Skip to main content

PX to EM Converter

What it does

The PX to EM Converter translates CSS sizes between four units that all describe length but use different references — pixels (absolute), em (relative to the parent), rem (relative to the root), and percentages. Type a value into any field; the others update. A configurable root font size (default 16px, the browser default) sets the scale. A reference table beneath shows common sizes (10–64px) in their rem equivalents at the chosen base — useful for skimming when you need “the rem value for 24px” repeatedly.

Common situations

You’re migrating an existing stylesheet from pixel-based sizes to a rem-based scale. The motivation is accessibility — rem-based typography respects browser font-size preferences in a way pixel sizes do not. Hundreds of values need converting; doing the maths for each one in your head is a recipe for off-by-0.0625 errors.

You’re reading a colleague’s commit and they used padding: 1.25rem. Is that 16, 20, or 24 pixels at the project’s base? At a 16px base it is 20. At a 14px base it is 17.5. The tool resolves this in the half-second it takes to type the number, which is faster than asking and waiting for an answer.

You’re sketching out a new design system’s spacing scale and need to know what each candidate value would feel like in real units. Three baseline scales (0.25rem, 0.5rem, 1rem… versus 4px, 8px, 16px… versus a custom modular scale) need quick conversion to compare.

You’re working with a Figma file specified in pixels but exporting to a Tailwind 4 codebase that prefers rems. Each measurement needs translation; doing this in batch alongside the design handover is faster than translating during implementation.

You’re writing CSS for an embedded widget that lives inside someone else’s site, and you cannot control the host’s root font size. Using rem in this context produces unpredictable results — the converter helps you find equivalent fixed-pixel values to use instead.

What you need to know

CSS units split into absolute and relative. Pixels (and the rarely-used cm, mm, in) are absolute — they always render at the same size. Relative units (em, rem, %, vh, vw) compute against a reference. em references the parent element’s font-size, which means an em value can mean different things in different parts of the page. rem references the root (<html>) font-size, which is consistent across the document. Percentage in font-size context behaves like em.

The conversion rests on one assumption: the root font-size. Default browsers use 16px. Projects that override this do so on the <html> element (font-size: 14px or font-size: 100%, the latter equivalent to 16px). The tool exposes that base size so you can match your project’s setting. Setting it to 10px is a common shortcut — “1rem = 10px” makes mental conversion easy at the cost of some accessibility headaches around browser zoom interactions.

Modern best practice in 2026: use rem for typography, padding, margin, and most layout dimensions. Use px for borders, hairlines, and small fixed details (icons in fixed-position UI, separator lines). Use em sparingly — em compounds, which means font-size: 1.2em inside font-size: 1.2em inside font-size: 1.2em produces unexpected sizes, and most modern systems have moved away from em for this reason.

Why rem over px for typography? Browser users can adjust their default font size (in browser settings), and rem-based typography scales with that setting. Pixel-based typography ignores it. Users who increase their default font size for accessibility reasons (vision, screen distance, etc.) get a properly-scaled experience on rem-based sites and a broken experience on pixel-based ones.

Tailwind 4 internally uses rem for almost every spacing and sizing utility, with a default base of 16px. Other major systems (shadcn/ui, Radix, Material UI) follow the same convention. If you’re working in any of these, rem is already the lingua franca.

Frequently asked questions

How do I convert px to rem?

Divide the pixel value by the root font size. At a 16px base, 24px = 24÷16 = 1.5rem. At a 10px base, 24px = 2.4rem. The base size matters; default to 16px unless the project overrides it.

What’s the difference between em and rem?

em is relative to the parent element’s font-size. rem is relative to the root element’s font-size. Em compounds (nested ems multiply); rem does not.

Should I use px or rem for fonts?

Rem. It respects user font-size preferences set in browser settings, which matters for accessibility. Pixel-based fonts ignore those settings.

Why does my page font-size change unexpectedly with em?

Em compounds. A child element with font-size: 1.2em inside a parent with font-size: 1.2em produces 1.44x the grandparent’s size, not 1.2x. Switch to rem to break the inheritance chain.

Is it bad to set the root font-size to 10px?

Not bad, but has implications. The “1rem = 10px” shorthand makes mental conversion easy, but it also disables the browser’s default zoom behaviour relative to the standard 16px assumption — users with browser-level font-size adjustments get unexpected results. Tailwind and modern frameworks default to 16px for this reason.

What unit should I use for margin and padding?

Rem in modern systems. The argument matches typography: spacing should scale with browser font-size preferences for the same accessibility reasons. Pixel-based spacing creates inconsistencies between text size and surrounding whitespace.

Does my root font-size affect images?

No — images render at their pixel dimensions regardless of root font-size. Rem affects only properties that take rem as input. Image sizing uses width/height, which can be in any unit.

How do I make rem work with browser zoom?

Browser zoom affects all rendering, regardless of unit. Both px and rem zoom proportionally. The accessibility advantage of rem applies to font-size preferences (set in browser settings), not zoom.

Common problems

Problem: My converted rem values produce visibly different sizes from the original px values.

The base font-size in the project differs from the calculator’s setting. Check the actual <html> font-size in DevTools — if your project overrides the default 16px, set the calculator base to match. The conversion is exact; the discrepancy is in the assumption.

Problem: A 1.5rem padding looks correct in development but wrong in production.

The production CSS is overriding the root font-size somewhere — often a reset stylesheet or inherited framework style. Inspect the <html> element’s computed font-size to confirm. The fix is to set the base explicitly at the root rather than letting frameworks override silently.

Problem: Browser zoom and font-size adjustments produce different visual scaling on different parts of the page.

Mixing px and rem within the same component creates this. A button with padding: 12px and font-size: 1rem scales the text but not the padding under font-size adjustments — visible as misaligned text within the button. Standardise on rem within any given component to avoid this.

Problem: Em-based components in nested layouts produce sizes I cannot predict.

Em compounds. Replace em with rem throughout nested components, and the predictability returns. Em has legitimate uses (relative sizing within a single component), but mixing em across layout layers is the cause of most “why is this size wrong?” bugs in production CSS.

Quick guides

Tailwind CSS: Defaults to a 16px root. The spacing utilities (p-4, m-2, etc.) translate to rem internally — p-4 is padding: 1rem (16px), p-8 is padding: 2rem (32px). The default scale is 4px increments.

Sass / Custom properties: Define the base as a variable: $base-font-size: 16px in Sass, or --base-font-size: 16px as a custom property. Build a mixin or function (@function rem($px) { @return $px / $base-font-size * 1rem }) so the codebase converts at compile time.

Vanilla CSS at scale: Set font-size: 100% on <html> (matches the user’s browser default) and use rem everywhere. This is the most accessibility-respectful approach and survives any browser configuration.

Tips

  • Use rem for typography, padding, and margin where you want the design to scale with browser font-size preferences. Use px for borders and small fixed elements where pixel-perfect rendering matters.
  • The 16px default is the right default. Overriding to 10px is convenient for quick mental conversion but disables some browser zoom behaviour — only worth doing if you also test that case.
  • “em” is rarely the right choice in 2026 design systems. It compounds — an em inside an em inside an em produces sizes nobody can predict. Most modern CSS sticks to rem and px.
  • Percentage is interchangeable with em in font-size context, but they diverge for other properties. width: 50% is parent-relative; width: 0.5em is font-size-relative. They are not the same.
  • Memorise common conversions: 16px = 1rem, 24px = 1.5rem, 32px = 2rem, 12px = 0.75rem. After that, the rest fall out by mental fraction.
  • For new design systems, define a 4px-based scale and convert to rem at build time. The 4px increment is a convention that survives translations between design tools and code.

Related tools in this suite

The natural pairing is the Aspect Ratio Calculator — both convert between linked numerical relationships, both come up when sizing layout components. The Border Radius Generator is the third side of that “tuning numbers visually” group — radius scales benefit from being expressed in rem too, for the same reason.

Take it further

The bigger question is whether your CSS has a coherent scale at all. Ad-hoc px values scattered through a stylesheet (padding: 13px, font-size: 17px) are the symptom of a system that grew without one. The systems we build bring those values into a documented scale (typography sizes, spacing tokens, line heights) so the conversion question stops coming up — you reach for --space-3 rather than mentally converting 24px.