CSS Unit Converter: px, rem, em, %, pt, vw

A CSS pixel is not a pixel on your screen

The absolute units are locked to each other by definition: one inch is exactly 96 pixels, a point is a seventy-second of an inch, a pica is twelve points. That makes 1pt exactly 1.3333px and 1cm about 37.8px, always, on every device.

What none of them are is physical. On a display with twice the pixel density, one CSS pixel is painted with four hardware pixels, and on a phone the browser applies a further scale so text stays legible at arm's length. width: 1in does not measure an inch of glass. In a print stylesheet it does, which is the one place pt, cm and mm genuinely earn their place.

rem is somebody's setting

rem means the computed font size of the root html element. It is 16px because that is the browser's default text size — and that default is a preference the reader can change. Someone who has set 20px because 16 is hard to read gets every rem-sized thing on your page 25% larger. Everything you sized in pixels stays exactly as small as it was. That is the entire argument for rem in type, spacing and media queries, and it is a better argument than most style guides make.

It also means html { font-size: 16px } is worth avoiding. It overwrites the preference with your own number and quietly cancels the benefit for everyone who changed it.

The 62.5% trick, and what it costs

Setting html { font-size: 62.5% } makes 1rem equal 10px for a reader on the default, so 1.6rem reads as "16px" and the mental arithmetic disappears. It stays proportional to the user's setting, so it is not inaccessible by itself. The cost is that every inherited font size now starts at 10px: you have to reset the body, and any component library or third-party stylesheet sized in rem shrinks by more than a third. On a project you fully own it is fine. Inside someone else's design system it is a slow leak.

em compounds, and the exception that makes it confusing

em refers to the font size of the element itself — except on the font-size property, where it refers to the parent's. That single exception is why nested lists at 0.9em keep shrinking level by level, while padding: 1em on a button resolves against that button's own, already-scaled size. Used deliberately, that is the neatest way to build a component that scales as a unit: set one font size and let padding, gaps and radii follow in em. Used accidentally, it is where an hour goes.

Percent means a different thing on every property

There is no single reference for %. Width resolves against the containing block's width. Height resolves against its height, and only if that height is definite, which is why height: 100% so often does nothing at all. The one that surprises people: padding and margin percentages resolve against the containing block's width, including padding-top and margin-bottom. That is the mechanism the old padding-top: 56.25% aspect-ratio hack relied on, before aspect-ratio existed. The table above treats % as a percentage of font size, which is what it means on font-size and line-height.

Viewport units and their two famous bugs

1vw is one percent of the viewport width — and on desktop browsers with classic scrollbars that width includes the scrollbar. Set width: 100vw on a page that scrolls vertically and you get a horizontal scrollbar for free. On mobile the problem was height: 100vh was measured with the address bar hidden, so a full-height section had its bottom cut off. svh, lvh and dvh exist for that, measuring the small, large and dynamic viewport respectively. dvh is the one that follows the bar as it hides, which also means it can cause the layout to shift while you scroll.

Where this converter stops

px, rem, pt, the physical units and the viewport units are exact once you supply the four numbers. em and % are not: their real value depends on where the element sits in the cascade, and no converter can read your parent's computed font size for you — the answer is only as right as the number you typed in. ch and ex are missing on purpose, because they depend on the glyph metrics of the actual font (the advance width of "0" and the x-height), which change with every font file and cannot be derived from arithmetic. And the viewport figures are read from this window, which tells you nothing useful about a visitor's phone.

Last updated September 19, 2026