Website Font Detector for Claude Code

Use Claude Code with Fudge to inspect website fonts, compare visual alternatives, and turn observed typography into practical CSS and design notes.

website font detector for claude code

Contents

  • [A practical font-checking method](#a-practical-font-checking-method)
  • [What to ask Claude Code to check](#what-to-ask-claude-code-to-check)
  • [Choosing a close alternative](#choosing-a-close-alternative)
  • [A checklist before you ship](#a-checklist-before-you-ship)
  • [Use this in your AI agent](#use-this-in-your-ai-agent)

The most useful website font detector for Claude Code is a workflow that identifies the font family, checks its weights and usage, then compares the result with nearby alternatives. Use the captured page as evidence, but verify the output against visible headings, body text, buttons, navigation, and code samples before adopting it.

A practical font-checking method

  1. Start with the page area that matters. Check the homepage, product screen, documentation page, or marketing section where you want to match the typography. A website may use different families for interface text, editorial headings, and code.
  2. Record the family and role. Note the family name, whether it is variable or static, and where it appears. Useful roles include body text, headings, labels, navigation, buttons, and monospace code.
  3. Check the actual variants. Compare the weights and styles used on the page. A family name alone is not enough. A page can feel different because it uses a lighter weight, tighter tracking, a larger line height, or a separate display face.
  4. Test a short sample. Use the same phrase in the candidate font at the observed size and weight. Compare letter width, punctuation, numerals, lowercase shapes, and line wrapping.
  5. Separate identification from substitution. If the exact font is unavailable, choose an alternative based on width, x-height, stroke contrast, and spacing rather than on the name alone.

The supplied references give useful pages to inspect before making a recommendation. They include a Notion Developer Platform page, a Claude Code page, and an Exa MCP Server page. The font evidence supplied with this task is a separate captured Linear reference, which lists Inter Variable as a primary sans serif, Berkeley Mono as a supporting monospace face, and Tiempos Headline as an occasional editorial display face. Treat those details as observations from that capture, not as claims about every page from any of these companies.

Captured pages

Fonts captured on linear.app

What to ask Claude Code to check

Give Claude Code a narrow instruction instead of asking for a vague "font detector" result. Ask it to return:

  • family name and confidence level
  • font file or source information when visible
  • weight, style, size, and line height by text role
  • whether the family appears variable
  • likely fallback fonts
  • a short comparison with two or three alternatives
  • uncertainty that still needs a browser check

A useful report separates observed details from inferred matches. For example, "Inter Variable appears on the captured interface at weight 400" is different from "Inter is probably used across the entire product." That distinction prevents a single heading or button from being treated as the site's complete type system.

When asking Claude Code to inspect several captures, request one result per page and role. This makes it easier to spot a family that appears consistently and to distinguish a local display choice from a broad interface choice. Ask for the viewport and page state when those details affect wrapping or responsive behavior.

Choosing a close alternative

Use this quick decision framework:

  • Choose a neutral UI sans when the reference is compact, highly legible, and consistent across controls.
  • Choose a humanist sans when the reference has open counters, more varied letter shapes, or a warmer feel.
  • Choose a grotesk when the reference depends on tight, geometric forms and dense headlines.
  • Choose a monospace only for code, technical labels, or deliberately fixed-width content.
  • Choose a serif display face when contrast, editorial rhythm, or distinctive headline shapes carry the design.

Then compare the same words at the same width. If the replacement wraps earlier, check tracking, weight, and x-height before changing size. A visually similar family with the wrong width can change the entire layout. Also compare numerals, punctuation, lowercase shapes, and the width of common button labels.

A checklist before you ship

Confirm the family across at least three roles, check regular and bold weights, compare mobile line wrapping, inspect numerals and punctuation, and test the fallback stack with the font disabled. Keep a short note that labels each result as observed, likely, or still unverified. This makes the decision useful to both a designer and an engineer.

Do not add font-face declarations for files that have not been verified. If the exact family cannot be confirmed, present the closest visual match as a recommendation and explain what still needs checking. Keep licensing and delivery decisions separate from visual identification unless you have authoritative information about the font's terms.

Use this in your AI agent

> Check the captured website typography for the main interface, headings, body copy, buttons, navigation, and code. Return observed font families, files or variants when available, sizes, weights, line heights, and likely fallbacks. Separate observed facts from guesses, compare each candidate with two practical alternatives, note viewport-specific differences, and finish with a concise CSS font-stack recommendation that does not include unverified font files.

Install Fudge for your AI agent

How can I tell whether the detected font is really used across the whole site?

Check several page types rather than relying on one hero section. Compare a marketing page, a product or dashboard view, a documentation page, and any code-heavy section. Record the family, weight, size, and line height for the same roles on each page.

Look especially for changes between display headings and interface text. A site may use one sans for navigation and body copy, a serif for editorial headlines, and a monospace face for code. Also check whether a different font appears after a modal opens, inside a table, or at a mobile breakpoint.

Disable the suspected web font in a browser test and compare line wrapping, button widths, numerals, and the shape of lowercase letters. If the layout changes substantially, the family is doing real work. If only one isolated title matches, describe it as a local use rather than a site-wide type system.

Ask Claude Code to organize the result by page and role, then flag families that appear consistently. Keep the final recommendation limited to what the checked pages support, and label any broader conclusion as unverified.

Can you give me a Claude Code prompt for turning the font findings into CSS?

Use this prompt after you have a typography report:

> Turn the observed website typography into a maintainable CSS proposal. Create named font-family stacks for interface sans, display heading, and monospace roles only when the evidence supports them. Include font-face declarations only for verified files or URLs. For each role, list the observed weight, size range, line height, and tracking, then propose responsive values for narrow and wide screens. Preserve the original findings in comments marked observed, and mark every fallback or substitution as a recommendation. Do not claim a font is site-wide unless it appears consistently across the checked pages. Finish with a small test checklist covering headings, body copy, buttons, numerals, code, and mobile wrapping.

Before using the CSS, compare it with the reference at the same viewport widths. If the replacement changes wrapping or control sizes, adjust the family or tracking before changing the layout. Do not add licensing or file-hosting claims unless they have been verified separately.

Related questions