PX to REM: How the Conversion Works and Why It Matters
The one-division math behind px-to-rem, why 16px became the web's base size, the 62.5% trick, and where em quietly compounds against you.
The entire conversion is one division: rem equals pixels divided by the root font size. 24px at the default 16px root is 1.5rem. That’s it. The reason a PX to REM Converter still earns its keep is that nobody wants to divide 13 by 16 in their head forty times a day while porting a Figma file.
Why 16 pixels, of all numbers
The 16px default goes back to the mid-90s browsers, which shipped “medium” text at 16px because that roughly matched 12-point print type on the low-DPI monitors of the era. Every browser since has kept it, and now the whole ecosystem leans on that number. Tailwind’s spacing scale assumes it. So does almost every CSS framework’s type ramp.
Here’s the part that matters: users can change it. Chrome and Firefox both have a font-size setting buried in preferences, and people with low vision actually use it. If your layout is built in px, that setting does nothing — the text stays small. Built in rem, everything scales. That’s the whole accessibility argument, and it’s why WCAG’s resize-text criterion keeps coming up in audits of px-heavy sites.
Browser zoom is a different mechanism, by the way. Zoom scales px and rem alike, which is why “it zooms fine” is not evidence your site respects font-size preferences. Test with the setting, not with Ctrl-plus.
The 62.5% trick, and its cost
In 2004 Richard Rutter suggested setting html { font-size: 62.5% }, which turns 1rem into 10px and makes the mental math trivial: 1.3rem is 13px, 2.4rem is 24px. Plenty of older codebases still run on this.
It works, but it has a tax. Every third-party widget and every copy-pasted snippet assumes a 16px root, so their text renders at 62.5% of the intended size until you patch it. If you inherit a project on the 10px base, set the root to 10 in the converter and carry on — just don’t introduce the trick into a new project without weighing that cost.
Where em bites
rem is boring and predictable: one reference point, the html element. em is relative to the current element’s font size, and it compounds. A nested list styled at 1.2em renders at 1.2, then 1.44, then 1.728 times the base as you go deeper. I’ve debugged exactly this in a comment thread widget where the fifth reply level had comically large text and nobody could say why.
em still has legitimate uses — padding that should track the element’s own text size, media queries — but for global spacing and type scales, rem saves you from the compounding surprise.
Reading Tailwind values without a cheat sheet
Tailwind’s scale is rem under the hood: each spacing step is 0.25rem, so p-4 is 1rem and p-6 is 1.5rem. Font sizes follow the same base — text-sm is 0.875rem, which is 14px at the default root. Once you know the step size, the class numbers stop feeling arbitrary: multiply by 4 and you have pixels.
The conversion table in the tool lists the common sizes from 1px to 128px at whatever root you set, which covers the Tailwind scale and most design-system type ramps in one view.
Next time a designer hands you pixel values and the stylesheet wants rem, drop them into the PX to REM Converter and copy the results straight into your CSS.