On this page
A heading should answer two questions before anyone reads its words: how important is this information, and which content belongs beneath it? Size alone cannot answer both. A large heading placed too close to the previous paragraph can look like a conclusion rather than the start of a new section.
Start with content roles, not a size ladder
Inventory the actual headings on one representative page. Separate the page title, major sections, subsections, and small component labels. These are content roles, not necessarily four successive font sizes. A product dashboard might need only three visual treatments even when its document outline contains more levels.
Use the px-to-rem converter to translate proposed sizes into relative units. With a 16px reference, 24px becomes 1.5rem and 32px becomes 2rem. Keep the browser root size user-controlled rather than forcing that reference on every reader.
Write a short role description beside each treatment: “section heading introduces a new task,” for example. If two treatments have indistinguishable responsibilities, merge them before adjusting their appearance. This avoids a decorative scale that grows every time a designer needs a slightly different card title.
Use size contrast where it carries meaning
Start with body text around 1rem, subsection headings around 1.125–1.25rem, section headings around 1.5rem, and a page title around 2–2.5rem. These are starting points, not universal ratios. The font's x-height, width, and stroke contrast change how large each value appears.
A heading only one pixel larger than body text may still work if weight and spacing clearly separate it. Conversely, a 48px title can fail when it wraps into five short lines above a compact interface. Evaluate perceived size in the actual font, not just the number shown in a design panel.
For editorial layouts, test a long title and an ordinary title together. For interfaces, include “Account,” “Billing preferences,” and a longer localized equivalent. A hierarchy that works only with short English labels is not ready for production.
The MDN font-size reference explains relative sizing behavior. For mixed typefaces, the existing serif and sans-serif pairing guide provides a useful companion: equal CSS sizes rarely create equal optical prominence across families.
Give weight and spacing separate jobs
Let font weight communicate emphasis within a size tier, and let spacing communicate grouping. A section heading at 600 can stand above body copy at 400 without needing the visual density of 800. Check that the selected font actually provides the requested weight before judging the result.
The key spacing relationship is usually more space above than below. A heading belongs to the paragraph that follows, so its lower gap should generally be smaller than its upper gap. Try 2rem above and 0.75rem below a section heading, then adjust for the surrounding rhythm.
Use tighter line-height for large headings than for paragraphs, but leave room for accents and multiple lines. A title might start at 1.15, while a compact subsection title might need 1.3. Avoid fixed pixel heights around headings: those boxes can clip text when users enlarge it.
Letter spacing needs restraint. Slightly negative tracking can help some large display faces, but it can also close counters and crowd punctuation. Small uppercase labels often need more tracking, yet they should remain short. Do not apply one tracking value across every heading level.
Encode a small, explicit hierarchy
Keep semantic rank separate from visual styling. An h2 marks a section in the document, even when it is styled like a small panel title. Do not pick h4 merely because its browser default looks convenient. The WAI headings guidance explains why a meaningful outline helps readers navigate.
A compact implementation can make the role differences easy to inspect:
:root {
--text-body: 1rem;
--text-section: 1.5rem;
--text-page: 2.25rem;
}
.prose {
font-size: var(--text-body);
line-height: 1.6;
}
.page-title {
font-size: var(--text-page);
font-weight: 700;
line-height: 1.15;
margin-block: 0 1.25rem;
max-inline-size: 22ch;
}
.prose h2 {
font-size: var(--text-section);
font-weight: 600;
line-height: 1.25;
margin-block: 2rem 0.75rem;
}
.prose h3 {
font-size: 1.125rem;
font-weight: 600;
line-height: 1.35;
margin-block: 1.5rem 0.5rem;
}The title width is a useful starting constraint, not a guaranteed character count: the ch unit is based on the zero glyph's advance width. Test the resulting measure with real copy. Also inspect collapsed block margins in your layout; their final spacing may differ from simply adding the declared values. MDN's margin documentation covers that behavior.
Test the hierarchy as a reading path
First, blur your attention and scan only the headings. Can you identify the page subject, major sections, and subordinate ideas without reading paragraphs? Then read the final paragraph before each heading and the opening paragraph after it. This reveals whether spacing creates the right boundaries.
Next, test at a narrow viewport and with enlarged text. Reduce oversized titles before shrinking body copy. Let heading lines wrap naturally, and avoid manual line breaks inserted merely to match a desktop screenshot. Those breaks often produce awkward fragments on smaller screens.
Include a stress-test page with adjacent headings, a heading followed by a list, a linked heading, and a three-line title. If adjacent headings create excessive whitespace, add a targeted rule for that relationship instead of weakening every section gap. If links obscure hierarchy, adjust underline treatment without removing the link's recognizable affordance.
Finally, document the result with a few real examples and acceptance checks. Record intended weights, line-heights, and spacing relationships, not just sizes. The principles in design tokens basics can help preserve these decisions as the interface grows. Recheck after changing a typeface: the same numeric scale can suddenly feel flatter or more aggressive.
Before approving a treatment, compare a page with many short sections against one with only two long sections. The first exposes repetitive visual noise; the second exposes headings that disappear inside dense copy. Keep the hierarchy consistent, but allow the surrounding layout to establish a different rhythm. A sidebar heading does not need the same top margin as a heading deep inside an article. Name those contextual exceptions clearly instead of creating new heading levels. This keeps the reading order stable while acknowledging that a navigation panel and a reading column perform different jobs.
Key takeaways
- Establish heading roles before selecting a mathematical scale.
- Combine size, weight, and spacing rather than maximizing all three.
- Keep headings visually attached to the content they introduce.
- Preserve semantic heading order independently of styling.
- Test long copy, narrow layouts, and enlarged text before documenting the system.
Reach designers & developers at work
Put your product next to the tools people use every day. One sponsor per placement, no tracking pixels.
Become a sponsor