REM vs PX: Which CSS Unit Should You Use?

Many people set a larger default font size in their browser. When your CSS uses px for text, that setting is ignored and the page stays small. With rem, every size built on the root grows proportionally, so the layout keeps its rhythm at the user's preferred size.

Browser zoom scales both px and rem, so the difference shows up specifically with the font size setting, which is exactly the setting many low-vision users rely on.

A CSS pixel is not a physical screen pixel. It is a reference unit defined so that one CSS pixel looks roughly the same size on every device at a typical viewing distance. On high-density screens, one CSS pixel may be drawn with two, three or more physical pixels. That is why a 16px font looks similar on a laptop and a phone, even though the phone has many more physical pixels per inch.

Because px is fixed relative to that reference, it does not respond to the user's preferred font size. If someone sets their browser to use larger text, any text sized in px stays the same.

rem is relative to the root element's font size. With the default root of 16px, 1rem is 16px everywhere in the document, which makes rem predictable: you always know what 1.5rem means.

em is relative to the font size of the element itself (or its parent, for the font-size property). That makes em useful for values that should scale with a component's own text, such as padding inside a button or the size of an icon next to a label. The downside is compounding: nested elements with em font sizes multiply each other, so a list inside a list inside a list can grow or shrink unexpectedly.

Browser zoom (Ctrl or Cmd plus) scales everything, including px, so zoom alone does not show the difference between units. The difference appears when users change the default font size in browser settings, which many people with low vision rely on, often together with zoom.

With rem-based typography and spacing, the page reflows with larger text and keeps its proportions. With px-based typography, the setting is ignored, and users have to fall back to zoom, which may cause horizontal scrolling on some layouts. Supporting both is part of meeting the WCAG requirement that text can be resized up to 200 percent without loss of content or function.

Here is how 24px might appear in real CSS. The card title uses 1.5rem, spacing uses rem values from the same 16px base, and the border stays in px so it remains a crisp hairline. If a visitor's default font size is 20px, the title grows to 30px and the spacing grows with it, while the border stays 1px.

If you convert values often, let your tools do it. In Sass, a small function such as rem($px) that returns math.div($px, 16px) * 1rem turns rem(16px) into 1rem at compile time. In plain CSS, you can keep the pixel value readable with calc(16 / 16 * 1rem), which modern browsers resolve to 1rem.

In JavaScript, for example when generating inline styles or design tokens, divide by the root font size: 16 / 16 = 1. If you need the live root size (for users who changed their default), read parseFloat(getComputedStyle(document.documentElement).fontSize) instead of assuming 16.

Design systems rarely use raw numbers in components. Instead, 16px would live in a token such as --font-size-base for type or --space-4 for spacing, defined once as 1rem. Components then reference the token, so a later change to the scale updates every use at once.

If your team uses Figma variables or a tokens file (for example in the W3C design tokens format), store the value in px for designers and generate the rem version in the build step. That keeps both sides speaking the same language while the shipped CSS stays accessible.

When the browser computes a rem value, it multiplies it by the computed font size of the html element. That font size starts from the user's default (16px unless they changed it), then applies whatever your CSS sets on html. So 1rem means "1 times the root size", and it is resolved once per page, unlike em, which is recalculated at every level of nesting.

Because the root is shared, rem values are predictable across the whole document: a 1rem gap in a sidebar is exactly the same size as a 1rem gap in a modal, regardless of the text size inside each.