CSS REM vs PX: when to use which (Real UI Cases)

A practical guide to choosing rem or px for typography, spacing, borders, and responsive UI—plus copy-paste patterns and a px to rem converter workflow.

TL;DR

Use rem for anything that should scale with user settings: font sizes, most spacing, and many layout paddings.
Use px for things that should stay visually consistent: borders, hairlines, shadows, and some icon strokes.
Most teams end up with a hybrid: typography + spacing in rem, fine detail in px.

If you want quick conversions while working, keep a px to rem converter open and treat it as part of your UI workflow.

What px and rem actually mean

px (CSS pixel)

px is a fixed unit in CSS. It’s not always a physical pixel, but it behaves like a fixed visual unit relative to the rendering environment.

rem (root em)

rem is relative to the root element (html) font size.

If the browser’s default is 16px, then:

1rem = 16px
0.875rem = 14px
1.25rem = 20px

And the conversion is:

rem = px / rootFontSize
px  = rem * rootFontSize

Why rem matters (accessibility + consistency)

Users can change:

browser default font size
zoom level
OS text scaling (in some environments)

If your UI uses rem for typography and core spacing, the UI adapts more naturally to these settings. This tends to reduce “text too small” issues and improves usability without adding responsive breakpoints everywhere.

Practical rules: what should be rem vs px?

Typography: prefer rem

Fonts are the most user-sensitive part of UI.

html { font-size: 16px; } /* default; often unnecessary */
body { font-size: 1rem; } /* 16px */
h1 { font-size: 2rem; }   /* 32px */
small { font-size: 0.875rem; } /* 14px */

When px might be OK: tiny UI labels that must match a pixel-perfect spec in a controlled environment (e.g., kiosk), but it’s usually still better to use rem.

Spacing (padding/margin/gap): mostly rem

Spacing generally should scale with typography.

.card {
  padding: 1.25rem;  /* 20px */
  gap: 0.75rem;      /* 12px */
  border-radius: 0.75rem; /* 12px */
}

A common pattern is tying spacing steps to a typographic rhythm, so the whole UI grows or shrinks together.

Layout widths: depends

For layout, you often want fluid units (%, fr, vw) or constraints (min(), max(), clamp()).

Use rem for max-width constraints that should scale with text size (reading comfort).
Use fluid units for container behavior.

.container {
  width: min(100% - 2rem, 70rem); /* max width scales with rem */
  margin-inline: auto;
}

Borders & hairlines: px

Borders should usually remain visually crisp.

.button {
  border: 1px solid #ddd;
}

If you use rem borders, they can become comically thick at large font scales.

Shadows: px

Shadows are visual details; keep them stable.

.card {
  box-shadow: 0 8px 24px rgba(0,0,0,0.12);
}

Icons and strokes: usually px

SVG strokes often look best in whole pixels.

Use px for stroke-width
Use em/rem for icon size if you want it to track font size

.icon {
  width: 1.25rem;
  height: 1.25rem;
}
.icon path {
  stroke-width: 1.5px;
}

Real UI cases

Case A: Button sizing that scales with user font size

Use rem for padding + font, px for border.

.button {
  font-size: 1rem;
  padding: 0.625rem 1rem; /* 10px 16px */
  border-radius: 0.625rem;
  border: 1px solid #ccc;
}

Case B: Card component with a stable “detail layer”

Rem for structure, px for polish.

.card {
  padding: 1.25rem;
  border-radius: 0.875rem;
  border: 1px solid #eee;
  box-shadow: 0 10px 30px rgba(0,0,0,0.08);
}

Case C: Typography that adapts but doesn’t explode on large screens

Use clamp() with rem so it respects user scaling.

h1 {
  font-size: clamp(1.75rem, 2vw + 1rem, 3rem);
  line-height: 1.1;
}

Case D: “Pixel-perfect” table but readable

Keep grid lines px, text rem.

.table {
  font-size: 0.9375rem; /* 15px */
  border-collapse: collapse;
}
.table td, .table th {
  padding: 0.625rem; /* 10px */
  border-bottom: 1px solid #eee;
}

Should you set `html { font-size: 62.5% }`?

You’ll see this a lot because it makes 1rem = 10px (if the default is 16px), so designers can mentally divide by 10.

Pros:

faster mental math (14px → 1.4rem)

Cons:

can surprise users and some devs
can interact oddly with browser defaults / user settings

If you do it, do it intentionally and document it. Many modern teams keep the default (16px) and use a px to rem converter during implementation instead.

A simple workflow: design in px, ship in rem

Most design tools output px. That’s fine:

Keep design specs in px (easy to communicate).
Convert to rem during implementation:
- rem = px / 16 (or your chosen base)
Use rem for: fonts, spacing, radii, container max widths
Use px for: borders, shadows, hairlines, tiny strokes

If you want it frictionless, add a px to rem converter and rem to px converter link near your typography section, so visitors (and you) can translate values instantly.

Quick conversion cheat sheet (base 16px)

12px → 0.75rem
14px → 0.875rem
16px → 1rem
18px → 1.125rem
20px → 1.25rem
24px → 1.5rem
32px → 2rem
48px → 3rem

FAQ

Is rem always better than px?

No. rem is better for user-scaled UI (typography/spacing). px is better for fine visual details (borders/shadows).

Should I use em instead of rem?

Use em when you want something to scale relative to the current component’s font size (e.g., an icon next to text). Use rem for global consistency.

You can use our em to px converter online tool to see how em units compound in nested elements.

Does rem help SEO?

Indirectly. It can improve usability and accessibility, which can reduce pogo-sticking and improve engagement. SEO impact is not “rem ranks higher,” it’s “better UX can help overall.”