How to Convert px to rem in CSS (And When Each One Wins)

Every front-end developer hits the same wall sooner or later: a design hands you everything in pixels, but the codebase—or your sense of accessibility—says you should be writing rem. So you start dividing numbers by 16 in your head, get it wrong on the third value, and ship a heading that's one notch too big. This guide walks through the actual math, why rem exists, and how to decide between px, rem, and em without second-guessing yourself.

The Formula You Actually Need

The conversion is a single division:

rem = px / root font size

The "root font size" is the font-size set on the html element. In a stock browser that value is 16px, and almost every framework assumes it. So with a 16px root, the math collapses to "divide by 16":

24px ÷ 16 = 1.5rem

Going the other direction is just multiplication:

px = rem × root font size
1.5rem × 16 = 24px

That's the whole engine. If your project ships a custom base—say the design system sets html { font-size: 18px }—you divide by 18 instead, and 1.5rem now means 27px, not 24px. Getting the base right is the single most common place this goes wrong, which is exactly why a px to rem converter lets you pin the base font size before it does any arithmetic.

A Worked Example at the 16px Base

Let's run three real values through it at the standard 16px root. These are the sizes you'll touch constantly: body copy, fine print, and a section heading.

24px → 1.5rem. 24 ÷ 16 = 1.5. A comfortable subheading.
12px → 0.75rem. 12 ÷ 16 = 0.75. Captions, labels, helper text.
32px → 2rem. 32 ÷ 16 = 2. A clean page or hero heading.

Notice how the round numbers fall out: 16px is 1rem, and the common type sizes land on tidy fractions. That's not a coincidence—the 16px default is deliberately chosen so the most-used sizes (12, 24, 32) divide cleanly. When a value doesn't divide cleanly (14px → 0.875rem, 18px → 1.125rem), that's the moment people reach for a calculator instead of trusting mental math, and the moment a wrong digit slips into production CSS.

Why rem Scales and px Doesn't

Here's the part that matters for real users. When someone bumps their browser's default font size from 16 to 20—a genuinely common accessibility setting, especially for readers with low vision or anyone squinting at a phone—every rem-based value recalculates against that new root. Your 1.5rem heading grows from 24px to 30px. Your padding, your line-height, your gutters all grow in proportion. The layout stays balanced because it was always described as a ratio of the root, not a fixed measurement.

A px value ignores that setting entirely. font-size: 24px is 24px whether the reader asked for bigger text or not. You've effectively overridden their accessibility preference, and on a text-heavy page that's a real exclusion, not a cosmetic one.

This is why the modern default for type, spacing, and line-height is rem. It's the one unit that respects "I need bigger text" without you writing a single media query. Reserve px for the things that genuinely should not scale: borders, box shadows, and one-device-pixel hairlines, where a fixed size is the point.

rem vs px vs em: A Decision You Can Make in Seconds

The three units answer three different questions:

rem is relative to the html root font size. It never compounds—2rem is always 2 × root, no matter how deeply nested. Use it for body type, headings, spacing, and anything that should honor the user's preference.
px is absolute. It never scales with anything. Use it for borders, shadows, and hairline rules where you want a fixed, predictable size.
em is relative to the nearest parent's computed font-size, so it compounds. Inside a .card { font-size: 1.25rem }, a padding: 1.25em resolves to 1.25 × (1.25 × 16) = 25px, not 20px.

That compounding makes em a feature for component-scoped scaling—a badge inside a heading inherits the heading's size automatically—and a footgun for layout, where nested lists can balloon unboundedly. There's one place em quietly wins outright: media queries. em breakpoints resolve against the browser default and survive user zoom more reliably than px ever has, so @media (min-width: 48em) triggers at 768px on a default browser and scales gracefully. Both rem and em are fine for breakpoints in current browsers; px is the one to avoid.

How I Actually Work This in Practice

When I migrate an old stylesheet, I don't convert values one at a time—that's where mistakes creep in. I grab every distinct pixel size in the file (usually something like 12, 14, 16, 18, 24, 32), drop the whole list into batch mode, and get back a single px-to-rem table at base 16. Then I find-and-replace across the CSS in one pass. The reason I trust the table over my own division is the 14s and 18s: I will confidently type 0.85rem for 14px when it's actually 0.875rem, and that 0.025rem error is invisible until a designer notices the rhythm is off. Letting the tool do the division removes an entire category of silent bug. For the odd one-off conversion outside the CSS world—pt for an email template, say—I keep a general unit converter open in the next tab.

The Quick Reference Worth Memorizing

A handful of conversions show up so often it's worth knowing them cold, all at the 16px base every CSS framework agrees on:

12px = 0.75rem
16px = 1rem
24px = 1.5rem
32px = 2rem

Anything else—14px, 18px, 20px, the awkward in-betweens—divide by your real root font size, double-check the base isn't a custom value, and let a converter handle the digits you'd otherwise fat-finger. Get the base right, lean on rem for anything a reader might want to resize, and keep px for the pixels that should stay pixels.

Made by Toolora · Updated 2026-06-13