em vs rem: What's the Difference?
em and rem are both relative CSS units used mainly for font sizes and spacing, and both scale based on font size rather than fixed pixels. The difference is what they reference. An em is relative to the font size of its own element (or the nearest parent that sets one), so ems can compound when nested. A rem is always relative to the root element's font size — the html element — so it stays consistent regardless of nesting. rem gives predictable, page-wide scaling; em gives contextual, component-local scaling.
- em
- Relative to the current element's font size (MDN Web Docs)
- rem
- Relative to the root (html) font size (MDN Web Docs)
- Compounding
- Nested ems multiply; rems never compound
- Default base
- Browsers default the root to 16px unless changed
- Accessibility
- Both respect user font-size settings, unlike fixed px
- Common use
- rem for consistent sizing; em for context-relative spacing
What em and rem actually are #
em and rem are relative length units in CSS, used most often for font sizes, margins, and padding. Unlike a pixel, which is a fixed absolute value, both em and rem scale in proportion to a font size, which makes layouts more flexible and accessible. The single most important distinction between them is their reference point. An em is relative to the font size of the element it is applied to — or, when sizing something other than font-size, the element's own computed font size. A rem, short for root em, is always relative to the font size of the root html element, no matter how deeply nested the element is. That root value defaults to 16 pixels in browsers unless a stylesheet changes it. Because both scale with font size, both honor a user's browser font-size preference, which fixed pixels ignore. This accessibility benefit is one reason our /services/ada-compliance work favors relative units when building interfaces that must adapt to individual reader needs.
The compounding behavior of em #
The defining quirk of em is that it compounds when elements are nested. Because an em references its own element's font size, and font size is inherited, ems can multiply in ways that surprise developers. If a parent sets its font size to 1.5em and a child inside it also uses 1.5em, the child's effective size is 1.5 times the parent's already-enlarged size, not 1.5 times the root. Nest a few levels deep and text can grow or shrink dramatically without any single rule looking wrong. This compounding is sometimes exactly what you want — a component whose spacing scales with its own text — but it is a frequent source of confusing bugs when used carelessly for structural sizing. Understanding this behavior is essential to using em deliberately rather than accidentally. When developers first hit unexplained text-size drift on a project, nested ems are almost always the culprit, which is why many teams reserve em for specific, intentional cases.
Why rem stays predictable #
rem exists precisely to avoid the compounding problem. Because every rem references the root html font size and nothing else, its value never changes based on nesting. A rule of 1.5rem produces the same size whether it sits at the top of the document or ten levels deep inside nested components. This predictability makes rem the go-to unit for consistent, page-wide sizing — headings, body text, and spacing scales all behave the same everywhere. It also creates a single control point: change the root font size, and everything defined in rem scales proportionally in one move, which is powerful for responsive typography and accessibility. For teams building maintainable design systems, this consistency is invaluable, since designers can reason about sizes without tracing inheritance chains. Our /services/ui-ux-design process typically standardizes on rem for typography and layout spacing for exactly this reason, reserving contextual units only where local scaling genuinely helps. Predictability reduces bugs and makes handoffs between designers and developers far smoother.
Accessibility and user font settings #
A major reason to prefer relative units over fixed pixels is respect for user preferences. Browsers let people increase their default font size for readability, and users with low vision often do. Text sized in pixels ignores this setting entirely and stays fixed, which can make a site unusable for someone who needs larger text. Both em and rem scale from a font size that ultimately traces back to the user's chosen default, so text sized in these units grows when the user asks for larger text. This is a core accessibility principle and aligns with WCAG guidance on resizable text. rem is especially reliable here because it ties directly to the root, giving a single, honest scaling point that honors the user's choice across the whole page. Building with relative units is a simple, high-impact accessibility habit. Our /services/ada-compliance reviews frequently flag pixel-based typography precisely because it defeats the browser controls people depend on to read comfortably.
Seeing em compounding versus rem #
This example shows why nested ems drift while rems hold steady. The nested em multiplies against its parent; the rem always references the root.
html { font-size: 16px; }
.parent { font-size: 1.5em; } /* 24px */
.parent .child { font-size: 1.5em; } /* 36px, compounded! */
.parent2 { font-size: 1.5rem; } /* 24px */
.parent2 .child2 { font-size: 1.5rem; } /* 24px, no compounding */When em is the better choice #
Despite rem's predictability, em has genuine strengths in the right context. em shines when you want a value to scale relative to the local text size rather than the whole page. A classic example is button or badge padding defined in em: because it references the button's own font size, the padding automatically grows in proportion when the button's text is enlarged, keeping the component visually balanced without extra rules. The same applies to spacing inside a component that should feel consistent with its own typography regardless of the global scale. em is also useful for values like letter-spacing or line-based spacing that are conceptually tied to the current font. Used intentionally within a self-contained component, em's context-awareness is a feature, not a bug. The key is deliberate application — reaching for em when you specifically want local scaling, and being aware of the compounding when elements nest. In component-driven /services/web-app-development, this targeted use of em keeps components self-scaling and portable.
When rem is the safer default #
For most sizing decisions, rem is the safer default. Its immunity to compounding means predictable results, and its single reference point makes global adjustments trivial and reasoning about sizes simple. Use rem for base typography, heading scales, layout spacing, and any value that should be consistent regardless of where an element sits in the document. This consistency pays off most on larger projects and design systems, where dozens of components share a common scale and unexpected inheritance would be a constant source of bugs. rem also pairs naturally with responsive typography: adjust the root font size at different breakpoints and the entire scale shifts in harmony. Because it ties cleanly to the root, rem gives designers and developers a shared, dependable vocabulary of sizes. When in doubt, reaching for rem produces fewer surprises. Our teams standardize on rem for the structural sizing of a /services/web-design build and introduce em only where a component genuinely benefits from scaling to its own local text.
A practical strategy for using both #
The mature approach is to use both units purposefully rather than choosing one exclusively. A common, effective strategy is to define the root font size once, use rem for all global sizing — body text, headings, and layout spacing — so the whole page scales predictably from a single control, and reserve em for values that should track a component's own font size, such as internal padding or icon spacing within a button. This combination gives you page-wide consistency where you want it and local flexibility where it helps. It also keeps typography accessible, since everything ultimately scales from the user-respecting root. Documenting this convention in a project's style guide prevents the accidental nested-em drift that plagues undisciplined codebases. Thinking of rem as the global unit and em as the contextual one turns a confusing choice into a clear rule of thumb. This is precisely the kind of foundational discipline our /services/ui-ux-design and development teams build into a project so the styling stays sane as it grows.
What we recommend #
Our recommendation is simple: default to rem for consistent, page-wide sizing, and use em deliberately when you want a value to scale with a component's own font size. rem's freedom from compounding makes it the predictable choice for typography and spacing scales, while em's context-awareness is a genuine asset inside self-contained components. Above all, prefer both relative units over fixed pixels for anything text-related, because they respect the browser font-size settings that many users rely on to read comfortably — an accessibility win that costs nothing. Avoid the common trap of nesting ems for structural sizing, where compounding quietly wrecks your scale. Document your convention so the whole team applies it consistently. If your current site uses rigid pixel typography or suffers from mysterious text-size drift, those are fixable problems. A /free-website-audit can surface where unit choices are hurting accessibility or maintainability, and our team can standardize the approach so your styling stays predictable and inclusive as the site grows.
FAQ
What is the main difference between em and rem?
The reference point. An em is relative to the current element's font size, so nested ems compound and multiply. A rem is always relative to the root html font size, so it stays consistent no matter how deeply an element is nested. rem gives predictable scaling; em gives context-relative, local scaling.
Should I use px, em, or rem for fonts?
Prefer rem or em over px for text. Fixed pixels ignore the browser font-size settings that users with low vision rely on, hurting accessibility. rem is the safest default for consistent sizing, while em suits values that should scale with a component's own text. Both respect user preferences; px does not.
Why do my nested elements grow unexpectedly?
Almost always compounding ems. Because em references its own element's font size and font size is inherited, nesting elements that each use em multiplies the effect, so text drifts larger or smaller with each level. Switching structural sizing to rem, which never compounds, fixes the unexpected growth immediately.
What is the default root font size?
Browsers default the root html element to 16 pixels unless a stylesheet changes it. This means 1rem equals 16px by default. Because everything in rem scales from this root, changing the root font size proportionally rescales your whole page, which is useful for responsive typography and honoring user preferences.
Is rem better than em?
Neither is universally better; they serve different purposes. rem is the safer default for consistent, page-wide sizing because it never compounds. em is better when you want a value to scale with a component's own font size, like button padding. Most projects use rem broadly and em selectively where local scaling helps.
Do em and rem help with accessibility?
Yes. Both scale from a font size that traces back to the user's chosen browser default, so text sized in these units enlarges when a user increases their font size. Fixed pixels ignore that setting. Using relative units is a simple, high-impact habit that aligns with WCAG guidance on resizable text.
How Local Web Advisor checks this for you
Is your own website getting web dev right?
Our free AI audit scans your site and tells you — in plain English — exactly what to fix for web dev and seven other areas, with the business impact and the fix for each. No login needed to start.
Run my free website audit →Was this helpful?