Typography Checklist: 20 Things to Review Before You Launch

The week before launch is when typography gets the least attention. Everyone is chasing broken forms, missing images, and analytics tags, and the text looks fine on the one laptop everyone is testing on. Then real users arrive with large phones, small laptops, zoomed browsers, and slow connections, and the cracks show: a heading that overflows on mobile, a fallback font that flashes in for two seconds, a price column that won't line up.

This post is a typography launch checklist: 20 specific things to review, grouped into fonts and loading, size and spacing, layout and wrapping, accessibility, and content details. Each item says what to check and how, with a snippet where it helps. Most take a minute or two. Together they catch the problems users notice before you do.

Fonts and Loading

1. Every Font File Loads Without Errors

Open DevTools, go to the Network panel, filter by Font, and reload with the cache disabled. Every request should return 200. A 404 on a font file is easy to miss because the fallback still renders.

Also check the console for CORS errors if fonts come from a different origin or CDN.

2. Only the Fonts You Use Are Downloaded

In the same Network view, look at what's downloaded on a typical page. Unused weights, italic files nobody references, or a whole icon font for three icons are all wasted bytes. Remove @font-face rules for styles the design doesn't use.

3. Fonts Are WOFF2 and Subset

WOFF2 is supported by every current browser and compresses better than older formats. If your font files are larger than you expect, subsetting to the character ranges your content uses can cut them substantially. Font Subsetting: Shrinking Web Font Files Without Losing Characters explains how.

4. font-display Is Set Deliberately

Every @font-face rule should have a font-display value you chose on purpose, not one copied from a snippet:

@font-face {
  font-family: "Inter";
  src: url("/fonts/inter-var-latin.woff2") format("woff2");
  font-weight: 100 900;
  font-display: swap;
  unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+2000-206F;
}

swap is a sensible default for most text. optional suits sites where performance matters more than seeing the custom font on a first visit. The trade-offs are covered in How to Load Web Fonts Efficiently with font-display.

5. Fallback Fonts Are Close and Layout Doesn't Jump

Throttle the network to "Slow 4G" in DevTools and reload. Watch the text as the web font arrives. If headings change line count or the page shifts, tune the fallback with size-adjust and metric overrides, or use a framework tool that does it for you, such as next/font in Next.js. See Font Optimization in Next.js with next/font.

6. No Synthesized Bold or Italic

Search the CSS for every font-weight and font-style value used, and confirm each one has a matching font file. A quick way to surface gaps during testing is to disable synthesis temporarily:

* {
  font-synthesis: none;
}

Any text that should be bold but renders regular is missing its font file.

Size and Spacing

7. Body Text Is at Least 1rem

Paragraph text should be at least 1rem and set in relative units so it follows the user's browser setting. Check by changing the browser's default font size to "Large" or "Very Large" in settings and reloading. The text should grow. If it doesn't, something is set in px.

8. Line Height Is Set for Body and Headings Separately

Look at a long paragraph and a multi-line heading. Body text usually wants a unitless line-height around 1.5 to 1.7. Headings want something tighter, around 1.1 to 1.25. If both use the same value, one of them looks wrong.

9. Line Length Is Capped

Open the longest article on a wide monitor. If paragraphs stretch beyond about 75 characters, cap them:

.prose {
  max-width: 70ch;
}

10. Headings Have More Space Above Than Below

A heading should sit closer to the content it introduces than to the content before it. Scan a long page and check that each heading visually belongs to the section below it.

11. The Type Scale Is Consistent

Run a quick audit in the console to list every distinct font size on a page:

const sizes = new Set(
  [...document.querySelectorAll("body *")].map(
    (el) => getComputedStyle(el).fontSize,
  ),
);
console.log([...sizes].sort((a, b) => parseFloat(a) - parseFloat(b)));

If you see 15px, 15.5px, 16px, and 17px all in use, some components aren't using the scale.

Layout and Wrapping

12. Headings Don't Overflow on Small Screens

Test at 320px wide, which is the width WCAG's reflow criterion uses. Long words in large headings, especially in languages like German, can overflow the viewport. Add a safety net:

h1,
h2 {
  overflow-wrap: break-word;
  hyphens: auto;
}

A fluid size with clamp() usually prevents the problem in the first place. How to Build Fluid Typography That Scales Across Every Screen shows how.

13. Headings Wrap Nicely

Look for headings and card titles that break with a single word on the last line. Add text-wrap: balance to headings and text-wrap: pretty to paragraphs.

14. Truncation Works with Real Content

Anywhere text is clamped or truncated, test with the longest realistic content: long product names, long author names, translated strings. Make sure the full text is still available somewhere, such as a title attribute or a detail page.

15. Numbers Line Up

Check tables, pricing, stats, and any changing counters. Columns of numbers should use tabular figures so digits align and timers don't jitter:

td,
.stat-value {
  font-variant-numeric: tabular-nums;
}

Accessibility

16. Text Contrast Meets WCAG AA

Run an automated checker like Lighthouse or axe on key pages, then spot-check text over images and gradients by hand, since tools often miss those. The AA thresholds are 4.5:1 for normal text and 3:1 for large text.

17. Text Survives Zoom and Spacing Overrides

Zoom the browser to 200% and confirm nothing overlaps or gets cut off. Then apply the WCAG 1.4.12 text spacing values with a bookmarklet or a temporary stylesheet:

* {
  line-height: 1.5 !important;
  letter-spacing: 0.12em !important;
  word-spacing: 0.16em !important;
}

p {
  margin-bottom: 2em !important;
}

Fixed-height buttons, cards, and badges are the usual places where text gets clipped. Meeting WCAG Text Spacing Requirements goes deeper.

18. Heading Levels Are Logical

Use a browser extension or the accessibility tree in DevTools to list the page's headings. There should be one h1, and levels shouldn't skip from h2 to h4 just to get a smaller size. Visual style and heading level can differ; the outline still needs to make sense.

Content Details

19. Punctuation Is Typographic

Search the rendered pages for straight quotes in body copy, double hyphens used as dashes, and three periods used as an ellipsis. Fix them at the content source. Check that ranges use en dashes and that apostrophes curl the right way.

20. The lang Attribute Is Correct

The lang attribute on the html element affects hyphenation, quote styles from the q element, font selection for some scripts, and screen reader pronunciation. Make sure it's present and correct, and that content in other languages has its own lang:

<html lang="en">
  <body>
    <p>The French term is <span lang="fr">mise en page</span>.</p>
  </body>
</html>

The Checklist at a Glance

#	Check	How to verify
1	All font files load	Network panel, filter by Font
2	No unused font files	Network panel on key pages
3	WOFF2 and subset	File sizes in Network panel
4	Deliberate font-display	Review @font-face rules
5	Minimal shift when fonts swap	Throttled reload
6	No faux bold or italic	font-synthesis: none test
7	Body text at least 1rem	Change browser default font size
8	Separate body and heading line height	Visual check on long content
9	Line length capped	Wide monitor test
10	Heading spacing groups content	Scan a long page
11	Consistent type scale	Console audit of font sizes
12	No overflow at 320px	Responsive mode
13	Balanced heading wraps	Visual check
14	Truncation with real content	Long strings and translations
15	Tabular figures where needed	Tables, prices, timers
16	Contrast meets AA	Lighthouse or axe, plus manual check
17	Zoom and text spacing survive	200% zoom, spacing stylesheet
18	Logical heading outline	Accessibility tree
19	Typographic punctuation	Search rendered text
20	Correct lang attribute	View source

How to Run the Review

A checklist only helps if it's run consistently. A few practical habits make the difference.

Pick representative pages. You don't need to check every URL. Choose a small set that covers your templates: the home page, a long article, a listing page, a page with a table, a form, and an error page. Problems found there usually apply site-wide.

Test on real devices and settings. At minimum, check one phone, one laptop, and one large desktop monitor. Include at least one Windows machine if your team works on Macs, since text rendering differs noticeably. Change the browser's default font size and zoom level at least once.

Record what you find. Note the page, the check number, and a screenshot. Group issues by root cause before fixing them. Five pages with cramped headings are often one missing line-height rule in a shared component.

Fix at the source. Resist patching individual pages. If the checklist finds body text at 15px on one template, find out why that template isn't using the base style, and fix that.

Automate what you can. Some checks can run on every build. Lighthouse in CI can flag contrast failures and missing lang attributes. A Stylelint rule can reject px font sizes outside your token files. Visual regression tests catch unexpected changes in wrapping and spacing. The manual checks still matter, but automation keeps fixed problems from coming back.

Common Mistakes

• Testing only on a fast connection with a warm cache. Font loading problems only show up on a cold, slow load.
• Checking only the home page. Long articles, tables, forms, and error pages have the most typography edge cases.
• Relying entirely on automated tools. Contrast checkers can't evaluate text over images, and no tool judges hierarchy or wrapping.
• Fixing issues in one component. If a check fails, look for the root cause in base styles so the fix applies everywhere.
• Leaving it until launch day. Run the checklist at the first full staging build, then again before release.

Conclusion

A typography launch review covers five areas: fonts load quickly and correctly, sizes and spacing follow the system, layouts handle real content at every width, text meets accessibility requirements, and the small content details are right. Twenty checks sounds like a lot, but most take a minute with DevTools open.

Make the list part of your release process rather than a one-time exercise. The first run will find a handful of issues; later runs will find fewer, because the fixes end up in your base styles and stay there.