Extract a Website's Color System

To extract a website's color system, collect the colors that appear repeatedly, group them by visual role, and check how each color behaves in real components. A useful result is more than a list of hex values: it should explain which colors belong to backgrounds, text, borders, actions, states, and accents.

Start with a role-based color inventory

Review the page from the outside in. First record the main canvas color, surface colors, and the strongest text colors. Then look at buttons, links, icons, borders, badges, alerts, illustrations, and hover or selected states. For each color, note:

• The value, such as a hex or RGB color
• Where it appears
• Whether it is a background, foreground, border, accent, or status color
• Whether it is common or used only once
• Which colors it sits beside

This prevents a common mistake: treating every visible shade as an independent design token. A color used once in an illustration may not belong in the reusable interface system, while a slightly different gray used across cards and controls may deserve its own surface role.

The captured Pangram page shows a muted green direction, with observed colors ranging from dark forest greens to softer gray-green tones. That is a useful reminder to separate the main brand accent from supporting text, surfaces, and secondary actions rather than calling every green the primary color.

Turn raw colors into practical roles

A compact token map might look like this:

Use the page structure to decide whether two close colors are genuinely different roles. For example, a dark green used for a primary button may need a lighter hover value, while a pale green used behind a message should remain separate because its job is to support readable text. Keep state colors distinct from brand colors when they communicate meaning.

The captured color set includes #496c10, #15502e, #14532d, #233f2a, #254f1a, #1e6f30, #295631, #556659, #4a5a4a, #2c7a4a, #2a966f, and #799c92. Treat these as observed starting points, not as a finished token system. Compare their placement and contrast before assigning names.

Check contrast in context

Test text against the exact background where it appears. A color can work on a white card but fail on a tinted surface, or work for large display text but fail for small navigation labels. Check normal body text, muted text, button labels, links, icons that carry meaning, and focus or selected states.

Also check interaction states. A hover color should remain readable, a disabled color should still be distinguishable without suggesting that an active control is available, and a focus outline should be visible against both the page canvas and the component surface. Do not fix every contrast issue by making everything darker. Sometimes changing the background or adding a border produces a closer match to the original design.

Make the result reusable

Once roles are clear, write the system in a format your team can use. A CSS version could be:

Keep the original observed values beside the normalized names. That preserves a useful audit trail and makes it easier to revise a token when further pages reveal another surface or state. A practical final checklist is: sample more than one page, include interaction states where available, assign roles before naming colors, test contrast by component, and mark uncertain values for later review.

Use this in your AI agent

> Extract the color system from the captured website. List observed colors with their page locations, group them into canvas, surface, text, border, accent, and state roles, identify repeated versus one-off colors, check text and control contrast in context, and return a compact CSS variable table with notes about uncertain assignments. > > Install Fudge for your AI agent

Keep two similar colors separate when they perform different jobs or need to change independently. Common examples include a page canvas and a card surface, primary text and muted text, a button color and its hover state, or a border color and a disabled control color.

A simple test is to replace both values with one shared token in a sample layout. If the result makes hierarchy weaker, reduces contrast, or makes a state hard to recognize, they should remain separate. Another test is change ownership: if a designer might reasonably adjust one use without changing the other, give them different names.

Do not create a token merely because two screenshots contain slightly different pixels. Rendering, transparency, shadows, images, and anti-aliasing can create small variations. Start with repeated flat colors, then confirm each candidate across more than one component or page. Keep uncertain shades as notes until their role is clear.

Include a role-based token table, the original observed values, usage examples, and contrast notes. For each token, provide a name, value, role, common components, and any known states such as hover, selected, focus, or disabled.

A useful handoff has five parts:

1. Canvas and surface colors, including page, card, panel, and elevated areas.
2. Content colors, including primary, secondary, placeholder, inverse, and link text.
3. Borders and controls, including dividers, inputs, focus rings, and buttons.
4. Meaningful states, such as success, warning, danger, and informational colors.
5. Verification notes showing which combinations were checked and which need review.

Keep one or two screenshots or captured page references beside the table. The developer can then see whether a token describes a reusable role or only a decorative color from an illustration. If the handoff needs to become code, ask for CSS variables or Tailwind tokens after the roles have been reviewed.

Related questions

• Extract a Website's Complete Design System
• Extract a Website's Border Radius Scale
• Extract a Website's Component Styles
• Capture a Website Typography System for Reuse