What rem actually means
A rem is the root em — a multiple of the font size set on the <html> element. By default browsers set that to 16px, so 1rem = 16px, 1.5rem = 24px, and so on.
The conversion is simply:
rem = px ÷ root font size
The value of rem is not the arithmetic but the indirection: every rem-based measurement scales together when the root changes.
The accessibility argument
This is the reason rem matters, and it is not stylistic.
Browsers let users set a default font size, and people with low vision commonly do. When you size text in pixels, that setting is ignored — the text stays 14px whatever the user asked for. When you size in rem, the whole interface scales as they intended.
The difference is significant for a real group of users. It is also one of the easier accessibility wins available, since it costs nothing at build time once the convention is established.
Note that browser zoom scales pixel values too, so pixels are not entirely unresponsive — but zoom enlarges everything including layout, while a font-size preference targets text specifically, which is often what the user wants.
rem versus em
rem always references the root, so it is predictable everywhere. em references the font size of the element's own parent, which compounds.
The compounding trap: nest three elements each set to 0.9em and the innermost renders at 0.9 × 0.9 × 0.9 = 0.729 of the base. Deeply nested lists and menus become unreadable this way, and the cause is hard to spot.
The practical convention is rem for font sizes and layout spacing, and em where you want a value tied to the local font size — button padding that grows with the label, or letter-spacing that stays proportional.
The 62.5% trick, and why to be careful
A widely shared technique sets html { font-size: 62.5%; }, making 1rem equal 10px so the mental arithmetic becomes trivial.
It works and is popular. The caveat is that it changes the base for anything that inherits from the root without an explicit size, which can produce surprisingly small text in components you did not write — third-party widgets in particular. If you use it, set body { font-size: 1.6rem; } immediately to restore a sensible default.
Modern CSS offers a cleaner alternative for the arithmetic problem: calc(), custom properties, or simply letting your build tooling handle the conversion.
Fluid typography with clamp()
Media-query breakpoints step font sizes at fixed widths, which produces visible jumps. The clamp() function scales smoothly instead:
font-size: clamp(1.5rem, 4vw, 3rem);
That sets a minimum of 1.5rem, a preferred value of 4% of viewport width, and a maximum of 3rem — producing continuous scaling between two bounds with no breakpoints.
One accessibility caution: a preferred value expressed purely in viewport units does not respond to the user's font-size setting. Combining units — clamp(1rem, 0.5rem + 2vw, 2rem) — keeps some scaling tied to the root and avoids that problem.
Frequently asked questions
Why use rem instead of px for font sizes?
Because rem respects the user's browser font-size preference. Pixel-sized text ignores that setting entirely, which excludes users with low vision who have deliberately increased their default.
What is the difference between rem and em?
rem always references the root element's font size, so it is predictable. em references the parent's font size, which compounds through nesting - three nested 0.9em elements render at 0.729 of the base.
Is the 62.5% root font size trick a good idea?
It works and makes arithmetic easy, but it changes the base for anything inheriting from the root, which can shrink third-party components unexpectedly. If you use it, set an explicit body font size straight away.
How do I make font sizes scale with the viewport?
Use clamp(), for example clamp(1.5rem, 4vw, 3rem). Combine rem with viewport units in the preferred value so the result still responds to the user's font-size setting.