Give Claude Code a Website's Typography Hierarchy

Learn how to turn a website capture into a clear typography hierarchy for Claude Code, including roles, font choices, sizing, and responsive rules.

give claude code a website's typography hierarchy

Contents

  • [Start with roles and visual priority](#start-with-roles-and-visual-priority)
  • [Separate font families from hierarchy rules](#separate-font-families-from-hierarchy-rules)
  • [Make the hierarchy implementable](#make-the-hierarchy-implementable)
  • [Use this in your AI agent](#use-this-in-your-ai-agent)

A useful typography hierarchy for Claude Code should explain how text roles differ, not merely name the font family. Give it the typeface, weight, size, line height, width, casing, and usage for each role so it can reproduce the page's reading order.

Start with roles and visual priority

Inventory the text from highest priority to lowest priority:

  1. Display or hero heading
  2. Section heading
  3. Card or feature heading
  4. Introductory paragraph or lead text
  5. Body copy
  6. Navigation and controls
  7. Labels, metadata, and helper text
  8. Code, technical values, or other monospace content

For each role, record the visible properties:

RoleRecord
Font familyExact family when known, otherwise a candidate
WeightNumeric or named weight
SizeRendered size at the captured viewport
Line heightMeasured or estimated leading
Letter spacingEspecially for uppercase labels
WidthMaximum text measure or container width
ColorPrimary, muted, or accent role
Responsive ruleWhat changes at smaller widths

This gives Claude Code enough information to build a hierarchy instead of making every heading a larger version of body text. It also makes uncertainty visible. A captured font result can identify a family, while the exact role still needs to be tied to the text visible on the page.

Open the examples below and compare the type treatment before borrowing it. The captured Linear examples list Inter Variable as the primary sans serif, Berkeley Mono as a supporting monospace face, and Tiempos Headline as an occasional editorial display face. Another captured example describes Inter at different weights for interface text and headings. These are concrete reference observations, not a universal recipe for every developer website.

Captured pages

Fonts captured on linear.app

Separate font families from hierarchy rules

A typography system has two connected but different parts:

  • Family assignments: which font is used for interface text, display text, code, and supporting labels.
  • Hierarchy rules: how size, weight, line height, width, and spacing establish importance.

Claude Code should not assume that a new font family requires a completely new hierarchy. A site can use one sans serif across all roles and create contrast through size, weight, color, and measure. Another site may reserve a serif or monospace face for one narrow purpose.

Ask for an output like this:

Treat those values as formatting examples only. Replace them with observations from the page. Do not invent a role simply because a typical design system has one.

Make the hierarchy implementable

Ask Claude Code to create semantic names such as text-display, text-section, text-body, and text-label, then map each name to CSS or Tailwind variables. Include a fallback stack and keep the original family separate from the fallback.

Have it define the relationship between size and line height. A large heading often needs a tighter line height, while body copy needs enough leading for comfortable reading. The text width matters too: a heading can lose its intended emphasis if it stretches across the entire viewport, and a paragraph can become difficult to scan when its measure is too wide.

Require responsive behavior as an explicit field. For each role, Claude Code should say whether the value is fixed, stepped at a breakpoint, or fluid. If only one viewport is available, it should mark smaller-screen values as recommendations for review rather than facts.

Use this review checklist:

  • Does the largest heading clearly dominate the first screen?
  • Can section headings be distinguished without relying on color alone?
  • Are body paragraphs comfortable to scan?
  • Are labels smaller without becoming difficult to read?
  • Are weights available in the chosen font files?
  • Does the fallback stack preserve similar width and line breaks?
  • Are code or technical strings visually distinct only when the page supports that pattern?

Use this in your AI agent

> Analyze the supplied website capture and produce an implementable typography hierarchy. Identify every visible text role, its font family or best-supported candidate, weight, size, line height, letter spacing, color role, maximum measure, and responsive behavior. Separate family assignments from hierarchy rules. Use semantic names such as display, section, card, lead, body, label, and code only when the captured page supports those roles. Mark unknown values and unavailable font variants instead of guessing. Return a role table, recommended CSS custom properties, a Tailwind-friendly mapping, fallback stacks, and a short visual review checklist for headings, paragraphs, controls, and line breaks. > > When you want to run this workflow from your AI agent, install Fudge for your AI agent.

How can I tell Claude Code which font should be used for headings versus body text?

Give it evidence tied to visible roles rather than a family name alone. For each family, list the text locations where it appears, the observed weight, and whether the difference comes from size, weight, casing, or a separate typeface.

A useful instruction is: "Assign a font family to a role only when the captured typography evidence supports it. If the same family appears in headings and body copy, keep one family assignment and express hierarchy through size, weight, line height, and measure. If a second family appears only in display text, document that limited use."

The captured Linear examples provide a good format for this kind of record: Inter Variable is listed as the primary sans serif, Berkeley Mono as supporting monospace, and Tiempos Headline as an occasional editorial face. Claude Code should preserve those distinctions without assuming every page needs all three. Ask it to flag any heading or body assignment that is inferred rather than directly supported.

What is the best way to check whether the typography hierarchy actually matches the website?

Compare the rendered page in the same viewport and inspect the moments that establish reading order: the hero heading, lead paragraph, primary button, first section heading, card titles, and labels. Check line breaks before fine-tuning colors or letter spacing because a wrong font, width, or line height usually changes the hierarchy more than a small size difference.

Use a side-by-side checklist:

  • Is the hero heading the first text your eye lands on?
  • Does its line break occur at roughly the same place?
  • Is the lead paragraph visibly quieter but still easy to read?
  • Do section headings create clear stopping points?
  • Are card titles stronger than metadata and helper text?
  • Do buttons and navigation remain legible at their smaller size?
  • Does the fallback font cause unexpected wrapping?

Have Claude Code list the largest visual mismatches after the comparison and fix those first. A good sequence is family and weight, text width, size, line height, then tracking and color.