PX to REM Converter

CSS units explained — px, em, rem, %, vw, vh, ch, and which to use where

"Should I use px, em, or rem?" is a question every CSS author hits in their first month and still hits ten years later for new edge cases. The answer is not "rem for everything" — different units exist because different jobs demand different scaling behaviour. This guide is the working reference: how each unit is defined, the formula for converting between them, the accessibility argument for rem-based typography (it is a real WCAG requirement, not an opinion), and the modern viewport-relative units that ship in every evergreen browser.

Absolute vs relative units

The conversion formulas

Given a default 16 px root and 16 px parent:

• rem = px / root_font_size
• em = px / parent_font_size
• px = rem × root_font_size
• px = em × parent_font_size

Worked examples for the standard 16 px root:

Why rem-based typography is a WCAG requirement, not a preference

WCAG 2.1 Success Criterion 1.4.4 Resize Text requires that text can be scaled up to 200% without loss of content or functionality. Browsers implement this through two mechanisms:

1. Page zoom (Ctrl++): scales everything, regardless of unit. Pixels included.
2. Default font size preference: changes the root font size from 16 px to whatever the user picked in browser settings. Only rem and em-based values respect this. Pixel-based values stay frozen.

Roughly 4% of users override their default browser font size. A site authored in pure pixels ignores them entirely — text stays the same physical size when the user has explicitly told the browser they need it larger. This is the single strongest argument for rem-based typography in production code.

The 62.5% trick — making rem math easier

Many design systems use this idiom:

html {
  font-size: 62.5%;   /* 10 px on a default 16 px root */
}
body {
  font-size: 1.6rem;  /* 16 px — restore default body size */
}

Now the rem math is trivial: 1 rem = 10 px, 1.6 rem = 16 px, 2 rem = 20 px. The percentage form is critical — using html { font-size: 10px } instead breaks user font-size preferences. With 62.5%, the result still scales when a user bumps their default to 20 px (yielding a 12.5 px effective root rather than ignoring the preference entirely).

When to use em instead of rem

Em is the right choice when you want a value to scale with its local context, not the document root:

• Component padding on a button: padding: .5em 1em grows when you bump the button font size to make a "large" variant.
• Border-radius on cards: border-radius: .5em stays proportional whether the card is heading-sized or body-sized.
• Inline icons sized to match adjacent text: height: 1em; width: 1em tracks the text exactly.
• Vertical rhythm in a single component: margin-bottom: 1em = "one line of space below".

The trap with em: nesting compounds. A 1.5 em heading inside a 1.2 em parent inside a 1.1 em grandparent computes to 1.5 × 1.2 × 1.1 = 1.98 em — almost double. Use rem when you want to opt out of this compounding.

Modern viewport-relative units — vw, vh, and the new dvh family

Mobile browsers have a long-running headache: the URL bar appears and disappears as the user scrolls. The original 100vh meant "full viewport height", but on mobile that height changes by ~50 px during scroll, causing layout thrash. The 2022+ solution shipped three new variants:

• svh — small viewport height (URL bar visible). Always the smaller value.
• lvh — large viewport height (URL bar hidden). Always the larger value.
• dvh — dynamic viewport height. Updates as the URL bar moves. Use this for "fill the screen" containers.

The corresponding width variants (svw, lvw, dvw) follow the same pattern. As of 2026 these are supported in every evergreen browser; for mobile-first hero sections, min-height: 100dvh is the modern replacement for min-height: 100vh.

The container query unit (cqw, cqh) — viewport-relative for components

CSS Container Queries (2023) introduced a new family of units that resolve against the nearest container, not the viewport:

• cqw / cqh — 1% of container width / height.
• cqi / cqb — 1% of container inline / block size (writing-direction-aware).
• cqmin / cqmax — smaller / larger of cqi and cqb.

Use case: a card component where font-size scales with the card's width, regardless of where the card lands. font-size: clamp(1rem, 4cqi, 1.5rem) caps the responsive growth.

Common px / rem / em mistakes

• Setting html { font-size: 10px } instead of 62.5%. Breaks the user's accessibility font-size preference.
• Using rem for media query breakpoints when paired with a px root and unaware of min-width resolution. Modern browsers do the right thing; older Safari versions had bugs. Em-based breakpoints are still safer.
• Mixing rem and px without a system. If half your spacing is rem and half is px, refactoring becomes a manual scan of every file.
• Using vw for body font size. Text becomes ~12 px on phones and ~30 px on TVs. Use clamp() with both rem and vw bounds.
• Using height: 100vh on mobile heroes. The URL bar makes that taller than the screen. Use 100dvh.
• Forgetting that min-width media queries match in computed pixels. If you write @media (min-width: 48rem) and a user has a 20 px root, the breakpoint hits at 960 px, not 768 px — desired behaviour, but surprising.

Build pipeline integrations — automating the conversion