Website Design Tokens Extractor from a URL

To extract design tokens from a website URL, collect repeated visual decisions first: font families and weights, text sizes, colors by role, spacing steps, corner radii, borders, shadows, button styles, and container widths. Treat the result as an observed reference for your own work, not automatically as the site's official internal design system.

Start with repeated patterns

Review several parts of the page before naming a token. A color used once in an illustration is not necessarily a brand color. A margin around one unusual component is not necessarily part of the spacing scale. Look for values that repeat across navigation, headings, body copy, buttons, cards, forms, and footer content.

A practical capture sheet can use these columns:

Separate exact observations from interpretation. For example, write "Inter appears in regular and medium weights" before deciding that your project needs body and heading tokens with those names.

Compare the page at different levels

Inspect the page in three passes. First, review the overall structure: header, hero, sections, calls to action, and footer. Second, compare repeated components such as buttons, cards, links, inputs, and badges. Third, inspect typography and color details within those components.

For the Linear reference, the supplied evidence shows Inter at weight 400 for body copy, labels, navigation, and controls, with weight 500 for headings and emphasized interface text. The useful lesson is not that every project should use Inter. It is that a small type system can create contrast through size, weight, and muted color rather than requiring many unrelated fonts.

Ask which values repeat exactly, which differences come from state or context, whether the page follows one spacing rhythm, and whether the accent color marks actions consistently. Also check whether borders and shadows support grouping without making every card look heavy.

Convert observations into a usable token set

Keep the first version small. Define body and display fonts, three or four text sizes with matching line heights, semantic background, surface, text, muted, and accent colors, a short spacing scale, small and medium radii, and one or two shadow levels. Add button, card, input, and link rules with their visible states.

Use semantic names such as --color-accent instead of names tied to one screenshot such as --blue-500. Record the source page, capture date, viewport, and whether each value was observed directly or estimated. This makes later review much easier.

Check before you reuse anything

A token extraction does not prove ownership, licensing, accessibility, responsive behavior, or the existence of an internal design system. Verify font licensing and brand permissions yourself. Test text and controls at the sizes you plan to use. Compare light and dark surfaces, keyboard focus, hover states, and narrow screens. If you need an official system, look for the site's own documentation or design-system materials rather than inferring it from one page.

The most useful output is a compact reference containing token name, value, role, source observation, and confidence. After reviewing the values and removing one-off styles, export the confirmed observations to CSS, Tailwind v4, JSON, or DESIGN.md.

Use this in your AI agent

> Extract an observed design reference from this website URL. Inspect the page structure, typography, colors by role, spacing, borders, radii, shadows, containers, and repeated component states. Separate directly observed values from estimates, identify which values repeat, and return a small semantic token set for CSS or Tailwind v4. Include the source page and viewport assumptions, flag anything that needs manual verification, and do not describe the result as the site's official internal design system.

Install Fudge for your AI agent.

Start with the tokens that affect the largest number of decisions. Extract body and heading font families, common weights, text colors, background colors, accent color, container width, section spacing, and button shape before investigating unusual effects.

A good first pass includes heading, body, muted, and label roles. Record font size and line height together, because the same size can feel very different with a tight or generous line height. For color, name roles rather than individual swatches: background, surface, text, muted text, border, accent, success, warning, and danger if those states appear repeatedly.

Next, identify spacing values that recur around sections, cards, and controls. A short scale that explains most of the page is more useful than a long list of exceptions. Add radii, borders, and shadows only after checking whether they repeat across components. Finish with button and input states, since these reveal how the visual language works in practice.

First, separate reference from decision. Copying observed values into variables is not the same as having a complete design system. Review each value for readability, responsive behavior, interaction states, and whether it fits your product's tone.

Create semantic variables for roles such as --color-text, --color-muted, --color-surface, --color-accent, --font-body, and --radius-md. Map repeated observations into those roles, then build a small sample page with headings, paragraphs, links, buttons, cards, inputs, alerts, and focus states. This exposes gaps faster than storing tokens without using them.

Keep a note beside each token that says where it came from and whether it was observed or estimated. Check font permissions and contrast yourself. Test the system at mobile width and on every dark or tinted surface it needs to support. A useful design system lets components share rules while still handling states and changing content.

Related questions

• Extract Gradient Styles From a Website URL
• Extract website interaction patterns from a URL
• Extract a Complete Design System From a Website URL
• Website Media Styles Extractor from URL