📏 Px to Rem Converter
Bidirectional px ↔ rem/em conversion with configurable base font size.
🔒 100% client-side processing
Common px to rem conversions
| Pixels | Rem / Em |
|---|
Converting pixel values from a mockup into scalable CSS is one of the most repetitive jobs in front-end development. This converter does it both ways as you type: enter pixels to get rem, or enter rem to get pixels, with a base font size you control. A generated reference table covers every value from 1px to 64px, so a whole spacing scale can be translated without opening a calculator.
How to Use
- Set the base font size: Leave it at 16 for the browser default, or enter your project’s actual root size.
- Edit either field: Type in the px box to update the rem box, or type in the rem box to update px. There is no convert button.
- Pick rem or em: The dropdown beside the rem field changes the label only; the math uses the same base.
- Scan the table: The 1–64px table regenerates against your chosen base, ready to copy from.
The Conversion Math
The whole tool rests on one division and one multiplication. To convert pixels to rem, divide by the base:
rem = px ÷ base
At a 16px base, 32px ÷ 16 = 2rem and 12px ÷ 16 = 0.75rem. To go the other way, multiply:
px = rem × base
So 1.5rem × 16 = 24px, and 0.875rem × 16 = 14px. The converter applies the same two operations whether you are working with rem or em, which is why the unit dropdown does not change the numbers.
The distinction between the units is about reference, not arithmetic. One rem is always the root font size. One em is the font size of the current element’s parent, so a padding of 1em inside a component whose parent is 20px resolves to 20px, not 16px. If you convert a padding value to em assuming a 16px base but the parent is 20px, the rendered result is wrong. rem has no such ambiguity.
Choosing a Base Font Size
Sixteen is the safe answer for almost every project, but three other bases show up in practice:
| Base | Set by | 1rem equals | Notes |
|---|---|---|---|
| 16px | Browser default | 16px | Match this for accessibility-first work |
| 10px | html { font-size: 62.5% } | 10px | Easy mental math; test with enlarged text |
| 20px | A custom root rule | 20px | Some design systems use a 20px body |
| 18px | A custom root rule | 18px | Common for reading-heavy sites |
Whatever you choose, confirm it by inspecting the computed font size of the html element in your browser’s developer tools. Guessing the base is the single most common source of off-by-a-bit conversions.
Common Values at a Glance
| Pixels | rem at base 16 | rem at base 10 |
|---|---|---|
| 8px | 0.5 | 0.8 |
| 12px | 0.75 | 1.2 |
| 16px | 1 | 1.6 |
| 18px | 1.125 | 1.8 |
| 20px | 1.25 | 2 |
| 24px | 1.5 | 2.4 |
| 32px | 2 | 3.2 |
| 48px | 3 | 4.8 |
| 64px | 4 | 6.4 |
The pattern is easy to extend: at base 16, every 4px step is 0.25rem, so 28px is 1.75rem and 36px is 2.25rem. At base 10, every 1px is 0.1rem.
Converting a Real Spec
Take a small card component specified in Figma: 20px padding, a 24px heading, 15px body text, a 40px avatar, and a 12px gap. At a 16px base, the converter returns 1.25rem for the padding, 1.5rem for the heading, 0.9375rem for the body, 2.5rem for the avatar, and 0.75rem for the gap. The CSS reads cleanly:
.card { padding: 1.25rem; gap: 0.75rem; }
.card h2 { font-size: 1.5rem; }
.card p { font-size: 0.9375rem; }
.avatar { width: 2.5rem; height: 2.5rem; }
Now the same spec against a 10px root: the padding becomes 2rem, the heading 2.4rem, the body 1.5rem, the avatar 4rem, and the gap 1.2rem. Notice how the body text at 15px is a less tidy 0.9375rem at base 16 — this is exactly the kind of value where a mental conversion goes wrong and the tool earns its place. If a designer hands you a spec full of odd numbers like 15px and 22px, enter the base once and let the table do the rest.
Edge Cases and Precision
- Fractional pixels: 15.5px ÷ 16 = 0.96875, which rounds to four decimals. Browsers handle the sub-pixel value fine.
- Very small values: 1px at base 16 is 0.0625rem. This is valid CSS, though a 1px border is often intentionally kept in px to stay a true hairline.
- Empty input: Clearing a field clears the paired field rather than treating the blank as zero.
- Invalid base: Zero, negatives, and non-numeric input show an error and halt conversion.
- Rounding drift: Repeatedly round-tripping a value can shift the last decimal, so convert once from the source value rather than chaining edits.
Why rem Beats px for Accessibility
Pixels are absolute. A user who raises the browser’s default font size to 20px to read more comfortably does not change a 16px heading — it stays 16px and now looks small against the larger body text. rem units inherit that preference, so a heading set to 1.5rem becomes 30px at a 20px root and keeps its proportional relationship. WCAG guidance treats text that cannot be resized without loss as a failure, and px typography is the usual culprit. Spacing scales built in rem also grow with the text, so margins do not collapse into a cramped layout when the font is enlarged. Keeping a few hairline borders and one-off shadows in px is a reasonable exception; fonts and layout spacing belong in rem.
Related Tools
Frequently Asked Questions
Why does 24px equal 1.5rem?
rem means root em, so the conversion is px divided by the root font size. At the browser default of 16px, 24 / 16 = 1.5, hence 1.5rem. Change the base to 10 and the same 24px becomes 2.4rem, which is why every conversion depends on the base you set.
Which base font size should I enter?
Use 16 unless your stylesheet deliberately sets a different root size. Sixteen pixels is the default in Chrome, Firefox, Edge, and Safari, and nearly every design system is drawn against it. If your CSS contains html { font-size: 62.5% }, enter 10 instead, because that rule makes 1rem equal 10px.
Does the em option calculate differently from rem?
The arithmetic is identical — both divide or multiply by the base you provide. The dropdown only relabels the output. That is accurate for an element whose parent font size equals the base, but genuinely different from rem when a parent has its own size, since em is relative to the parent while rem is always relative to the root.
How precise are the converted values?
Results are rounded to at most four decimal places and trailing zeros are dropped, so 18px at a 16px base displays as 1.125 and 12px as 0.75. That is far more precision than CSS needs, since browsers resolve sub-pixel values themselves during layout.
Why do some teams set the root to 62.5%?
That shorthand sets html { font-size: 10px } because 62.5% of the 16px default is 10. It makes mental math easier — a 24px design value becomes 2.4rem at a glance. The trade-off is that it overrides the user's root size unless you rem-based the rule itself, so it needs care for accessibility.
What happens if I enter a base of zero or a negative number?
The tool refuses the value and shows an inline error, because division by zero is undefined and a negative root size is meaningless. Correct the base field and the conversion and the reference table resume immediately.
Reviewed by the HandyTools Hub team · Last updated