Why Developers Prefer REM Units

The core promise of REM

REM (Root EM) derives every value from the computed font-size of the html element. Its defining property is that this anchor lives at the top of the document — outside every component, outside every shadow root, outside every nested context.

The formula is simple:

rem value = desired px ÷ root font-size

With a 16px root: 24px → 1.5rem, 32px → 2rem, 14px → 0.875rem. Use the PX to REM calculator to convert values instantly.

This single-anchor property makes REM uniquely well-suited to design tokens: values that should express proportional relationships rather than absolute measurements, and that should respond to environmental context (user settings, zoom level, accessible display preferences) rather than hard-coding physical sizes.

Predictability over EM

EM is relative to the computed font-size of the current element or its parent. This local relativity is powerful but dangerous in deeply nested components:

/* Root: 16px */
.card            { font-size: 0.875em; } /* 14px — 0.875 × 16 */
.card .badge     { font-size: 0.85em;  } /* 11.9px — 0.85 × 14 */
.card .badge span { font-size: 0.9em;  } /* 10.7px — 0.9 × 11.9 */

Each nested EM multiplies the previous context. Three levels deep and you have type that is barely legible — and a bug that only reproduces inside that specific nesting context.

REM is immune to this compounding:

/* Root: 16px */
.card            { font-size: 0.875rem; } /* always 14px */
.card .badge     { font-size: 0.75rem;  } /* always 12px */
.card .badge span { font-size: 0.7rem;  } /* always 11.2px */

When you read a REM value, you know the rendered size. When you read an EM value, you need to know the entire ancestor chain.

Design token alignment

Design systems express spacing and type as a token scale — a named table of sizes that maps directly to component usage. REM tokens are portable across any component depth:

:root {
  /* Type scale */
  --font-size-xs: 0.75rem;   /* 12px */
  --font-size-sm: 0.875rem;  /* 14px */
  --font-size-base: 1rem;    /* 16px */
  --font-size-lg: 1.125rem;  /* 18px */
  --font-size-xl: 1.25rem;   /* 20px */
  --font-size-2xl: 1.5rem;   /* 24px */
  --font-size-3xl: 1.875rem; /* 30px */

  /* Spacing scale */
  --space-1: 0.25rem;  /* 4px  */
  --space-2: 0.5rem;   /* 8px  */
  --space-3: 0.75rem;  /* 12px */
  --space-4: 1rem;     /* 16px */
  --space-6: 1.5rem;   /* 24px */
  --space-8: 2rem;     /* 32px */
}

These tokens hold their meaning regardless of where they are used. A button's padding: var(--space-3) var(--space-4) is 12px × 16px in any context, on any page, at any nesting depth.

Use REM to PX when stakeholders need to verify the pixel output of a token at a specific root size.

Legitimate px exceptions

The case for REM is strong, but some scenarios genuinely require pixel values:

1px hairlines and borders

Sub-pixel rendering on high-DPI displays can make 0.0625rem (1px) render as blurry. For crisp borders, border: 1px solid is still the most reliable choice:

.divider {
  height: 1px; /* not 0.0625rem */
  background: currentColor;
}

Focus rings

WCAG 2.2 specifies focus indicators in pixels for consistency across zoom levels. Some accessible focus ring implementations use outline: 2px solid deliberately.

Media queries

The debate is ongoing, but many teams keep media queries in pixels for cross-browser consistency. Browser rendering of rem-based media queries at non-default root sizes has historically had quirks in some edge cases.

Icon dimensions where crisp rendering matters

SVG icons sized in REM scale correctly, but for icons that must snap to pixel grids (e.g. 16×16 icons in dense data tables), width: 16px; height: 16px is safer.

When EM is still the right tool

EM has a legitimate use case: component-local typography rhythm, where padding and margins should feel "attached" to the component's own font size.

/* Badge: padding should scale if badge font-size changes */
.badge {
  font-size: 0.75rem;
  padding: 0.25em 0.5em; /* scales with badge font-size, not root */
  border-radius: 0.25em;
}

If you later change .badge { font-size: 0.875rem }, the padding scales proportionally. This is the correct use of EM — deliberate, local, documented.

Use PX to EM with the element's font-size as the base to derive the correct EM value for component-local spacing. Pair REM to EM when crossing between global tokens and local component scales.

Common REM misconceptions

"I need to set html { font-size: 62.5% } to use REM"

No. This legacy pattern sets the root to 10px so 1.6rem = 16px for easier mental arithmetic. It overrides user browser preferences. Use proper conversion tools instead.

"REM values change at different screen sizes"

Only if you change the root font-size at breakpoints, which is uncommon. Most production sites have a fixed root and REM values are constant across viewport widths.

"1rem is always 16px"

1rem is always the computed root font-size. The browser default is 16px, but users can change it. A user who has set their browser to 20px gets 1rem = 20px — and that is the correct, accessible behaviour.

Browser compatibility

REM has been supported across all major browsers since 2013. There are no meaningful compatibility concerns in 2026:

For the rare IE11 support requirement, you would need to provide px fallback values — but IE11 market share is effectively zero in 2026.

Key takeaways

• REM is the right default for typography and spacing — it is predictable, accessible, and token-friendly.
• EM is appropriate for component-local rhythm where padding should track component font-size.
• px belongs for hairlines, focus rings, some icon sizing, and sometimes media queries.
• The 62.5% root hack is anti-pattern — use tooling and tokens instead.
• REM tokens in CSS variables are the most maintainable approach for design systems.