Capture a Website Color System for Reuse
Learn how to capture a live website's colors, assign practical roles, check contrast, and turn the result into reusable design tokens.
capture color system from a live website for reuse
The fastest way to capture a website color system is to record repeated colors, sort them by practical role, check how they work together, and save the result as reusable tokens. Do not treat every visible shade as a separate brand color. Start with the colors that control backgrounds, text, actions, borders, and states.
Start with roles, not hex codes
Use this capture sheet while reviewing the site:
| Role | What to record | Questions to ask |
|---|---|---|
| Page background | Main canvas and alternate surfaces | Is the page white, tinted, dark, or layered? |
| Text | Primary, secondary, muted, and inverse text | Which shades carry readable content? |
| Action | Buttons, links, selected states, and focus states | Is one color repeated for interaction? |
| Accent | Highlights, badges, illustrations, or decoration | Does it support or contrast with the action color? |
| Border | Dividers, cards, inputs, and inactive controls | Is it neutral, tinted, or nearly invisible? |
| Feedback | Success, warning, error, and information | Are these distinct from the brand palette? |
Record the source location beside each color. A green used for a button is more useful than an isolated green in an illustration because its role is easier to reuse. Also note whether a color appears repeatedly or only once.
Captured pages
Colors
#496c10#15502e#14532d#233f2a#254f1a#1e6f30#295631#556659#4a5a4a#2c7a4a#2a966f#799c92
Compare the captured palette
The captured Pangram page shows a muted green direction, including deep greens such as #15502e and #14532d, lighter green accents, and restrained gray-green shades. Treat these as observed reference values, not as a complete inventory of every color on the site.
A practical first grouping could be:
- Deep green: primary text on light surfaces, dark buttons, or strong headings.
- Mid green: links, active controls, and secondary actions.
- Light green: soft backgrounds, selected states, or decorative emphasis.
- Gray-green: borders, muted labels, and supporting content.
- Light neutral: page or card surfaces when the design needs separation.
These groupings are recommendations. Keep the original hex values and record the component where each appeared. A source color can serve as an action color in one context and an accent in another, so avoid assigning permanent roles without checking usage.
Check contrast and states
A reusable color system depends on readable combinations. Test text against the actual surface it sits on, not against a white swatch. Check normal body text, large headings, button labels, links, placeholder text, disabled controls, and focus indicators separately.
Use this review sequence:
- Test primary text on the main background.
- Test inverse text on the strongest action color.
- Test muted text on cards and alternate surfaces.
- Check borders against both the surface and surrounding page.
- Review hover, selected, focus, success, warning, and error states.
- Check grayscale to confirm that hierarchy does not depend only on hue.
If two colors look different but serve the same role, keep the one with better readability and note the other as an optional variant. If a pair has not been tested, label it as unverified rather than presenting it as ready for production.
Save a reusable token set
Use names that describe purpose rather than appearance. For example:
These values are a draft mapping, so replace them after checking the live page and contrast results. Keep semantic roles separate from raw palette values. A useful handoff includes observed swatches, role assignments, contrast checks, state values, and a small token file.
Fudge lets you help inspect a captured page's color roles, contrast, spacing, and component treatment, then export supported observed details for reuse. The capture remains the reference, while your token names and theme adjustments remain recommendations.
Use this in your AI agent
> Inspect the captured website for repeated colors and practical roles. Return a table of raw hex values, likely roles, source components, contrast concerns, and suggested semantic tokens. Separate observed colors from recommendations, and finish with a reusable CSS variable set.
How should I turn the captured colors into a light and dark theme?
Start with semantic roles that stay constant between themes, then assign different values to each mode. Keep names such as text-primary, surface, action, and border stable so components do not need to know whether they are in light or dark mode.
For a light theme, a deep green may work as primary text or a button background while the page uses a pale neutral surface. For a dark theme, that same deep green may need to become a brighter accent, while text moves toward a light neutral and borders become low-opacity light tones. Do not simply invert every hex value.
Check primary text on the page surface, secondary text on cards, action text on the action background, focus rings against both the component and page, and feedback states against both modes. If a captured green loses contrast in dark mode, use a lighter approved variant and document it as a theme adjustment rather than an observed source value.
What should I include in a color handoff for a developer?
Give the developer a small, tested package instead of a long swatch list. Include the raw colors, semantic tokens, usage examples, and known exceptions.
A useful handoff includes the palette with source locations, semantic roles for page, surface, text, muted text, action, accent, border, and feedback, plus hover, pressed, selected, focus, disabled, success, warning, and error values. Add contrast notes for tested pairs and identify any combinations that need caution.
Include component examples for buttons, links, inputs, cards, navigation, and alerts. Add light and dark mappings when both modes are supported. Mark recommendations separately from observations so later revisions remain easy to audit. A CSS variables file or JSON object is usually enough for implementation, with a short DESIGN.md explaining choices and exceptions.