How to analyze typography hierarchy from a live website

Learn how to map a live website's type hierarchy, compare fonts, and turn observed sizes, weights, and spacing into a practical design checklist.

analyze typography hierarchy from a live website

Contents

  • [Start with the visible reading order](#start-with-the-visible-reading-order)
  • [Build a role table](#build-a-role-table)
  • [Check relationships across screen sizes](#check-relationships-across-screen-sizes)
  • [Turn the review into a usable type system](#turn-the-review-into-a-usable-type-system)
  • [Use this in your AI agent](#use-this-in-your-ai-agent)

To analyze typography hierarchy from a live website, map each text role from largest and most prominent to smallest and most supporting. Record its family, size, weight, line height, color, width, and spacing, then compare how those choices guide reading order. The useful result is a role-based type scale you can apply to a new page, not just a list of font names.

Start with the visible reading order

Open the page at the viewport your visitors use and record the text in the order it draws attention:

  1. Brand mark or navigation label
  2. Main headline
  3. Supporting statement or introduction
  4. Primary and secondary buttons
  5. Section headings
  6. Body copy and lists
  7. Captions, metadata, labels, and helper text

For each role, note whether it is visually dominant because of size, weight, contrast, width, position, or surrounding space. A smaller label can still feel important if it uses a strong color or sits alone above a headline. Hierarchy comes from the combination of these choices.

The examples below include a captured Linear typography reference. Its observed system includes Inter Variable as the primary sans serif, Berkeley Mono as a supporting monospace face, and Tiempos Headline as an occasional editorial display face. Treat these as observations from that captured reference, not as a universal recipe or proof of the site's complete internal design system.

Captured pages

Fonts captured on linear.app

Build a role table

Use a table while reviewing the page:

RoleFamilySizeWeightLine heightSpacingPurpose
Display headingSans or displayobserved valueobserved valueobserved valuetight or openSets the page promise
Section headingSans or displayobserved valueobserved valueobserved valuetight or openStarts a new idea
BodySans or serifobserved valueobserved valueobserved valuecomfortableCarries the explanation
LabelSans or monoobserved valueobserved valueobserved valueoften trackedIdentifies an action or group

Record repeated values before isolated exceptions. A site may use many text sizes, but its hierarchy usually depends on a smaller set of recurring roles. Capture the rendered values rather than relying only on stylesheet declarations, because inherited rules and responsive overrides can change what visitors see.

Check relationships across screen sizes

A good hierarchy has clear jumps between roles. Ask whether a section heading is visibly distinct from body copy at a glance, whether supporting text explains the headline without competing with it, and whether labels remain legible at their actual size. Also check line length. A large headline that spans too widely can lose impact, while body text that runs across the full screen becomes harder to scan.

Review responsive states when available. Mobile layouts often reduce headline size, change line height, and stack controls without changing the underlying roles. Record the change as a rule, such as "display heading drops one step below 768px," rather than copying only the desktop value. Check whether font loading or fallback fonts change wrapping, button widths, or vertical rhythm.

Turn the review into a usable type system

After collecting the roles, make four decisions:

  • Choose one default text family for most interface and body content.
  • Add a second family only when it has a clear job, such as code, data, or editorial emphasis.
  • Define a small size scale with named roles instead of styling each element separately.
  • Set maximum line widths for headings and paragraphs so hierarchy survives different screens.

Test the result on a real page containing a headline, paragraph, button, card title, label, and long-form text. If two roles look interchangeable, increase their difference through size, weight, line height, or spacing before adding another font. Verify small text contrast and keyboard focus separately from the type hierarchy.

Typography analysis can identify what a captured page appears to use, but it does not prove ownership of an official internal design system. If you need a production-ready system, verify observations against your own source files, design tokens, and accessibility checks. Keep the captured evidence separate from your adoption decisions.

Use this in your AI agent

> Analyze the typography hierarchy of the live website I provide. Return a role table covering navigation, display headings, section headings, body text, buttons, labels, captions, and code or data text. For each role, report the observed family, file or variant when available, size, weight, line height, color, spacing, and responsive changes. Separate repeated system patterns from one-off exceptions, compare the roles by visual importance, and finish with a compact type scale and implementation checklist. Mark anything that needs manual verification.

Install Fudge for your AI agent to review captured website references alongside your own design questions.

How can I tell whether a second font is part of the hierarchy or just used for decoration?

Check the second family across several roles before treating it as a system choice. If it appears in repeated interface elements, code blocks, labels, navigation, or headings with consistent weights and spacing, it likely has a defined job. If it appears only once in a hero phrase or campaign section, describe it as a display treatment or one-off use.

Compare more than the family name. Note its size, weight, letter spacing, line height, and surrounding space. A monospace face may be used for technical labels, while a serif may mark editorial emphasis. The role matters more than the fact that the font is different.

Also check whether the fallback changes the layout. A family used throughout the page needs reliable loading and a sensible fallback, while a decorative face may be optional. In your final notes, use labels such as "primary interface family," "technical label family," or "editorial display family," and cite the repeated evidence for each label.

What should I do after I have mapped the site's typography roles?

Turn the map into a small test page before applying it across a product. Include a long headline, two paragraph lengths, a button row, a card, a label, and a code or metadata example if the site uses one. Test the page at desktop and mobile widths.

Look for three problems: roles that are too similar, text that wraps unexpectedly, and small labels that lose readability. Fix those with a narrower role scale, a maximum text width, adjusted line height, or stronger contrast. Avoid adding more font families until those basics work.

Finally, write the result as named tokens such as display, heading, body, label, and caption. Record source observations separately from your decisions. That keeps the reference useful without implying that you own or copied the original site's internal design system.