When should I use rem instead of px in CSS?

Use rem for font sizes and component spacing so your layout scales proportionally when users change their browser's default font size. This is key for accessibility. Use px for things that should never scale — borders, outlines, small decorative elements.

What is the difference between em and rem?

rem (root em) is always relative to the root element's font size — usually 16px. em is relative to the current element's (or its parent's) font size. rem is more predictable because it doesn't cascade. em can compound in nested elements, which leads to unexpected sizes.

How do vh and vw units work?

1vh = 1% of the viewport height, 1vw = 1% of the viewport width. They're useful for full-screen layouts and responsive sizing without media queries. The catch: on mobile browsers, the address bar affects vh, which can cause layout jumps.

What does 100% mean in CSS?

The % unit is relative to the parent element's value for the same property. For width, 100% means 100% of the parent's width. For font-size, 100% means 100% of the inherited font size. This context-dependence is why % can be confusing.

Is there a tool to convert CSS units automatically?

Yes — our CSS Units Converter lets you enter any value, pick the source unit, and see all equivalent values instantly. You can also customize the base font size and viewport dimensions for accurate real-world conversions.

CSS Units Converter: Stop Guessing and Start Converting

The Handoff Problem Nobody Talks About

Picture this: a designer sends you a Figma file. Every measurement is in pixels — 24px font size, 16px padding, 48px margin. You copy those values into your CSS. The layout looks right on your machine.

Then a colleague who bumps their browser's base font size to 20px for readability loads the page. Your carefully specified 24px heading stays at exactly 24px while everything around it shifts. The carefully balanced hierarchy that worked at 16px base falls apart. The designer is confused. You're confused. Nobody wins.

This isn't a rare edge case. It's what happens when you treat every CSS measurement as an absolute value when most of them should be relative. The fix is understanding which unit to reach for and when — and having a reliable way to convert between them.

That's exactly what the CSS Units Converter is built for. But before we get to the tool, let's build the mental model from scratch.

The Units Glossary

CSS has more measurement units than most developers realize. Here's what each one actually is:

px — Pixels

The pixel is the baseline most of us learned CSS with. 1px is nominally one pixel on a standard-density screen. On high-DPI (retina) displays it gets scaled by the device pixel ratio, so 1px might actually render as 2 or 3 physical pixels — but the browser handles that math, not you.

The key property of px: it is fixed. It doesn't respond to user preferences, parent elements, or anything else in the document. This is sometimes exactly what you want (a 1px border should always be 1px) and sometimes exactly the problem (a 16px font size ignores a user who needs larger text).

rem — Root Em

rem stands for "root em." One rem equals the font size of the <html> element — typically 16px in most browsers by default, but crucially, it respects whatever the user or your CSS sets that root size to.

If a user sets their browser's default font size to 20px, 1rem is 20px everywhere on the page. Your entire layout scales up proportionally. That's a significant accessibility win.

1.5rem at 16px base = 24px. Same ratio, different base, predictable everywhere.

em — Em (the slippery one)

em is similar to rem but relative to the current element's font size, not the root. This sounds fine until you start nesting elements.

If an element has font-size: 1.2em and it's inside a parent with font-size: 1.2em, the child ends up at 1.2 × 1.2 = 1.44em relative to the root. Stack three levels deep and you have 1.728em. This compounding effect is the em inheritance trap — more on that in a dedicated section below.

vh / vw — Viewport Height and Width

1vh = 1% of the browser viewport's height. 1vw = 1% of the viewport's width. These are genuinely useful for full-screen sections and fluid typography that adapts to screen size.

The caveat: on mobile, the browser's address bar is sometimes visible and sometimes hidden. This changes the viewport height, which makes 100vh elements jump in height as the user scrolls. The CSS Working Group added dvh (dynamic viewport height) to handle this, but browser support is still catching up.

% — Percent

Percent is context-dependent in a way that trips up even experienced developers. width: 50% means 50% of the parent's width. font-size: 120% means 120% of the inherited font size (behaves like em). margin-top: 10% is 10% of the containing block's width — not height, which surprises most people the first time.

pt, cm, mm — Print Units

These are the physical measurement units. They map to real-world dimensions at a standard screen resolution but are almost exclusively useful for print stylesheets. 1pt = 1/72 of an inch. 1cm = 10mm. You'll rarely write these in a web stylesheet unless you're formatting something for printing.

The Base Font Size Mental Model

Here's the thing most tutorials skip: browsers don't just have a default font size, they have a user-configurable default font size. Chrome, Firefox, and Safari all let users set this in their preferences. Historically, the default across browsers has been 16px, and that's what most conversion tables assume.

The math that follows:

1rem = 16px  (at browser default)
0.75rem = 12px
1.25rem = 20px
1.5rem = 24px
2rem = 32px

Some design systems set html { font-size: 62.5%; } to make 1rem = 10px, which makes the arithmetic easier (1.6rem = 16px). I've used this trick and I'll admit it works — but it silently breaks components that assume the browser default, and it doesn't actually improve accessibility. If you inherit a codebase using this trick, check for it early.

The bottom line: rem is predictable because it always anchors to one value. That's why it's the right choice for most typographic and spacing decisions.

Decision Framework: Which Unit for What

This is the part of every CSS article where the advice gets generic. I'll try to be concrete instead.

Font sizes → rem

Always. There's very rarely a good reason to set font-size in px. If someone changes their browser's default, you want your text hierarchy to stay intact. rem does this for free.

body { font-size: 1rem; }       /* 16px at default */
h1   { font-size: 2.5rem; }     /* 40px at default */
h2   { font-size: 2rem; }       /* 32px at default */
small { font-size: 0.875rem; }  /* 14px at default */

Component spacing → rem or px depending on intent

Padding and margin on components is a judgment call. If the spacing is meant to scale with text (like the vertical padding on a button), use rem. If it's a fixed visual gap that shouldn't grow (like the gap between icon and text inside a button), px is fine.

.button {
  padding: 0.75rem 1.5rem;  /* scales with font size */
  border: 1px solid currentColor;  /* always 1px */
  border-radius: 4px;  /* fixed visual property */
}

Full-screen and viewport-relative layouts → vh/vw

Hero sections, modals that should take a percentage of the screen, sticky sidebars — these belong in viewport units.

.hero {
  min-height: 100vh;  /* full-screen section */
  width: 100vw;
}

Just watch the mobile address bar issue. If you're building something where pixel-perfect full-screen behavior matters on mobile, dvh is worth the polyfill cost.

Print-specific styles → pt/cm/mm

If you have a @media print section, switch to physical units there. Printers think in inches and points, not screen pixels.

@media print {
  body { font-size: 12pt; }
  .page-break { page-break-after: always; }
}

"Sized to content" → percentage or auto

For widths that should respond to their container, % is often the right call. Just remember the mobile quirk with margin percentages being width-based.

The Em Inheritance Trap (With a Real Example)

Let me show you exactly why em in font sizes gets dangerous.

Say you're building a card component with some nested text:

.card { font-size: 1.2em; }
.card .meta { font-size: 0.9em; }
.card .meta .timestamp { font-size: 0.85em; }

If the parent of .card has font-size: 16px (1rem), here's what you actually get:

.card → 16px × 1.2 = 19.2px
.card .meta → 19.2px × 0.9 = 17.28px
.card .meta .timestamp → 17.28px × 0.85 = 14.688px

None of those numbers are what you probably intended. You were probably thinking "a little smaller than normal for meta, even smaller for timestamps." What you got instead is a compounding mess that's hard to debug without a calculator.

The same styles with rem instead:

.card { font-size: 1.2rem; }   /* 19.2px */
.card .meta { font-size: 0.9rem; }  /* 14.4px */
.card .meta .timestamp { font-size: 0.85rem; }  /* 13.6px */

These numbers correspond directly to the root font size. No compounding. Much more predictable.

The one place em is genuinely useful: when you want something to scale relative to the element's own font size, like line-height: 1.5em (1.5× the element's font size) or padding: 0.5em on a button where the padding should grow proportionally if the button's font size is changed.

Conversion Reference Table (16px Base)

px	rem	em (no inheritance)	pt
10px	0.625rem	0.625em	7.5pt
12px	0.75rem	0.75em	9pt
14px	0.875rem	0.875em	10.5pt
16px	1rem	1em	12pt
18px	1.125rem	1.125em	13.5pt
20px	1.25rem	1.25em	15pt
24px	1.5rem	1.5em	18pt
32px	2rem	2em	24pt
40px	2.5rem	2.5em	30pt
48px	3rem	3em	36pt

These assume 1rem = 16px. If your root font size is different, every conversion changes. That's precisely why the tool exists.

How the CSS Units Converter Works

The CSS Units Converter handles a problem that a static table can't: what if your base font size isn't 16px? What if your viewport is 1440px wide and you need exact vw values?

The tool lets you:

Enter any numeric value
Select the source unit (px, rem, em, vh, vw, %, pt, cm, mm)
Set your base font size (defaults to 16px, adjustable)
Set your viewport dimensions (for accurate vh/vw conversions)
See all equivalent values instantly — no need to calculate each one manually

This is the workflow I use when translating Figma specs (which are always in px) into rem values for a design system. Enter the px value, read the rem equivalent, done. It's also useful for sanity-checking when you get a layout that's slightly off — plug in the px value from DevTools and compare it to what the rem should be.

One edge case the tool handles gracefully: em values displayed are relative to the configured base font size (i.e., assuming no inheritance). If you have inheritance in play, you'll need to account for the compounding yourself — or just switch to rem.

Quick Tips for Tailwind CSS Users

Tailwind shows pixel values in its documentation (e.g., text-xl is described as 1.25rem / 1.75rem but class names sometimes list pixel equivalents). A few things worth knowing:

Tailwind uses rem internally. text-base is 1rem, text-lg is 1.125rem, text-xl is 1.25rem. If you're setting font-size manually to match a Tailwind class, use rem — not the pixel number from the docs.

The spacing scale is also rem. p-4 is 1rem (16px at default). p-8 is 2rem (32px). When your designer says "24px padding," that's p-6 in Tailwind (1.5rem). Our converter helps bridge the gap when you need to match specific design values to Tailwind classes.

Custom base font sizes work fine with Tailwind. If you set html { font-size: 18px }, all Tailwind rem values recalculate automatically. Run the converter with base 18px to double-check your custom values.

Wrapping Up

CSS unit choice isn't trivia — it's the difference between a layout that adapts gracefully and one that breaks for a subset of your users. The rules of thumb:

px for fixed visual properties (borders, outlines, specific decorative elements)
rem for font sizes and scalable spacing — your accessibility default
em sparingly, where you want proportional scaling to the element's own size
vh/vw for viewport-relative layouts, with dvh for mobile full-screen accuracy
% for container-relative sizing, keeping the width-based margin quirk in mind
pt/cm/mm only in print stylesheets

And when you need to convert between any of these, the CSS Units Converter has you covered — with adjustable base size and viewport dimensions so your conversions match your actual project, not a textbook example.

The goal is less time doing mental math in your head and more time building things that actually work.