skip to content

In CSS, if a user raises their browser's default font-size preference, what happens to text sized in px versus rem — and is px text still accessible?

level: seniorimportance: should knowfreq 40%

answer

  1. two controls, not one
  2. zoom scales everything, the preference does not
  3. the root is where the preference lands
  4. pinning html font-size discards it
  5. px is fine for hairlines

basics

~20 s

Text sized in px ignores the browser's default font-size preference entirely; rem and em text scales with it because the root font-size inherits that preference. Page zoom still enlarges px text, so px is not unusable — it just ignores one of the two resize mechanisms users have.

solid answer

~50 s

There are two separate user mechanisms and they behave differently. **Page zoom** scales the whole page — every unit, including `px` — so `font-size: 14px` does enlarge under zoom. The **default font-size preference** in browser settings instead changes the root element's font-size, which is where `rem` (and inherited `em`) get their value. Text declared in `px` is unaffected by that preference: a user who raised their default to 20px because 16 is uncomfortable still gets your 14px body copy. Since raising the default is the setting users with low vision most often reach for, sizing type in `rem` is the accessible default. The nuance worth stating: `px` is not forbidden — it is fine for hairline borders, small shadow offsets, and other details that should not grow with text — and the blanket claim that px text cannot be resized has been false since browsers moved to full-page zoom.

code

css · 8 lines
css
/* Breaks the preference: rem is now pinned to 16px for everyone */
html { font-size: 16px; }

/* Honours it: root keeps the user's default, scale is relative */
html { /* no font-size */ }
body { font-size: 1rem; line-height: 1.5; }
h1   { font-size: 2rem; }
.card { padding: 1rem; border: 1px solid; } /* px border stays crisp */

go deeper

for a junior

Know that rem-based text follows the user's browser font-size setting while px-based text does not, and default to rem for anything that is type.

for a middle

Distinguish the two user controls precisely — page zoom scales every unit, the default font-size preference only moves the root — and explain why rem inherits that preference while px cannot.

for a senior

Show the production judgment: audit for a pinned root font-size, keep px for hairlines and shadows, choose em-based breakpoints deliberately, and correct the overstated claim that px text is unresizable.

for a principal

Own it as a token-system decision: which scales live in rem, which stay absolute, and how that contract is enforced across teams — plus how far the organisation commits to honouring user preferences beyond the minimum an audit checks.

## Two different user controls Browsers give users two ways to make a page bigger, and conflating them is the source of most bad advice on this topic. **Page zoom** (the ctrl/cmd-plus control) scales the rendered page as a whole. Every CSS length grows proportionally, `px` included, and the CSS pixel effectively gets larger. Layout still reflows, because the viewport measured in CSS pixels gets narrower as you zoom in, so media queries fire. Nothing about your unit choice defeats zoom. **The default font-size preference** is a setting in the browser's appearance/fonts panel: the user says "my default text should be 20px, not 16px". This changes the initial value that the root element's `font-size` computes to. It does *not* touch anything you declared in absolute units. That second control is the one that discriminates between unit choices, and it is the one a low-vision user is most likely to set once and forget — it does not need re-applying per site the way zoom sometimes does. ## How each unit responds - **`px` font-size** — fixed. `font-size: 14px` renders at 14 CSS pixels regardless of the preference. Under page zoom it grows like everything else. - **`rem`** — resolves against the root element's computed font-size. If the author never overrides it, that *is* the user's preference, so `1rem` becomes 20px for the user above and your whole type scale moves with them. - **`em`** — inherits through the tree from that same root value, so it also scales, with the compounding behaviour that comes with `em`. - **`%` on font-size** — behaves like `em`: relative to the parent's computed font-size, so it also tracks the preference. ```css :root { /* no font-size declared: inherits the user's preference */ } body { font-size: 1rem; } /* 16px by default, 20px if the user asked for 20 */ .note { font-size: 14px; } /* 14px for everyone, always */ ``` ## The trap: overriding the root in px Declaring `html { font-size: 16px }` looks harmless and is the most common way teams accidentally break this. It **pins** the root to 16px and discards the user's preference — and because `rem` resolves against the root, every `rem` in the stylesheet is now silently locked too. You get all the ceremony of a rem-based scale with none of the benefit. The same applies to the `62.5%` trick (`html { font-size: 62.5% }` so `1rem` reads as 10px). A percentage at least stays proportional to the user preference, but it shrinks every inherited default in the document below what the user asked for, and any third-party or user-agent styling that assumed the default now renders small. The safe pattern is to leave the root font-size alone and express your scale in `rem` relative to it. ## Where px is still the right call The accessible-units argument is about **text and the space around it**, not about every length in the file. Values that should stay crisp and not grow with type are legitimately `px`: - `border-width: 1px` hairlines and dividers — a border that scales with the user's font preference just looks heavy. - Small `box-shadow` offsets and blur radii. - Fixed-size decorative details that are not carrying information. Text, its line-height, and the padding that keeps it legible are the things that should scale. ## Media queries and the preference One more consequence: font-relative units inside a `@media` condition resolve against the *initial* font-size — the user's preference — and not against any `font-size` you set on `:root`. So `@media (min-width: 40em)` shifts its effective breakpoint for a user with larger default text, which is usually desirable: a user who wants bigger text gets the narrower-layout treatment sooner rather than being crammed into a multi-column grid. Breakpoints declared in `px` do not respond that way. ## Saying it correctly in an interview The weak version of this answer is "never use px, users can't resize it". That was true in the era of text-only zoom and has not been true for a long time — full-page zoom scales `px` fine, and an accessibility criterion about resizing text can be satisfied through zoom alone. The strong version is precise: *px ignores the browser's default font-size preference, which is a real setting real users rely on; rem honours it; therefore size type in rem, keep px for details that should not scale, and never pin the root font-size in px.*

  • So is it wrong to say px text cannot be resized by users?
    Yes, as an absolute claim. Full-page zoom scales px text along with everything else, so px text is resizable. What px cannot do is respond to the browser's default font-size preference — a setting many low-vision users set once globally. That is the accurate framing: px ignores one of the two mechanisms, not both.
  • What is wrong with declaring html { font-size: 16px } if the rest of the stylesheet uses rem?
    It pins the root to an absolute value, so the user's font-size preference is discarded and every rem in the stylesheet becomes a disguised px. You keep the authoring convenience of a rem scale and lose the entire accessibility benefit. Leave the root font-size undeclared and let it inherit the preference.
  • Should breakpoint values be written in px or em?
    em-based conditions resolve against the user's default font-size, so a user with larger text reaches the narrower layout sooner — usually the behaviour you want, since bigger type needs fewer columns. px breakpoints ignore the preference and fire purely on viewport width. Many teams pick em for that reason and accept that the effective breakpoint varies per user.
  • Which lengths are still legitimately px in an accessible stylesheet?
    Details that should not grow with text: 1px borders and dividers, small shadow offsets and blur radii, and fixed decorative elements carrying no information. Text size, line spacing and the padding that keeps text legible should be relative, because those are the values a user is adjusting when they raise their default font size.

saying these in an interview costs you the question

  • Claims px text cannot be enlarged by users at all
  • Sets html font-size in px and still calls the scale accessible
  • Says zoom and the default font-size setting are the same control
  • Uses rem for hairline borders to be safe
  • Treats the 62.5% root trick as an accessibility best practice

context

resolving links…