rem to px converter
Enter a rem value to get the pixel equivalent at any root font size. Result updates as you type.
When you need this conversion
Most modern stylesheets, design tokens, and CSS frameworks (Tailwind, Bootstrap 5, the entire ecosystem of design systems born after 2018) express type and spacing in rem because rem is the unit the modern web ships in. But you still need to know the pixel equivalent to debug a design comp, line things up in DevTools, write a test that asserts an element is this size, or talk to a designer who thinks in px. This page is the lookup you reach for when you have a rem value and need its rendered pixel size.
How it works
rem stands for “root em” — it’s relative to the font size set on the root element (the <html> tag). Browsers default the root to 16px, so unless the page has overridden it, every rem resolves through px = rem × 16. 1rem = 16px, 1.5rem = 24px, 2rem = 32px. The conversion the browser performs at render time is exactly the multiplication this calculator does — there’s no rendering magic beyond the math.
The catch: if the page sets a different root (a common shortcut is html { font-size: 62.5% }, making 1rem = 10px), the multiplier shifts. Use the root input above to model that case.
Worked examples
Reading a Tailwind class. p-6 applies padding: 1.5rem. At the default root: 1.5 × 16 = 24px of padding. Useful when you’re trying to match a Figma frame that was measured in pixels.
DevTools check. You see font-size: 0.875rem in the computed styles panel. 0.875 × 16 = 14px. That’s what’s rendering, regardless of what the source CSS looks like.
Non-default root. If the site applies html { font-size: 18px } for a reading-friendly default, 1.5rem becomes 1.5 × 18 = 27px. The same rem value, a different rendered size — which is the whole point of using rem.
Reference table
Common rem values resolved at the default 16px root, with the design-system role each typically fills.
| Rem | Pixels (16px root) | Typical role |
|---|---|---|
| 0.5rem | 8px | Compact spacing (Tailwind spacing-2) |
| 0.75rem | 12px | Captions, small UI text |
| 0.875rem | 14px | Secondary body (Tailwind text-sm) |
| 1rem | 16px | Default body text |
| 1.25rem | 20px | Lead paragraphs (text-xl) |
| 1.5rem | 24px | Sub-headings, medium spacing (h3, spacing-6) |
| 2rem | 32px | Section headings, large spacing (h2, spacing-8) |
| 3rem | 48px | Page titles (h1, spacing-12) |
| 4rem | 64px | Hero display type (text-6xl, spacing-16) |
rem vs em vs px — quick mental model
rem resolves once, against the root. The same rem value renders the same size everywhere on the page, regardless of nesting. Use it for anything that should be globally consistent: page-level type scale, layout spacing, breakpoints in calc().
emresolves against the parent. The same em value can render at different sizes inside different parents. Use it for component-internal sizing that should track the component’s own type (button padding that scales when button text scales).
px is absolute. The same px value always renders at the same pixel count. Use it for hairline borders, fixed icon sizes, and any visual atom that must not scale.
In a Tailwind / Tokens / design-system world, almost everything is rem because the “scales with user font-size” behaviour is the modern default. You only reach for em or px when that default is specifically wrong.
Accessibility
The rem-based stylesheet you’re reading is doing the right thing by default. Anything sized in rem responds when a user changes their browser’s default font size — a preference many readers rely on. Px values ignore that preference. When you convert rem to px just to talk about a value, remember that the px you see is at the default root only; the same rem may render larger or smaller for a user who has changed their settings.
If a page locks the root to a pixel value (html { font-size: 16px }), the entire rem tree stops scaling for users. That’s the single most common accessibility regression in otherwise rem-based codebases.
Common mistakes
- 1. Confusing rem with em when nested. rem ignores parent font sizes. If you wrap a 1rem element inside a 2rem-font parent, the inner element is still 16px, not 32px. Confusing this with em’s behaviour is the most common rem misunderstanding.
- 2. Assuming the multiplier is always 16. It usually is, but some codebases set the root to 62.5%, 10px, or 18px. Check the computed font-size on the html element before assuming 1rem = 16px.
- 3. Mixing rem with hard-coded px.
padding: 1rem 16pxrenders identically topadding: 1rem 1remat the default root, but it stops behaving the same the moment the root changes. Pick one unit per property. - 4. Forgetting that pseudo-elements use rem too. Some developers set a tiny rem-based icon size for
::beforedecorations and are surprised when accessibility-mode users see the icons scaled up enormously. If an element shouldn’t scale, use px.
FAQ
Is 1rem always 16px?
Only when the root font size is 16px, which is the browser default. If a stylesheet sets a different root, 1rem resolves to that value. Check the computed style of the html element in DevTools to be sure.
Why does Tailwind use rem?
Because rem-based spacing scales when users change their default font size. A Tailwind site sized in p-4, text-base, and gap-6 respects user preferences without any extra work; a px-based equivalent does not.
What about rem in media queries?
rem in media queries resolves against the browser default, not against any font-size you’ve set on the html element. This is intentional and useful: it means breakpoints expressed in rem also scale with user preferences, even if a custom root size would otherwise affect them.
How precise is rem to px conversion?
Mathematically exact — the browser computes rem × root to full precision and then rounds for layout. So 0.875rem at 16px root is exactly 14px; 0.8rem is exactly 12.8px (which may render as 13px due to sub-pixel rounding).