PX to REM converter

How to use this tool

Pixel values are absolute. When you set font-size: 16px, that text is locked at 16 pixels regardless of what the person reading it has asked for. Browsers let users raise their default text size — a setting that people with low vision genuinely rely on — and pixel-based text simply ignores it. Browser zoom still enlarges px text, so px alone is not an automatic failure of WCAG success criterion 1.4.4 (Resize Text), which requires text to scale to 200% without loss of content or function — but anyone who changes only their default font size, rather than zooming every site, gets nothing from a page sized in px.

Rem units solve this because they are relative to the root element's font size. If a visitor sets their browser default to 20px, every rem-based measurement on your page scales proportionally — your headings, body copy, spacing and layout all grow together, keeping the design's hierarchy intact instead of breaking it.

There is a second, practical benefit: consistency. Because rem always resolves against the same root value, 1.5rem is identical everywhere in your stylesheet. That makes a type scale predictable, and makes global adjustments trivial — change the root font size once and the entire interface rescales.

rem vs em vs px — which to use when

The three units each have a job, and most confusion comes from using one where another belongs:

The trap with em is compounding. Because it inherits from the parent's font size, nesting multiplies it: three levels of 1.2em gives you 1.2 × 1.2 × 1.2 ≈ 1.73× the base size, not 1.2×. That is why em is excellent for padding that should track its own button's text, and a poor default for typography.

The 62.5% trick — and why to think twice

A widely shared shortcut sets html { font-size: 62.5%; }, making 1rem equal 10px so the mental maths becomes easy (1.6rem = 16px). It works, and plenty of production sites use it. But it carries two costs worth knowing before you adopt it.

First, everything you forget to size inherits a tiny base: the root becomes 10px at the default setting, or 12.5px for someone who chose 20px. Because 62.5% is relative, your 1.6rem body copy still scales with the visitor's preference, but any text left at the inherited size ends up far smaller than they asked for. Second, any third-party component or CSS framework sized in rem will render 62.5% smaller than its author intended, because it assumed the standard root. Using a converter against the real 16px default sidesteps both issues entirely, which is why this tool defaults to 16.

Building a type scale in rem

Most design systems settle on a small set of steps rather than arbitrary values. A common, comfortable scale at a 16px root looks like: 0.75rem (12px) for fine print, 0.875rem (14px) for secondary text, 1rem (16px) for body copy, 1.25rem (20px) and 1.5rem (24px) for subheadings, then 2rem (32px) and 3rem (48px) for headings. Defining those as custom properties — --text-sm, --text-base, --text-lg — keeps your CSS readable and your spacing rhythm consistent.

For headings that should adapt to viewport width as well as user preference, combine rem with clamp() and mix a rem term into the fluid middle: font-size: clamp(1.5rem, 1rem + 2.5vw, 3rem) gives a floor, a fluid middle and a ceiling. A bare viewport unit in the middle, as in clamp(1.5rem, 4vw, 3rem), ignores the visitor's font-size setting everywhere between the floor and the ceiling.

Converting px to rem in Sass without the deprecated slash

Most rem() helpers in older tutorials divide with /. Dart Sass has deprecated slash-as-division, because CSS itself uses the slash as a separator (grid-area: 1 / 3, font: 16px / 1.5), and every such division now prints a deprecation warning. Load the sass:math module and use math.div(). The global built-in functions are deprecated too, so the old unitless() check becomes math.is-unitless().

@use 'sass:math';

$browser-default: 16px;

@function rem($size) {
  @if math.is-unitless($size) {
    $size: $size * 1px;
  }
  @return math.div($size, $browser-default) * 1rem;
}

.card {
  padding: rem(24);          // 1.5rem
  margin-block-end: rem(32); // 2rem
  font-size: rem(18px);      // 1.125rem
  border: 1px solid;         // hairlines stay in px
}

No preprocessor? Plain CSS can do it

CSS handles the same conversion on its own: padding: calc(24rem / 16) computes to 1.5rem with no build step, and the division stays readable for the next person. Either way, leave hairline borders and shadow offsets in px; a 1px line should stay 1px when the text grows.

If an existing codebase is full of slash divisions, the Sass team's slash-as-division breaking change notice describes sass-migrator division, which rewrites them for you.