Loading CSS Unit Converter…
24px = 24px
Every unit below is the same computed length in this context.
| Unit | Value | Relative to |
|---|---|---|
| px | 24 | A fixed 1/96 inch, not a device pixel. |
| rem | 1.5 | Root font size |
| em | 1.5 | Font size in force here |
| % | 150 | Percentage basis |
| pt | 18 | 1/72 inch, so 12pt is 16px. |
| pc | 1.5 | 12pt, one pica. |
| in | 0.25 | 96px exactly. |
| cm | 0.635 | 37.795px exactly. |
| mm | 6.35 | 3.7795px exactly. |
| vw | 1.875 | 1% of viewport width |
| vh | 3 | 1% of viewport height |
| vmin | 3 | 1% of the smaller viewport side |
| vmax | 1.875 | 1% of the larger viewport side |
Applied 4 levels deep from a 16px root.
| Depth | Multiplier | em result | rem result |
|---|---|---|---|
| 1 | 0.9× | 14.4px | 14.4px |
| 2 | 0.81× | 12.96px | 14.4px |
| 3 | 0.729× | 11.66px | 14.4px |
| 4 | 0.6561× | 10.5px | 14.4px |
Each level multiplies the one above it, so the same declaration keeps shrinking. The rem column is the same value at every depth, because rem reads the root and ignores everything between.
A converter that answers “16px is 1rem” is only right until someone declares html { font-size: 62.5% }, after which 1rem is 10px and every figure has moved. The context is editable here: the root font size for rem, the font size in force for em, a separate basis for percentages, and the viewport for vw and vh. Change one and the table moves — 24px reads as 1.5rem against a 16px root and 2.4rem against a 10px one.
Conversion runs through px, because px is the only unit with a fixed definition to convert through: one CSS pixel is exactly 1/96 of an inch, by specification rather than by measurement, which is what makes 12pt reliably 16px on every device.
This is the difference that catches people, and the tool demonstrates it with a table you can drive. An em resolves against the font size already in force, so nesting multiplies: font-size: 0.9em on an element inside an element inside an element computes to 0.9 × 0.9 × 0.9, which is 0.729 of the root, or 11.66px from a 16px start. Nothing in the CSS looks wrong — every declaration says 0.9em — and the text keeps shrinking as the markup gets deeper, which is why a comment thread or a nested list is where it gets noticed.
A rem always resolves against the root, so the same value at any depth is the same size. That is the reason for the common convention: rem for type, so a heading is a fixed step regardless of where it sits, and em for the space around type, so padding: 0.75em and border-radius in em scale with whatever font size that component ends up using. Both behaviours are useful; the mistake is expecting one from the other.
Percentages are the least portable unit because their reference changes with the property. On font-size the basis is the parent’s computed font size, which makes 90% and 0.9em identical and gives it the same compounding behaviour. On width it is the width of the containing block. On line-height it is the element’s own font size.
The trap is vertical padding and margin: a percentage there resolves against the containing block’s WIDTH, not its height, which is the mechanism behind the old padding-bottom trick for fixed aspect ratios. Because the basis differs per property, it gets its own input here rather than being inferred.
pt, pc, in, cm and mm are all fixed ratios of px: 1in is 96px, 1pt is 4/3px, and 1pc is 12pt or 16px. None of them measures your screen. A CSS inch is not an inch on a monitor, so pt is meaningful in a print stylesheet and misleading anywhere else — in a design handoff it usually just means the file came from a print tool.
Viewport units are the opposite problem: they are exact but the viewport is not stable. 100vh on a phone is the height with browser chrome hidden, so a full-height section can sit taller than the visible area and scroll by the height of the address bar. The newer dvh, svh and lvh units exist for that, dvh tracking the dynamic viewport as the chrome appears and disappears. Convert with a viewport size you have actually measured rather than a nominal one.
It makes the arithmetic easy and it is a long-standing habit, but every unstyled element and third-party widget then starts at 10px. If you adopt it, set a body font size back up immediately and remember the root is 10px everywhere.
They behave identically there, and neither one follows your root font size: em and rem in a media query resolve against the browser’s initial font size, usually 16px. Declaring html { font-size: 20px } does not shift a 40em breakpoint.
Because mobile browsers size vh to the viewport with the toolbars retracted, so 100vh is taller than what you can see when they are showing. Use 100dvh, which tracks the dynamic viewport, and keep a vh fallback for older browsers.
A px font size ignores the reader’s default font size preference, which some people have deliberately raised, so rem is the safer default for type. Page zoom scales px as well, so it is a real limitation rather than a total failure.
There is no single answer — that is the point of the unit. It equals whatever font size applies where the declaration sits: the parent’s size when you are setting font-size, and the element’s own computed size for padding, margins, borders and gaps.