What This Converter Does
The Microapp Pixel to Rem Converter takes pixel values — the kind your designer hands you on a Figma frame, the kind Photoshop exports, the kind that show up in screenshots from a redesign deck — and converts them into rem and em, the units browsers actually want. It also flags the closest Tailwind spacing token (if any) and, in bulk mode, emits a CSS variables block keyed by pixel value so you can ship a design-token sheet without writing the arithmetic yourself.
rem = px ÷ root font-sizeAt the browser default root of 16px:
• 16px = 1rem
• 24px = 1.5rem
• 12px = 0.75rem
• 8px = 0.5rem
• 4px = 0.25rem
Why rem, Not px?
If you only ever build sites for one user — yourself, on your monitor, in your browser, at default zoom — px and rem look identical. They behave identically too. The difference shows up at the edges of usage, and those edges are where accessibility lives.
Roughly 5% of web users change the browser default font-size. Older readers bump it up. People with low vision crank it. People reading on a low-DPI display do the same. A pixel-based design ignores them; everything stays the size you decided, including the spacing and the body copy. A rem-based design scales with their setting — text gets larger, gaps get larger, hit targets get larger. It's the difference between "we built a design" and "we built a design that respects the user's preferences."
The second reason is responsive layouts. With rem-based sizing, scaling the root font-size at breakpoints rescales every spacing, every component, every type size at once:
html { font-size: 14px; }
@media (min-width: 768px) { html { font-size: 16px; } }
@media (min-width: 1280px) { html { font-size: 18px; } }Three rules. Whole design grows. With px, you'd be writing a media query for every value.
rem vs em — When to Use Which
Both are relative units; they differ in what they're relative to.
| Unit | Relative to | Use for |
|---|---|---|
rem | The root element's font-size (typically html) | Layout-level sizing: padding, margin, gap, width, max-width |
em | The current element's parent font-size | Type-relative sizing: line-height, letter-spacing, button inner padding, icon gap |
The rule of thumb: rem for the page, em for the component. The page's spacing should be predictable, so rem; the component's inner spacing should grow with its own text size, so em.
A button that says "Save" and a button that says "Submit application for review" should have proportionally similar inner padding. If the padding is in em, it scales with the font; if in px or rem, the longer button looks cramped or the shorter one looks bloated. This is what em was designed for.
Bulk Mode — From Design Tokens to CSS Variables
Most design systems have a fixed spacing scale: usually 4, 8, 12, 16, 24, 32, 48, 64, sometimes with intermediates. Manually converting each one to rem is tedious and error-prone. The bulk mode of this converter takes the whole scale at once and emits:
:root {
--space-4: 0.25rem; /* 4px */
--space-8: 0.5rem; /* 8px */
--space-12: 0.75rem; /* 12px */
--space-16: 1rem; /* 16px */
--space-24: 1.5rem; /* 24px */
--space-32: 2rem; /* 32px */
--space-48: 3rem; /* 48px */
}Now your stylesheets reference var(--space-16) and your designer references "16" in Figma — same source of truth, two consumers. Change the root font-size, and the whole system scales. Change a value in :root, and every reference updates. This is what design tokens are supposed to feel like.
The "62.5% root" Trick — Why We Don't Recommend It
An older CSS pattern: set html { font-size: 62.5% } so that 1rem = 10px. Math gets easier (24px = 2.4rem). It was popular for years.
The problem: that rule overrides the user's accessibility setting. A user who has set their browser to 20px expects every site to scale up accordingly; with the 62.5% rule, the site uses 62.5% of that, which is 12.5px — smaller than the default. The site silently undercuts the user's preference.
If you want easier mental math, use root = 16 and accept the conversion. This tool exists exactly for that reason. The 62.5% trick was a workaround for a problem (math) that the tool now solves directly, without sacrificing the accessibility behavior.
Edge Cases This Converter Handles
- Fractional pixels (e.g. 1.5px for hairline borders). Just type the decimal — math flows through.
- Negative values (e.g. -8px for negative margins). Common for tight UI; converted as expected.
- Trailing px in pasted input ("16px" instead of "16"). Stripped automatically in bulk mode.
- Mixed separators (commas, semicolons, newlines, spaces). All treated as token boundaries.
- Garbage tokens in pasted text (e.g. "padding: 16px;"). Non-numeric tokens are silently skipped.
- Non-default root sizes. If your html element sets font-size: 14px, change the slider to 14 and the math adjusts.
Tailwind Spacing — The Quick Mapping
If you're building with Tailwind, the conversion is even tighter — Tailwind's spacing scale is 4px-quantized, so most px values from a 4px-based design system map directly to a class.
| px | rem | Tailwind |
|---|---|---|
| 4 | 0.25rem | p-1, m-1, gap-1 |
| 8 | 0.5rem | p-2, m-2, gap-2 |
| 12 | 0.75rem | p-3, m-3, gap-3 |
| 16 | 1rem | p-4, m-4, gap-4 |
| 20 | 1.25rem | p-5, m-5, gap-5 |
| 24 | 1.5rem | p-6, m-6, gap-6 |
| 32 | 2rem | p-8, m-8, gap-8 |
| 48 | 3rem | p-12, m-12, gap-12 |
| 64 | 4rem | p-16, m-16, gap-16 |
If your design uses values that don't fall on the 4px grid — 7, 13, 22, 30 — Tailwind has no direct token. You'll need an arbitrary value (p-[22px]) or to extend the theme. The converter flags missing tokens with a dash so you can see at a glance which values fit and which don't.
Related Tools
For the reverse direction — rem values from a stylesheet back into pixels — use the REM to PX Converter. For a broader unit conversion across px, rem, em, pt, pc, vw, and vh, see the CSS Unit Converter. For converting design colors from hex to RGB, see the Hex to RGB Converter.