PX ⇄ REM Converter

rem = px ÷ root font size, where the root is the computed font-size of the html element — 16px by default in Chrome, Firefox, Safari, and Edge. Examples at the 16px default: 10px = 0.625rem, 12px = 0.75rem, 14px = 0.875rem, 18px = 1.125rem, 24px = 1.5rem, 32px = 2rem. Going the other way: px = rem × root, so 1.25rem = 20px.

Accessibility. Users with low vision often raise their browser’s default font size (Settings → Appearance in Chrome) instead of zooming. Suppose a user sets the default to 20px: text set in rem scales — 1rem becomes 20px, 1.5rem becomes 30px — while text hard-coded as font-size: 16px stays 16px, silently ignoring the user’s explicit preference. WCAG 1.4.4 requires text to be resizable up to 200%; rem-based sizing satisfies the font-size-preference path, px-based sizing does not. Browser zoom (Ctrl/Cmd +) scales both, but you don’t control which mechanism your users rely on.

Setting the root to 62.5% of the 16px default makes 1rem = 10px, so the mental math becomes trivial: 1.6rem = 16px, 2.4rem = 24px. The tradeoffs: every third-party stylesheet and component library that assumes 1rem = 16px will render 37.5% smaller until you compensate; you must immediately reset body to 1.6rem; and the design system gains a hidden global dependency that surprises every new developer. It still respects user preferences (62.5% of 20px = 12.5px, so everything scales), but most modern teams skip it — with this converter or CSS custom properties, the arithmetic was never the hard part.

Anywhere scaling with the user’s text-size preference would hurt rather than help: borders (a 1px hairline should stay a hairline at any text size), box shadows, outline widths, and usually border-radius. Media-query breakpoints are a debated case — em-based queries handle some zoom edge cases better — but px breakpoints are common and defensible. The rule of thumb: typography, spacing tied to text, and max-widths of text columns in rem; decorative geometry in px.

Identical arithmetic, different reference. rem divides by the root (html) font size — one global, predictable base. em divides by the element’s own inherited font size, so ems compound: a 1.2em element inside a 1.2em parent renders at 1.44 × the base, which is why deeply nested em sizing drifts unpredictably. Use em deliberately for things that should scale with their local context — padding inside a button, an icon next to a label — and rem for everything tied to the page-wide scale.

Because that is the precision where browser rendering differences stop mattering. 13px at a 16px root is exactly 0.8125rem (shown in full), while 13px at an 18px root is 0.72222…rem, which the tool rounds to 0.7222rem — a discrepancy of less than 0.0004px at typical sizes, far below the half-pixel threshold where any screen could render a difference. Trailing zeros are trimmed, so 10px shows as 0.625rem, not 0.6250rem.