Get the Typography System from a Live Website

Learn how to capture a live website's fonts, weights, sizes, and roles, then turn the observed typography into a practical design reference.

get the typography system from a live website

Contents

  • [Start with the type roles](#start-with-the-type-roles)
  • [Capture the details that make it reusable](#capture-the-details-that-make-it-reusable)
  • [Build a practical type scale](#build-a-practical-type-scale)
  • [Check the system before copying it](#check-the-system-before-copying-it)
  • [Use this in your AI agent](#use-this-in-your-ai-agent)

To get a typography system from a live website, capture the page and record each font family, where it appears, its weight, size, line height, and role. Then group the findings into interface text, display text, editorial text, and utility text so you can reuse the system without guessing.

Start with the type roles

Use this four-part checklist before looking at individual font files:

  1. Interface text: navigation, buttons, labels, forms, menus, and product controls.
  2. Body text: paragraphs, descriptions, help text, and longer reading sections.
  3. Display text: hero headlines, large section titles, and promotional statements.
  4. Utility text: code, metadata, prices, timestamps, tags, and small supporting labels.

A website may use one family across several roles, or it may pair a sans serif with a serif or monospace face. The role matters as much as the family name because a font can look appropriate for a headline but feel cramped in small interface text.

Captured pages

Fonts captured on linear.app

Capture the details that make it reusable

For every observed family, create a short record with these fields:

  • Family name and whether it is variable or static
  • Available weights and styles
  • Typical size range
  • Line height or leading
  • Letter spacing, especially for uppercase labels
  • Text color and contrast against its background
  • The components where it appears
  • Whether it is used for long reading, short labels, code, or display copy

Do not stop at the primary font. Supporting fonts often reveal the site's personality. A monospace family may be reserved for technical details, while a serif may appear only in editorial headlines. Capture those boundaries so your implementation does not use every font everywhere.

The examples below show one observed typography reference from Linear. Compare the family names and stated roles, then use the same recording method on the live site you care about.

Build a practical type scale

After collecting the observations, turn them into a small scale rather than copying isolated values. A useful starting table looks like this:

RoleSize rangeWeightLine-height goal
Display headline48-80px500-7000.95-1.1
Section heading28-44px500-7001.05-1.2
Body text16-20px400-5001.4-1.7
Interface label12-16px500-6001.1-1.4
Utility or code11-14px400-6001.2-1.5

These ranges are a working template, not facts about a particular website. Replace them with the values you observe, then check the result at the smallest viewport you support. If a headline wraps differently or a label becomes hard to scan, adjust the size, width, or line height instead of changing the family immediately.

Check the system before copying it

Use three tests:

  1. Hierarchy test: Can you identify the headline, supporting text, action, and metadata in two seconds?
  2. Reading test: Does body text remain comfortable over several paragraphs?
  3. Consistency test: Do buttons, navigation, cards, and forms feel like the same product?

Also check whether the apparent font choice changes across page sections or states. A captured page can contain a display face used only in one campaign area, so treat each observation as evidence from that page rather than assuming it is the site's universal rule.

Once the records are complete, write implementation tokens such as font-family-interface, font-family-display, text-body, and leading-body. Keep the source observations beside those tokens so another designer can tell what was seen and what was chosen as a design decision.

Use this in your AI agent

> Inspect the typography of the live website I provide. Return the observed font families, font files or variants when available, sizes, weights, line heights, letter spacing, text colors, and the page components where each choice appears. Group the results into interface, body, display, and utility roles. Separate observed details from recommendations, then propose a compact type scale and CSS variables I can use in my own project.

When you are ready to inspect a page with your own agent, install Fudge for your AI agent.

How should I turn the captured typography into CSS variables?

Start by separating direct observations from your chosen implementation values. Direct observations describe what the site uses. Your variables describe how you want to reuse the pattern.

Treat the family names above as an example of how to organize roles, not as a universal recommendation. Confirm that each family is available for your project and that your intended use follows its license. Add responsive values for display sizes, because a desktop headline scale often needs a smaller mobile setting.

Then map the variables to components. Use the interface family for navigation and controls, the body setting for readable paragraphs, the display family only where you want a distinct editorial voice, and the monospace family for technical details. Finally, check real content rather than placeholder text. Long words, numbers, punctuation, and mixed-case labels can change the result significantly.

What should I ask an AI agent to inspect on a website's typography?

Ask for observations in a structured order so the result is useful for implementation:

  1. List every visible font family and identify where it appears.
  2. Record font files, variants, weights, styles, and whether the family is variable when those details are available.
  3. Sample headline, body, label, navigation, button, metadata, and code text.
  4. Record approximate size, line height, letter spacing, casing, and color for each sample.
  5. Group the findings by role instead of returning one long font list.
  6. Mark uncertain values as estimates.
  7. Separate what is observed from what should be changed.
  8. Return CSS variables and a short type scale only after the evidence is organized.

A strong prompt also asks for page context. Typography choices can differ between a landing page, a product dashboard, a blog, and a checkout flow. Ask the agent to note the section, component, and viewport for each observation. That makes it easier to decide whether a font is part of the site's shared system or limited to one page.