How to create a typography style guide?

To create a typography style guide, document the fonts you use and why, define a fixed type scale, turn every size, weight, line height and spacing value into named design tokens, combine those tokens into a small set of named text styles such as "heading large" and "body", and write clear rules for when to use each one. Add live examples of every style, accessibility requirements such as minimum sizes and contrast, and guidance for edge cases like long headings, links and numbers. The guide should be built from the same tokens your code uses, so it can't drift out of date. A good guide is short enough that people actually read it and specific enough that two designers or developers would make the same choice.

Without a style guide, typography tends to drift. Each new page adds a slightly different heading size, a new grey for captions, or another font weight, and after a year you have dozens of near-duplicate styles that make the site feel inconsistent and the CSS hard to maintain. In this article you'll learn what to include in a typography style guide, how to audit what you already have, how to define fonts, scales and tokens, how to name and document text styles, and how to keep the guide connected to production code.

What a Typography Style Guide Includes

A typography style guide is one part of a wider design system, but it can stand on its own. At a minimum, it should cover:

• Typefaces: Which font families you use, their roles, licences, and fallback stacks.
• Type scale: The fixed set of font sizes, and how they change across screen sizes.
• Weights and styles: Which weights and italics are available, and what each is for.
• Line height and spacing: Line heights for each size, letter spacing adjustments, and paragraph spacing.
• Text styles: Named combinations of the above, such as display, headings, body, caption and label.
• Usage rules: When to use each style, and what not to do.
• Accessibility: Minimum sizes, contrast requirements and behaviour when text is zoomed.
• Content rules: Line length, alignment, capitalisation, links, lists and numerals.

Keep it practical. A guide that explains every typographic concept from first principles is rarely consulted; one that answers "which style should I use for this?" in a few seconds gets used every day.

Step 1: Audit What You Already Have

Unless you're starting from scratch, begin with an audit. You need to know how much variation exists before you can reduce it.

1. Collect the values: Extract every font-size, font-weight, line-height, letter-spacing and font-family declaration from your CSS.
2. Group near-duplicates: Sizes like 15px, 15.5px and 16px are probably meant to be the same thing.
3. Screenshot real pages: Capture headings, body text, captions, buttons, forms and tables in context.
4. Note the problems: Inconsistent heading sizes, too many weights, low-contrast text or cramped line height.

A quick command-line pass gives you a rough frequency count of font sizes in your stylesheets:

grep -rhoE "font-size:[[:space:]]*[^;]+" src/styles/ | sed -E 's/font-size:[[:space:]]*//' | sort | uniq -c | sort -rn

  42 1rem
  18 0.875rem
  11 1.5rem
   9 14px
   7 2rem
   5 15px
   3 1.375rem
   2 13px
   1 1.4rem

In this example, 14px and 0.875rem are the same size written two ways, and the stray 15px, 13px and 1.4rem values are candidates for consolidation.

Step 2: Choose and Document Your Typefaces

Most sites need one or two typefaces: one for text and, optionally, one for headings or code. For each, document:

• Name and role: For example, "Source Serif 4 for headings, Inter for body and interface text, JetBrains Mono for code".
• Weights and styles in use: Only list the ones you load. If you load 400, 600 and 700, say so, and don't allow 500.
• Source and licence: Where the files come from and what licence covers them.
• Fallback stack: The fonts that appear while web fonts load, or if they fail.
• Loading strategy: Whether you self-host, preload, and which font-display value you use.

If you're still choosing, how to pair fonts covers combining typefaces, and how many fonts per website explains why fewer is usually better.

Step 3: Define a Type Scale

A type scale is the fixed set of sizes everyone is allowed to use. It replaces arbitrary values with a short, ordered list. Many teams base it on a ratio, such as 1.2 or 1.25, then round the results to sensible values. Others pick sizes by eye. Either works, as long as the set is small, usually six to ten steps.

Name the steps neutrally, by position, so the names still make sense when you use a size outside its typical role:

Token	Size (rem)	Size at 16px root	Typical use
size-xs	0.75	12px	Legal text, badges
size-sm	0.875	14px	Captions, labels, metadata
size-md	1	16px	Body text, inputs
size-lg	1.25	20px	Lead paragraphs, small headings
size-xl	1.5	24px	Section headings
size-2xl	2	32px	Page headings
size-3xl	2.75	44px	Display and hero text

Decide how the scale responds to screen size. A common approach keeps body sizes fixed and lets the largest headings grow between a minimum and maximum with clamp().

Step 4: Turn Values Into Design Tokens

Design tokens are named values that both design tools and code can use. Storing your typography values as tokens means the style guide, the Figma library and the CSS all come from a single source.

The Design Tokens Community Group format, a W3C community specification, is widely supported by token tools. A typography token file might look like this:

{
  "font": {
    "family": {
      "sans": {
        "$type": "fontFamily",
        "$value": ["Inter", "system-ui", "sans-serif"]
      },
      "serif": {
        "$type": "fontFamily",
        "$value": ["Source Serif 4", "Georgia", "serif"]
      },
      "mono": {
        "$type": "fontFamily",
        "$value": ["JetBrains Mono", "ui-monospace", "monospace"]
      }
    },
    "weight": {
      "regular": { "$type": "fontWeight", "$value": 400 },
      "semibold": { "$type": "fontWeight", "$value": 600 },
      "bold": { "$type": "fontWeight", "$value": 700 }
    },
    "size": {
      "sm": {
        "$type": "dimension",
        "$value": { "value": 0.875, "unit": "rem" }
      },
      "md": { "$type": "dimension", "$value": { "value": 1, "unit": "rem" } },
      "xl": { "$type": "dimension", "$value": { "value": 1.5, "unit": "rem" } },
      "2xl": { "$type": "dimension", "$value": { "value": 2, "unit": "rem" } }
    },
    "lineHeight": {
      "tight": { "$type": "number", "$value": 1.2 },
      "normal": { "$type": "number", "$value": 1.5 },
      "relaxed": { "$type": "number", "$value": 1.65 }
    }
  }
}

A build tool such as Style Dictionary can transform this file into CSS custom properties, platform files for iOS and Android, and documentation tables. The generated CSS looks like this:

:root {
  --font-family-sans: Inter, system-ui, sans-serif;
  --font-family-serif: "Source Serif 4", Georgia, serif;
  --font-family-mono: "JetBrains Mono", ui-monospace, monospace;
  --font-weight-regular: 400;
  --font-weight-semibold: 600;
  --font-weight-bold: 700;
  --font-size-sm: 0.875rem;
  --font-size-md: 1rem;
  --font-size-xl: 1.5rem;
  --font-size-2xl: 2rem;
  --font-line-height-tight: 1.2;
  --font-line-height-normal: 1.5;
  --font-line-height-relaxed: 1.65;
}

Step 5: Combine Tokens Into Named Text Styles

Raw tokens give too much freedom. If designers and developers combine sizes, weights and line heights freely, you're back to inconsistency. Text styles fix this by bundling tokens into a small set of approved combinations.

Name text styles by role, and keep the list short. Ten to fifteen styles cover most products.

.text-display {
  font-family: var(--font-family-serif);
  font-size: clamp(2.25rem, 1.6rem + 2.6vw, 2.75rem);
  font-weight: var(--font-weight-bold);
  line-height: 1.1;
  letter-spacing: -0.01em;
  text-wrap: balance;
}

.text-heading-lg {
  font-family: var(--font-family-serif);
  font-size: var(--font-size-2xl);
  font-weight: var(--font-weight-bold);
  line-height: var(--font-line-height-tight);
  text-wrap: balance;
}

.text-heading-md {
  font-family: var(--font-family-sans);
  font-size: var(--font-size-xl);
  font-weight: var(--font-weight-semibold);
  line-height: 1.3;
}

.text-body {
  font-family: var(--font-family-sans);
  font-size: var(--font-size-md);
  font-weight: var(--font-weight-regular);
  line-height: var(--font-line-height-relaxed);
}

.text-caption {
  font-family: var(--font-family-sans);
  font-size: var(--font-size-sm);
  line-height: var(--font-line-height-normal);
  color: var(--color-text-muted);
}

.text-code {
  font-family: var(--font-family-mono);
  font-size: 0.9em;
  font-variant-ligatures: none;
}

Separate visual styles from HTML semantics. An h2 doesn't always have to look like text-heading-lg; a sidebar h2 might use text-heading-md. Document this clearly so people choose heading levels for document structure and text styles for appearance.

Step 6: Write Usage Rules

Usage rules are what turn a list of styles into a guide. For each style, write a sentence or two on when to use it, then add a handful of do and don't examples.

• Body: Use for all running text, including article content, descriptions and form help text. Keep lines between about 45 and 75 characters.
• Caption: Use for image captions, timestamps and metadata. Don't use for anything a user must read to complete a task.
• Label: Use for form labels and buttons. Sentence case, never all caps.
• Display: Use once per page at most, for the main page title on marketing pages.

Cover common content decisions too:

• Capitalisation: Sentence case or title case for headings, and how to treat product names.
• Alignment: Left-aligned (start-aligned) body text, and when centred text is acceptable.
• Links: Underlined in body text, colour and hover state, and how links look inside headings.
• Numbers: Tabular figures in tables and prices, for example with font-variant-numeric: tabular-nums.
• Emphasis: Italic for emphasis in body text, bold for warnings and key terms, never underline for emphasis.

Step 7: Add Accessibility Requirements

Bake accessibility into the guide so it isn't an afterthought:

• Minimum sizes: Set a floor for body text, often 16px, and for small text such as captions.
• Contrast: WCAG 2.2 requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text at level AA. Document approved text colours and the backgrounds they pass on.
• Zoom and reflow: Text must remain readable when zoomed to 200 per cent, and layouts should reflow at a 320 CSS pixel width without horizontal scrolling.
• Text spacing: Layouts must not break when users increase line height, paragraph spacing, letter spacing and word spacing to the levels in WCAG success criterion 1.4.12.
• Relative units: Use rem for font sizes so user font-size preferences are respected.

Step 8: Build the Guide From Live Code

The most reliable style guides are generated from production code, so they can't go stale. A simple specimen page that uses the real CSS classes is a good start:

<section class="specimen">
  <h2 class="text-heading-md">Text styles</h2>

  <div class="specimen__row">
    <p class="specimen__meta">
      text-display · Source Serif 4 Bold · fluid 36 to 44px · 1.1
    </p>
    <p class="text-display">Readable type, every time</p>
  </div>

  <div class="specimen__row">
    <p class="specimen__meta">text-body · Inter Regular · 16px · 1.65</p>
    <p class="text-body">
      Body text is used for all running copy. It should be comfortable to read
      for long periods on every device.
    </p>
  </div>
</section>

Tools such as Storybook, or your design system documentation site, can render these specimens alongside the usage rules. Because they use the same tokens and classes as the product, a change to a token updates the guide automatically.

Enforce the Guide in Code

Linting stops new arbitrary values from slipping in. Stylelint's built-in declaration-property-value-allowed-list rule can require that font sizes and weights come from your tokens:

{
  "rules": {
    "declaration-property-value-allowed-list": {
      "font-size": ["/^var\\(--font-size-/", "/^clamp\\(/", "inherit", "/em$/"],
      "font-weight": ["/^var\\(--font-weight-/", "inherit"],
      "font-family": ["/^var\\(--font-family-/", "inherit"]
    }
  }
}

src/components/card.css
  12:14  ✖  Unexpected value "15px" for property "font-size"   declaration-property-value-allowed-list

Adjust the patterns to suit your codebase. The point is to make the easy path the consistent one.

Keeping the Guide Alive

A style guide needs an owner and a process, or it slowly becomes fiction.

1. Assign an owner: One person or a small group approves changes to typography tokens and styles.
2. Version it: Record changes in a changelog so teams know when a style was added, changed or removed.
3. Review new requests: When someone needs a style that doesn't exist, decide whether an existing style fits before adding a new one.
4. Audit periodically: Re-run your font-size audit every few months and fix strays.
5. Remove unused styles: Deprecate styles that nobody uses, so the list stays short.

---

FAQ: Typography Style Guides

---

Conclusion

Creating a typography style guide comes down to replacing many arbitrary decisions with a few deliberate ones. Audit what you have, choose a small number of typefaces, define a fixed type scale, store every value as a design token, and bundle those tokens into a short list of named text styles with clear rules for when to use them. Add accessibility requirements from the start, so the guide protects readers as well as consistency.

Then make sure the guide is connected to reality. Generate specimens from production CSS, lint for hard-coded values, give the guide an owner and a changelog, and prune styles that nobody uses. A style guide that is short, specific and built from live code will still be accurate a year from now, which is the real test of whether it works.