How the converter works
Enter a value in any CSS unit — px, rem, em, %, vw, vh, pt, pc, in, cm, or mm — and see its equivalent in every other unit at once. Relative units only mean something in context, so the context is adjustable: set the root font size that rem resolves against, the parent font size for em, the parent dimension for percentages, and the viewport size for vw and vh. The defaults (16 px root font, 1920×1080 viewport) match the most common desktop baseline.
That context-awareness is the point. “1.5rem” is 24 px on a default page but 15 px on a site using the 62.5% root-size trick — a plain lookup table cannot tell you which, and this converter can.
rem to px: the arithmetic
One rem equals the root element’s font size — 16 px in every mainstream browser unless a stylesheet overrides it. So converting rem to px is a multiplication, and px to rem a division by the same number. The values you will reach for constantly:
- 0.25rem = 4px — the classic spacing-scale step
- 0.5rem = 8px, 0.75rem = 12px, 0.875rem = 14px
- 0.625rem = 10px — a common “fine print” size
- 1rem = 16px — the browser default
- 1.125rem = 18px, 1.25rem = 20px, 1.5rem = 24px
- 2rem = 32px, 2.5rem = 40px, 3rem = 48px
px vs rem vs em: which unit to use where
Use rem for font sizes, spacing, and layout dimensions you want to scale with the user’s preferences. When someone raises their browser’s default font size — a genuine accessibility setting, not an edge case — everything in rem scales with it, while everything in px stays fixed and progressively breaks the design.
Use em when a component should scale with its own text: padding on a button set in em grows if the button’s font does, keeping proportions intact. The trap is nesting — em compounds through the tree, so 1.2em inside 1.2em is 1.44 times the base, which is why component-internal spacing is em’s sweet spot and page-level sizing is not.
Pixels still have a place: hairline borders, box shadows, and other details that should render identically regardless of text scale. The practical rule that falls out — type and spacing in rem, self-scaling component detail in em, fixed visual detail in px.
Viewport units and fluid layouts
vw and vh are percentages of the viewport itself: 1vw is 1% of its width, 100vh its full height. They power full-bleed hero sections, aspect-ratio boxes, and fluid typography that interpolates between sizes with clamp() instead of jumping at breakpoints. Because they resolve against a live viewport, the converter lets you set the viewport dimensions — check a value against 375×667 for a phone and 1920×1080 for desktop and you have the endpoints of your clamp() range.
One caveat worth knowing: on mobile browsers, 100vh has historically included the space behind collapsing toolbars, causing content to overflow beneath the fold. The newer svh/lvh/dvh units exist precisely for that; when a “full-height” section scrolls unexpectedly on a phone, that is the first thing to check.
The 62.5% trick, and why to use it carefully
A long-standing convention sets html { font-size: 62.5% }, making 1rem equal 10 px so that mental conversion becomes trivial: 1.6rem is 16 px, 2.4rem is 24 px. It works, and plenty of large codebases use it — but it also means every third-party embed and copy-pasted snippet built against the 16 px assumption renders at 62.5% of its intended size until patched. If you inherit such a codebase, set the converter’s root font size to 10 and every rem value on the site converts correctly.
Points, inches, and the print units
CSS defines its physical units against a reference: 1in is exactly 96 px, 1pt is 1/72 of an inch (so 12pt = 16px), 1pc is 12 points, and cm/mm follow from the inch. On screen these are just fixed ratios — a “point” does not measure a physical point on your monitor — but in print stylesheets they map to real paper distances, which is where pt for type and cm/mm for margins genuinely belong.