Em to Px Converter
Convert em to px (and back) with explicit parent font size context and a compounding visualizer that shows how em multiplies through nested elements — so you don't get burned by the rem-vs-em confusion.
Why Use Em to Px Converter?
Em is the unit people most often confuse with rem, and the bug only shows up after the design ships and a copywriter pastes a long heading inside a card inside a section. Predicting that compounded size by hand is a stack of multiplications; this calculator does it on the fly. It also makes the rem-vs-em decision concrete — when you see the L4 cumulative em on the visualizer, the answer to "should this be em or rem?" is usually obvious.
How to Use Em to Px Converter
- Pick Em → Px (default) or Px → Em with the direction tabs.
- Enter your value — the result calculates instantly.
- Set the Parent Font Size to match the directly-containing element. Em is parent-relative, NOT root-relative — this is the most common em mistake, so the parent picker is front-and-center.
- Use the Em Compounding Visualizer below to see how a single em factor multiplies across 4 levels of nesting, starting from a 16px root.
- Copy the result with one click.
Worked Examples
Component-relative button padding
0.5em padding inside a 14px button
0.5em × 14 = 7px
Em is the right call here because if the button text grows, the padding grows proportionally.
The compounding trap
1.2em factor at every level for 4 levels (root 16px)
L4 = 16 × 1.2⁴ = 16 × 2.07 = 33.18px
Far larger than a designer expects. Switch to rem at the deeper levels, or normalize font-size at one level.
Reverse: what em is 24px under a 20px parent?
24px, parent 20px
24 ÷ 20 = 1.2em
Useful when porting a design system that mixes em-based component tokens with px-based design specs.
About Em to Px Converter
The Em to Px Converter helps you translate between em values and pixels with the right parent-element context — the part most converters get wrong. Em units are relative to the font-size of the parent, which means nesting an em inside another em compounds the multiplication. A 1.2em link inside a 1.2em paragraph inside a 1.2em section inside a 1.2em body becomes 2.07em (33px) of the root — almost certainly not what you intended. This calculator shows the cumulative em factor and computed pixel size at every level of nesting so you can see the compounding before it ships to production. It runs entirely in your browser; no values are sent anywhere.
Troubleshooting & Common Issues
Em values look bigger than expected on nested elements
Em multiplies through every parent that has its own font-size. If your component has `1.2em` set on the wrapper AND `1.2em` on the heading inside, the heading is `1.44 × root font size`. Use rem to size relative to the root and avoid compounding, or reset font-size to a fixed value (`1rem`, `1em`) at one of the levels.
Result doesn't match what's in dev tools
Dev tools show the *computed* pixel value, which factors in every cascading font-size up the tree. This converter takes a single parent context. To match dev tools exactly, set the converter's parent to the computed font-size shown for the parent element, not the value declared in CSS.
Should I use em for padding/margin?
If you want spacing to scale with font size (e.g., a button whose padding grows with the label), em is correct. If you want spacing to be consistent regardless of font (e.g., card gutters), use rem. For Tailwind users, the entire spacing scale is rem-based by default — em is the exception.
Em in line-height doesn't compound
Correct — line-height is special. When `line-height` is unitless (e.g., `1.5`), it's inherited as a multiplier per element, not as a computed value. When line-height is in em (e.g., `1.5em`), it computes to a fixed pixel value at the declaration site and is inherited as that pixel value, which can produce unexpected line spacing in nested elements with different font sizes. Prefer unitless line-height.
Frequently Asked Questions
What's the difference between em and rem?
Em is relative to the PARENT element's font size — it compounds when nested. Rem is relative to the ROOT element's font size — it never compounds. Use rem for predictable global sizing and em when you specifically want a value to scale with the local font context (component-relative padding, line-height-aware spacing).
Why does em compound and rem doesn't?
Em resolves at every cascade level — a child's em is computed against the child's parent font size, which itself may be in em. Rem always resolves against the html element's font size, which doesn't change as you descend the tree. Compounding is em's defining behavior, not a bug.
When should I use em over rem in 2026?
Three cases: (1) component-internal spacing that should scale with the component's font size, like button padding; (2) media queries where you want breakpoints to track user font preferences (some teams prefer em over rem here for historical Safari quirks, though both work in modern browsers); (3) line-spacing on a per-component basis. For everything else, rem is the safer default.
Does em work in media queries?
Yes. Both em and rem in media queries resolve against the browser's default font size (typically 16px), NOT the html element's font-size — this is a Safari-era quirk that's now standardized. So `@media (min-width: 48em)` always means 768px regardless of any `html { font-size }` you set.
What is 1em in pixels?
It depends on the parent element's computed font-size. With the default 16px root and no overrides, 1em on a top-level element equals 16px. Nested under a `font-size: 20px` parent, 1em equals 20px. Always check the parent's computed font-size in dev tools to know the absolute value.
Can I mix em and rem in the same project?
Yes, and it's a common pattern. Use rem for the design system's global tokens (heading scale, body text, layout gaps) and em for component-relative sizing where local scaling is the goal. Keep the convention consistent across components or you'll lose the ability to predict how a change ripples.
Does em affect accessibility?
Indirectly. Like rem, em scales with the user's font-size preference because it ultimately resolves to a multiple of the root font-size. The risk is unintended compounding pushing text past readable sizes at large user font settings. Rem is safer for accessibility-critical sizing; em is fine for component-level details that already test well at 200% zoom.
Is my data sent to a server?
No. The Em to Px Converter runs 100% client-side in your browser. No data is transmitted anywhere.
Related Tools
Px to Rem Converter
Convert pixels to rem (and back) with a configurable root font size, copy-ready Tailwind class output, and a quick reference table of the most common front-end sizes.
Aspect Ratio Calculator
Calculate aspect ratios from dimensions, derive missing dimensions from a ratio + one side, and resize images proportionally. Includes 7 common-ratio presets, decimal output, and the modern CSS aspect-ratio property value.
Pixels to Inches Converter
Convert pixels to inches, centimeters, millimeters, and points at any DPI. Includes inches to pixels conversion and a precomputed reference table.
Was this tool helpful?