Typography Units For Web
Typography units look like a design detail until a layout breaks under browser zoom, headings feel inconsistent across sections or a component becomes impossible to maintain. PX, EM and REM all work, but they solve different problems. Good web typography starts when those units are chosen with intent rather than habit.
This guide stays in one lane: CSS font-size units for web type, specifically px, em, rem, pt and percent, with a close look at how font-size choices interact and how em values compound when elements nest. It does not cover layout spacing systems, grid sizing or print stylesheets beyond the px-to-pt question, which are separate topics.
PX still has a place
Pixel-based sizing gives direct control and is often useful for borders, icons and tightly controlled UI details. It is not inherently wrong for type either. The problem is using pixels everywhere without considering accessibility or system scaling.
A rigid pixel-only system can make maintenance and proportional scaling harder across a larger interface.
REM creates a stable site-wide rhythm
REM ties sizing back to the root font size, which makes global scaling easier and often improves consistency. When headings, spacing and body text derive from one clear base, a design system becomes easier to reason about.
That is why many modern design systems prefer REM for typography and spacing tokens.
Where EM helps and where it causes trouble
EM is useful when a component needs to scale relative to its own font size. Buttons, badges and nested text treatments can benefit from that local proportional behavior. The downside is compounding. Nested EM values can quickly become difficult to predict if the structure becomes deep or inconsistent.
To see the trap concretely, picture a list where every nested level sets font-size: 0.9em. Each level multiplies the size it inherits from its parent, so the text shrinks at every step rather than staying at a flat 90 percent of the root:
| Nesting depth | Computed size (parent then 0.9em) | Resulting px (16px base) |
|---|---|---|
| Level 0 (root) | 16px | 16.00px |
| Level 1 | 16 then 0.9 | 14.40px |
| Level 2 | 14.40 then 0.9 | 12.96px |
| Level 3 | 12.96 then 0.9 | 11.66px |
| Level 4 | 11.66 then 0.9 | 10.50px |
By the fourth nested level the text is 10.50px, roughly 66 percent of the 16px root, even though no single rule asked for anything smaller than 0.9. Swap the same rule to 0.9rem and every level stays locked at 14.40px no matter how deep the nesting goes, because rem reads the root and ignores the parent.
So EM is powerful, but best used deliberately rather than casually.
Why this matters beyond design theory
These choices affect readability, accessibility, maintenance and visual consistency. A page that scales cleanly under zoom or user preference is simply more resilient than one built from rigid assumptions.
For a utility site, that matters because people arrive from many devices and browsing habits.
Practical starting values for web type
Most modern sites set a base of 16px on the HTML element, which makes 1rem equal to 16px. From there, common heading sizes in rem are:
| Heading level | Common rem value | Equivalent in px (16px base) |
|---|---|---|
| H1 | 2rem | 32px |
| H2 | 1.5rem | 24px |
| H3 | 1.25rem | 20px |
| Body text | 1rem | 16px |
| Small / caption | 0.875rem | 14px |
These are starting points, not rules. What matters is internal consistency: if your H2 and body text sizes come from the same base, scaling the root font size will resize everything proportionally without breaking the ratios.
When users change their browser font size
Accessibility guidelines recommend allowing users to zoom text to at least 200 percent without breaking layout. Pixel-based type does not respond to browser font size preferences, which can make reading harder for users who need larger text. REM-based sizing respects those preferences because it ties to the user's configured root size rather than a fixed pixel count.
For a practical utility site, this means a visitor who has set their browser default to 20px will see proportionally larger text on a REM-based layout, while a pixel-locked layout will look the same to them regardless of their preference. That is a real accessibility and usability difference.
The takeaway
Typography units are not there to impress designers. They are there to keep text readable and layout behavior predictable. Use PX when fixed precision is genuinely useful, REM when global consistency matters, and EM when a component should scale from within.
Once those roles are clear, typography choices become much less confusing.
Useful tools for this topic
Frequently Asked Questions
Should I set font-size in px or rem?
Reach for rem on text so it respects the user's browser default. A visitor who raised their default from 16px to 20px sees a 1rem paragraph grow to 20px, while a 16px-locked paragraph stays 16px and ignores them. Keep px for things that should not scale with text, such as a 1px border or a 24px icon. The split is intent: rem for type, px for fixed UI detail.
Why does my em text keep shrinking when elements nest?
em multiplies the parent's computed font-size, not the root, so the effect compounds. With 0.9em applied at every level from a 16px base you get 14.40px, then 12.96px, then 11.66px, then 10.50px by the fourth nested level: about 66 percent of the root from a rule that never asked for less than 0.9. Switch the same declaration to 0.9rem and every level holds at 14.40px because rem reads only the root.
How many pixels is 1 point on a screen?
CSS defines 1pt as 1/72 inch and a reference of 96 CSS pixels per inch, so 1pt = 96 / 72 = 1.333px. That makes the familiar 12pt body size equal to 12 × 1.333 = 16px, which is exactly the common browser default. Points come from print, so on the web they are mostly useful inside a print stylesheet rather than for screen type.
What does setting font-size in percent actually do?
Percent behaves like em: it is relative to the parent's font-size, so font-size: 100% equals the inherited value and 62.5% on the root html makes 1rem equal 10px instead of 16px (16 × 0.625 = 10). The old 62.5 percent trick let people write 1.4rem and read it as 14px, but it also shrinks every rem-based default, so most teams now keep the root at 100 percent and do the math in rem directly.