Explain em, rem, px and why rem is preferred for font sizing

This tests CSS unit semantics and accessibility. px is absolute; em compounds against its parent; rem is root-relative and predictable. rem respects user browser font settings without nesting issues.
What's really being asked
Whether you understand the reference context of CSS length units and can justify rem for accessibility and maintainability inside a design system. Interviewers want to see that you know when compounding is dangerous and why user-agent font preferences matter for inclusive design.
The full answer
First, define px as an absolute length unit tied to device pixels, which does not scale with user font preferences and creates brittle layouts when users override defaults. Second, explain that em is relative to the font-size of its direct parent element, so nested components multiply values and produce unpredictable results that are difficult to debug across a large codebase. Third, state that rem is relative to the root element font-size, giving consistent scaling across the entire document regardless of nesting depth. Fourth, connect rem to accessibility by noting that when a user changes the browser default font size in settings, rem-based text scales accordingly, whereas px does not respond to that preference. Fifth, mention that rem creates a single scaling variable at the root, which makes design tokens, responsive typography, and global theming easier to maintain and reason about.
The mistakes people make
Claiming that px is acceptable because browser zoom works on everything today, which ignores non-zoom font-size preferences in accessibility settings and can break layouts at high zoom. Saying em and rem are identical, which misses the compounding problem entirely. Arguing that rem is only for fonts and cannot be used for spacing, when rem is valid for any length property including margins and padding. Failing to mention the root font-size as the rem reference point, or suggesting that percentages replace rem without explaining the relationship to root.
What usually comes next
How would you handle a component library where consumers might change the root font-size? When is em actually the right choice, such as for padding on a button that should scale with its own text size? How do viewport units like vw fit into a typography scale alongside rem? What happens if a user sets root font-size to 62.5 percent and how does that affect rem math?
A concrete example
Imagine a card component with a heading and nested paragraphs. If the card font-size is set to 0.875 em and a paragraph inside it also uses 0.875 em, the paragraph becomes 0.765625 em relative to the root, which is hard to trace and debug across teams. If both use rem, the heading might be 1.25 rem and the paragraph 1 rem, staying predictable regardless of nesting depth. When a user sets their browser default to 20 pixels instead of 16, a rem-based system scales every text element proportionally without redesigning each component or creating microscopic text in deeply nested trees.
Interview question
What makes rem more predictable than em when sizing text in nested components?
- a.rem references the root font size and avoids parent-level compoundingCorrect
- b.Browser zoom ensures px and em scale equally well for accessibility
- c.rem and em both calculate from the same parent reference point
- d.rem is limited to font properties while em applies to any length
Why? this is the answer
rem is always calculated from the root font-size, preventing nested elements from multiplying their size as em does. Distractor D is tempting but wrong because em references its direct parent, not the root, leading to unpredictable compounding in nested trees.
Just read this? Test yourself on what you have been reading.
Read the original → developer.mozilla.org
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on css — each one lists the topics its interview covers.
See open roles