Converting px to rem is basic math — divide by your base font size. Every tool on this list gets that part right. What separates them is whether they tell you the part that actually trips people up: which properties should be in rem, and which ones should deliberately stay in px.
The part the math doesn't tell you
/* Naive "convert everything" approach */
.card {
padding: 1rem; /* 16px → 1rem, fine */
margin: 1.5rem; /* 24px → 1.5rem, fine */
border: 0.0625rem solid #ddd; /* 1px → 0.0625rem — this is the mistake */
border-radius: 0.5rem; /* 8px → 0.5rem, fine */
}
Borders are the classic trap, though not for the reason you usually see given. A 0.0625rem border doesn't render as a blurry sub-pixel — browsers clamp any non-zero border to a minimum of one device pixel, so it stays a crisp hairline. I checked in Chromium across a range of root sizes:
html { font-size } |
1px border |
0.0625rem border |
|---|---|---|
| 16px | 1px | 1px |
| 20px | 1px | 1px |
| 24px | 1px | 1px |
| 32px | 1px | 2px |
So it holds at 1px for a long stretch, then silently doubles once the root gets large enough. That's arguably worse than an obvious break, because it only shows up for the users who've turned their font size way up.
The deeper objection is about intent. A hairline border is a visual constant — it separates two things. It isn't a typographic measure, so tying it to font size doesn't express anything meaningful. Same reasoning for most box-shadow blur and spread values, and anything meant to represent one physical device pixel.
Meanwhile the properties that should scale with the user's font preference — padding, margin, gap, border-radius, and obviously font-size itself — are exactly where rem earns its keep. That's the actual accessibility win: someone who bumps their base font size to 20px gets a layout that scales proportionally, not just bigger text crammed into fixed-size boxes.
A converter that just does value / 16 on everything you paste isn't wrong, exactly — but it's not helping you make the property-by-property call either.
Second trap: media query breakpoints
/* Original px-based breakpoint */
@media (min-width: 768px) {
.container { max-width: 720px; }
}
/* Converted to rem — here rem is genuinely the better choice */
@media (min-width: 48rem) {
.container { max-width: 45rem; }
}
This one's the opposite case from borders — rem (or em) is actually the better call here, not just a stylistic preference. But the reason is the opposite of what most guides say, and it's worth getting right.
Inside a media query, rem does not follow your html { font-size }. It's always resolved against the browser's initial font size. I tested this by setting the root to 16px, 24px and 32px in turn — @media (min-width: 48rem) fired at a 768px viewport in all three cases, never at 1152px.
That sounds like it defeats the purpose, but it's exactly what makes rem breakpoints valuable. Because they bypass your stylesheet's root override, they track the user's browser font-size setting instead. A reader who's raised their default from 16px to 20px gets breakpoints that shift with them, so the layout reflows at a point that suits their text size rather than at a width you hardcoded. A px breakpoint can't do that, and a rem breakpoint tied to your root wouldn't either.
Third case: line-height and unitless values
/* Common mistake — converting a unitless line-height */
.paragraph {
font-size: 1rem;
line-height: 0.09375rem; /* WRONG — this was line-height: 1.5 (unitless), not 24px */
}
/* Correct — leave unitless line-height alone */
.paragraph {
font-size: 1rem;
line-height: 1.5; /* scales relative to this element's own font-size */
}
This one's brutal and easy to miss in review. A unitless line-height: 1.5 on 16px text computes to 24px. Run it through a naive converter and you get 0.09375rem, which computes to 1.5px — the lines collapse on top of each other.
The distinction is that a unitless line-height is a ratio, not a length. It multiplies against each element's own font-size, which is exactly why it's the recommended value in the first place: a child with larger text gets proportionally larger leading for free. Converting it to any absolute unit throws that away even when the number happens to work out.
This mostly bites with paste-a-whole-stylesheet tools, but it's worth a grep before you commit a batch conversion.
Fourth case: icon and SVG sizing
/* Icons converted to rem — usually the wrong call */
.icon {
width: 1rem; /* was 16px */
height: 1rem;
}
/* Icons kept in px — generally the right call */
.icon {
width: 16px;
height: 16px;
}
Icons are visual assets, not typography — a 16px icon next to 16px text is a deliberate pairing, and letting the icon scale with a user's font-size preference can throw that relationship off. An icon that grows faster or slower than the text beside it looks broken, not "more accessible."
Some design systems do intentionally scale icons with rem to keep the icon-to-text ratio locked, and that's a perfectly valid choice. The point is that it should be a decision you made, not something a converter did to every pixel value it found without telling you.
Fifth case: transform and translate values
/* Converted to rem — technically works, but unusual */
.tooltip {
transform: translateY(-0.5rem);
}
/* Left in px — the more common convention */
.tooltip {
transform: translateY(-8px);
}
transform values describe movement distance, not a size tied to typography, so there's no accessibility argument for converting them — an 8px nudge should stay an 8px nudge regardless of the user's font-size setting. Most codebases leave transform offsets in px by convention. A converter that rewrites every number inside transform: isn't breaking anything, but it does scatter rem values through places nobody wanted them.
Here's how five free tools handle the main px-to-rem conversion, and whether they surface any of this.
1. CodeFronts — PX to REM Converter
Best for: knowing which properties to convert, not just doing the math.
Straightforward converter — enter a px value, set your base font size with a slider or number field, get the rem equivalent. There's a preset row for common values and a full reference scale underneath.
What's different is the guidance sitting right next to the tool, in plain language on the page:
Use REM for spacing too — Apply REM to padding, margin, gap, and border-radius, not just font-size. This gives the whole layout scale coherence.
Avoid REM for borders — Keep border-width in px (1px, 2px). Borders should not scale with font size — a 1px border should always be 1px.
That's the exact trap from the first section of this post, called out at the point you're about to fall into it rather than left for you to discover in a bug report three months later. None of the other four tools here say anything about which properties should get converted.
It's also open source — the standalone version is a single 174-line HTML file with no build step and no external requests, so you can fork it or drop it straight into an internal tools page.
🔗 codefronts.com/tools/px-to-rem-converter
2. PixelsConverter
Best for: understanding the formula, not just getting the number.
Less a quick-convert widget, more a working explanation — walks through what the root element is, why 16px is the usual default, and runs the division by hand so you're not trusting a black box.
Formula shown on the page:
rem = px / base font size
Example: 36px ÷ 18px base = 2rem
Good if you're teaching someone the concept rather than doing a fast lookup.
🔗 pixelsconverter.com/px-to-rem
3. nekocalc — PX to REM Converter
Best for: quick back-and-forth conversions in either direction.
Bidirectional — type a px value and get rem, or type rem and get px, with an adjustable base font size.
32px → 2rem (at 16px base)
2rem → 32px (reverse direction, same tool)
No guidance about which CSS properties should or shouldn't use rem, but the two-way conversion is genuinely convenient when you're moving between a design spec in px and a stylesheet in rem.
🔗 nekocalc.com/px-to-rem-converter
4. Bug0 — CSS Unit Converter
Best for: converting to units other than rem too.
Handles px, rem, em, %, and pt in one interface with live conversion as you type.
16px = 1rem = 1em = 100% = 12pt
24px = 1.5rem = 1.5em = 150% = 18pt
Plus a reference table converting a long range of px values across all units at once. Useful if you're setting up a design-system scale and want the full unit picture rather than a single lookup.
🔗 bug0.com/tools/px-to-rem-converter
5. CodeBeautify — PX to REM Converter
Best for: a name you already know, if you're already using their other tools.
Does the conversion reliably (16px → 1rem, 20px → 1.25rem, standard division). Part of CodeBeautify's much larger suite of format and unit converters, so if you're already there for something else it's a reasonable one to bookmark alongside it. No specific guidance on which properties to convert vs. leave in px.
🔗 codebeautify.org/px-to-rem-converter
Short version
- Want the "which properties" guidance built in → CodeFronts
- Learning the concept, not just converting → PixelsConverter
- Need both directions (px↔rem) → nekocalc
- Setting up a full unit scale (px/rem/em/%/pt) → Bug0
- Already using CodeBeautify for other conversions → CodeBeautify
Whichever tool you use, the conversion math is the easy part. The judgment call is knowing that your borders and shadows probably shouldn't scale with the rest of your layout — and that your breakpoints probably should.
Do you convert your whole stylesheet to rem up front, or only the properties that actually need to scale? Curious what other people land on here.
Top comments (0)