ColorKitFree em to px calculator
EM to PX, one nesting level at a time
This em to px calculator is free and needs no signup, and it asks for the nesting because em has no fixed pixel value: on font-size it is a ratio to the parent, so three innocuous declarations of 1.25em, 1.1em and 0.875em turn a 16px root into 19.25px rather than the 14px the last one appears to ask for. Set the root, add a level for each ancestor that declares a size, and every row shows what it inherited, what it produced and how far the running product has drifted. The panel underneath answers the other half of the question — em on padding, margin or letter-spacing measures against the element's own size, not its parent's.
- 100% free
- No signup
- Up to 8 levels
- Compounding per level
- Own size vs parent size
19.25px
×1.203 the root
htmlinherits nothing —16px<section>of 16px =20px×1.250<article>of 20px =22px×1.375<div>of 22px =19.25px×1.203
The same em somewhere other than font-size
This one does not use 22px, the size it inherited. Outside font-size, em is a ratio to the element's own computed size — 19.25px here — which is why a box can grow its padding by changing nothing but its type size.
Press Ctrl+V anywhere on the page to drop in a run of em values such as 1.25em 1.1em 0.875em — no need to click the field first.
How to convert em to px
Three steps for the case a two-field converter cannot answer: em inside em.
Start from the root, not from the element
Enter the pixel size of the html element and the chain builds downward from there. Every row shows the size it inherited on the left of the equals sign and the size it produced on the right, so the number you are chasing is always visible next to the number it came from rather than buried in a single total.
Add one row per element that declares a font-size
Nest one deeper for each ancestor between the root and the element you care about, and type the em factor each of them declares. Elements that set no font-size of their own are not levels — they inherit and change nothing, so leaving them out gives the same answer with less to read. A run of values pasted as 1.25em 1.1em 0.875em fills the whole chain at once.
Watch the multiplier column, then cut the chain
The badge on each row is the running product against the root, and it turns orange past double or below half, which is the point at which a chain has stopped doing what its author read into it. Switching any single level from em to rem re-bases that row on the root and everything below it inherits the corrected size — that switch is the fix, and it is one word in the stylesheet.
Technical specifications
| Chain depth | Up to 8 nested levels, each one taking the computed size of the level above it as its base |
|---|---|
| Compounding | 1.2em five levels deep is 2.488× the root — 39.81px from a 16px start, out of five declarations none of which looks large |
| Resolution rule | On font-size, em is the parent's computed size; on padding, margin, width, border-radius and letter-spacing it is the element's own |
| Chain break | Switching any level to rem re-bases it on the root, and the rows below it inherit from the corrected value |
| line-height | 1.5em computes to a length once and is inherited as that length; unitless 1.5 is inherited as a factor and recomputed per element |
| Input range | 0.01 to 10 per level, decimals accepted; a pasted run such as 1.25em 1.1em 0.875em fills every level in one go |
| Displayed precision | 2 decimal places per row, with the running multiplier to 3 — enough to show a 0.01px drift that a rounded chain hides |
| State | Nothing is stored: a reload returns the three-level starting chain, and no value you try leaves the page |
Frequently asked questions
What does 1.5em work out to in pixels?
One and a half times whatever the parent's font-size computed to, so there is no single answer. Under an unstyled parent at 16px it is 24px; inside a card whose own font-size is 0.875em of a 16px body, the parent is 14px and the identical declaration produces 21px. Em is a ratio rather than a size, and the thing it is a ratio to depends on where in the tree the element sits — which is why this page asks for a chain instead of one number.
Why does the same em value give two different pixel sizes on one page?
Because the two elements have different parents. This is em working correctly and it is also the single biggest source of surprise with the unit: a 0.875em caption is 14px under the body and 12.25px inside a card that already set 0.875em, and both are in the same stylesheet under the same class name. Reading the ancestor chain in the elements panel from the top down, rather than looking at the rule, is the way to settle it.
Does padding: 1em use the parent's font size or the element's own?
Its own. Font-size is the special case where em must look upward, since an element cannot be a ratio of itself; every other property — padding, margin, width, gap, border-radius, letter-spacing, text-indent — resolves em against the computed font-size of the element the declaration is on. That is the mechanism behind a button that grows its own padding when you change nothing but its type size, and it is worth knowing that the two ems on one rule can mean two different lengths.
How do I stop nested ems from compounding?
Re-base the level where the compounding starts hurting. Setting that element's font-size in rem ties it to the root and discards everything the chain accumulated above it, which is a one-word edit and the reason rem was added to the language. Two older workarounds still show up in stylesheets: a corrective ratio such as font-size: 1.25em on a child of a 0.8em parent, and the nested-list rule ul ul { font-size: 100% }, which stops the descent rather than reversing it.
Is line-height: 1.5em the same as line-height: 1.5?
No, and the difference only appears one level down. The em version is computed to a length once, on the element that declares it, and children inherit that fixed length no matter what size they end up at — so a 32px heading inside a 16px container inherits 24px of leading and the lines collide. The unitless version inherits as a factor and is recomputed against each element's own size, which is why every type guide tells you to write the number bare.
When is em the better choice than rem?
When the thing being sized should scale with its component rather than with the page. A button that sets its own font-size and then declares padding: 0.6em 1.2em stays in proportion at every size it is used, and one modifier class changing the font-size resizes the whole control; the same padding in rem would need a second override. The rule of thumb that survives contact with a real codebase: rem for the type scale, em for the space around type.
About em, inheritance and the compounding trap
The em is inherited from metal type, where it named the square body of the sort — as wide as the type was tall, and traditionally the width of a cast capital M. CSS keeps the name and drops the measurement: here 1em is simply the computed font-size, with no reference to any glyph in the font. That matters more than it sounds, because it means two families set at the same em look like different sizes on the page. Everything the eye judges size by — the x-height, the cap height, how much of the em square the letters actually occupy — varies by design and is not what the unit measures. It is the reason a body font swapped at constant size can suddenly read as too small, and it is worth checking against a heading-and-body pairing or in a side-by-side preview before blaming the number.
The compounding trap has a canonical example that predates most working developers. Give a list item li { font-size: 0.8em } and nest three lists: from a 16px start the first level renders at 12.8px, the second at 10.24px and the third at 8.19px, and nothing in the rule hints at any of it. The same arithmetic runs quietly in modern component trees whenever a card, a panel and a caption each shave a little off. It is not a bug in em; it is what a ratio to the parent means, and it only becomes a defect when the author was thinking in absolute sizes while writing relative ones. Chasing that difference by hand is what this chain replaces — and if you would rather size in a unit that cannot compound at all, converting the ramp to rem is the structural answer.
None of which makes em the wrong unit. It is the right one exactly where proportion should follow the component: padding around a label, the gap between an icon and its text, tracking on a heading, the offset of a tooltip arrow. Those all want to move when the type moves, and in em they do it with no extra declaration. The discipline that keeps this honest is to stop using em for font-size on nested elements while continuing to use it for the space around them, which removes the compounding without giving up what the unit is good at. Leading is the exception to the exception: line-height belongs unitless, because as a length it freezes on the element that declared it and stops tracking the sizes below.
Where the chain is calculated
Every number on this page is worked out by JavaScript running in the tab you are reading it in. Nothing you type, paste or open is uploaded, logged or kept, which is also why the tools carry on working after you disconnect from the network.