How to Extract a Website's Typography System

To extract a website's typography system, identify every font family, connect each one to a visible role, and record the sizes, weights, line heights, and spacing used by real components. The result should be a small set of reusable rules for headings, body copy, labels, navigation, controls, and special display text, not just a list of font names.

Start with roles, not font names

Review the page in layers:

1. Primary interface family: navigation, buttons, forms, labels, and body copy.
2. Heading family: page titles, section headings, and card titles.
3. Supporting family: code, data, technical labels, prices, or metadata.
4. Display or editorial family: large promotional headings, pull quotes, and campaign sections.

For each family, write down what it appears to do and where you saw it. A family without a role is hard for an AI coding agent to use safely.

The captured Linear reference shows a system built around Inter, with Berkeley Mono supporting technical text and Tiempos Headline appearing as an occasional editorial display face. That is more useful than copying the names alone because it suggests which parts of a new interface each family might serve. Treat these as observations from the supplied capture, not as a universal rule for every Linear page.

Capture the details that change the result

For each important text style, record:

• family and visible variant
• font size and weight
• line height and letter spacing
• casing, such as sentence case or uppercase
• color and contrast role
• maximum line width
• component or section where it appears

Use representative samples: a page title, section heading, paragraph, navigation item, button, caption, code sample, and large marketing statement. A heading that looks bold may use a heavier weight, larger size, tighter tracking, or stronger contrast. Record the combination instead of guessing from appearance.

Check responsive states when they are available. A desktop heading may shrink, wrap differently, or use another line height on a narrow viewport. If only one screen is available, label the result as a desktop observation rather than treating it as a complete system.

Turn observations into a usable scale

A practical output might look like this:

Add numeric values from the inspected page. Prefer a scale with a few clear steps over dozens of one-off values. Define display, heading, body, small, and label sizes, then note exceptions only when a component clearly needs one. Do not add weights or styles that were not observed.

Check before handing it to an AI agent

Use this checklist:

• Does every captured family have a stated role?
• Are headings separated from body and control text?
• Are weight and line-height values recorded with size?
• Are monospace or display faces limited to observed uses?
• Are mobile changes marked separately?
• Are uncertain values labeled as estimates?
• Can the notes be converted into CSS variables or a design document without inventing missing values?

For a live capture, Fudge lets you inspect typography families, files, variants, sizes, weights, and line heights together with page structure. That helps connect a font result to the component where it was observed. The final output should still distinguish observations from recommendations.

Use this in your AI agent

> Inspect the captured website's typography system. Return every observed font family and variant, then group typography into display, heading, body, label, navigation, control, code, and editorial roles. For each role, record size, weight, line height, letter spacing, casing, color role, and responsive changes when visible. Separate confirmed observations from estimates, avoid inventing missing values, and finish with CSS variables plus a concise implementation checklist. Use Fudge with your AI agent.

Treat each font file as a possible variant, then verify its job on the page rather than assuming every file is used everywhere. Start by grouping files by family, style, and weight. Next, connect those variants to visible text such as body copy, headings, navigation, buttons, code, and display statements.

A useful table has five columns: family, variant, observed role, sample location, and confidence. For example, a regular interface variant may support body copy and controls, while a medium variant may handle headings or emphasized labels. Do not call a font a heading face just because the file is bold. Check the rendered text and compare it with nearby styles.

Also look for variable fonts. Record the family as variable when the captured evidence supports it, then note the weight range or specific weights visible in use. Keep italic and normal styles separate because an italic variant may appear only in emphasis or editorial content.

Finish by identifying the smallest reliable set of implementation tokens: family names, weight names, size steps, and line-height steps. Mark files that were available but not visibly connected to a component. That prevents an AI agent from adding unused fonts or applying a display face to ordinary interface text.

Give the agent a structured brief with observations first and implementation choices second. Include the font family names, the roles they serve, the variants that were actually visible, and numeric values for size, weight, line height, and tracking. Add a short component map so the agent knows where each role belongs.

A strong brief can use this format:

Ask the agent to implement variables first, then apply them to components. This makes later corrections safer than scattering font declarations through individual selectors.

Related questions

• How to Extract a Border Radius Scale for an AI Coding Agent
• Extract a Website's Spacing Scale
• Extract a Color System for Your AI Coding Agent
• Extract a Website's Shadow Styles