CSS Unit Converter

CSS units fall into two families. Absolute units — px, pt, pc, in, cm, mm — are fixed physical or near-physical sizes: 1px is one device-independent pixel (1/96th of an inch in CSS terms), and the physical units map directly to real-world measurements. Relative units — em, rem, %, vh, vw, ch — resolve against something else in the document: a font size, a container, or the viewport.

The distinction exists because screens vary wildly in pixel density and viewing distance. Absolute units give you precise control — a 1px border is exactly one pixel line — but they don't scale when the user needs bigger text. Relative units trade that precision for flexibility: they adapt to the user's font-size preferences, the layout context, or the device's viewport, which is the foundation of responsive, accessible design.

One px (pixel) in CSS is not one device pixel — it's a reference pixel of 1/96 inch, scaled by the browser so that a given CSS length looks roughly the same physical size on a 1080p monitor and a 4K laptop. This is why CSS px sometimes seems to differ from device pixels and from image pixels, and why high-DPI screens can render crisp text: the browser maps multiple device pixels to each CSS px.

em is relative to the current element's font size: with a 16px font, 1.5em padding is 24px. Nested elements compound this — a child with font-size: 1.5em inside a parent that's already 1.5em ends up at 2.25× the root size. rem always resolves against the root (html) font size, so 1rem is 16px (by default) no matter the nesting depth. That predictability is why rem is the recommended unit for font sizes and most spacing.

Viewport units are percentages of the browser window: 1vw is 1% of the viewport width, 1vh is 1% of its height, and vmin/vmax pick the smaller or larger of the two dimensions. They're ideal for full-bleed layouts — height: 100vh is exactly one screen — and for fluid typography that scales with the window.

Two gotchas matter in practice. First, vh on mobile browsers is famously unstable: the address bar showing and hiding changes the visible height, so 100vh can leave content cut off or add phantom scroll area — dvh (dynamic viewport height) fixes this where supported. Second, viewport units have no minimum or maximum by default, so a 100vw element with a scrollbar can overflow horizontally; combining them with min()/max()/clamp() keeps layouts sane.

The practical consensus: rem for font sizes and most spacing (predictable, accessibility-friendly), px for borders, shadows and hairlines where you want an exact fixed thickness, % for widths and layouts that should track their container, and em for spacing that should scale with its own element — like padding around a heading that uses em-based margins, so the spacing grows if the heading is bumped up in size.

ch is the underrated workhorse for text: 1ch is the width of the "0" glyph in the current font, so max-width: 70ch sets an ideal measure (line length) for reading regardless of font size — it scales automatically. Container query units (cqw, cqh, cqi) extend the idea to components: sizes relative to the nearest query container, so a card's padding scales with the card's own width, not the viewport.

The accessibility case for rem/em over px is concrete: browsers let users set a default font size to compensate for vision needs, and px-based layouts ignore that preference entirely — every px length stays exactly as coded. Relative units honor it: bump the root font size from 16px to 20px and every rem-based size in the document scales up by 25%, keeping the design's proportions intact.

The one caveat is compounding: em-based margins nested inside em-based font sizes multiply, which is why accessibility guidance favors rem for font sizes and reserves em for components whose internal spacing should scale with their own text. And for users who zoom the page (Ctrl/Cmd +), percentage-based and viewport layouts generally hold together better than fixed-px grids.