Inspect a website's dark mode color palette

Contents

• [Start with surfaces, then check text](#start-with-surfaces-then-check-text)
• [Compare roles instead of copying light mode](#compare-roles-instead-of-copying-light-mode)
• [Dark mode inspection checklist](#dark-mode-inspection-checklist)
• [Make the review actionable](#make-the-review-actionable)
• [Use this in your AI agent](#use-this-in-your-ai-agent)

The best tool for inspecting a website's dark mode palette should show more than a list of hex values. It should connect each color to its visible role, such as page background, surface, body text, muted text, border, button, link, icon, and focus treatment, so you can tell whether the dark theme is consistent and readable.

Start with surfaces, then check text

Review dark mode from the largest areas to the smallest details:

1. Page background: Identify the main canvas color and whether it is truly black, charcoal, navy, green-tinted, or another dark neutral.
2. Raised surfaces: Compare cards, navigation bars, dialogs, inputs, and code areas with the page background. Small shifts in lightness should create hierarchy without making every panel look outlined.
3. Primary text: Check headings and body copy against each surface where they appear.
4. Secondary text: Inspect labels, helper copy, timestamps, placeholders, and metadata. These often become too dim after a light theme is inverted.
5. Actions and states: Review buttons, links, borders, icons, hover states, focus rings, errors, and success messages.

This order matters because text contrast cannot be judged separately from the surface underneath it. A muted label may work on the page background but disappear inside a darker card. A border that is visible around a panel may become distracting around every input if the same color is reused without adjustment.

Compare roles instead of copying light mode

Dark mode usually works better as a related set of roles than as a light palette with every value reversed. Keep the brand direction, but decide which colors need to become lighter, less saturated, or more neutral for dark surfaces. Bright saturated colors can appear stronger against charcoal, so a direct copy may make links, alerts, and buttons compete with the content.

The supplied examples show a muted green direction with colors including #233f2a, #254f1a, #295631, #556659, and #799c92. Use the example below to compare how a green family might move from deep surfaces to softer supporting tones. These colors are reference material, not verified dark-mode tokens for a particular website. Check the actual page states before adopting any value.

For each repeated color, ask: What role does it serve? What surface sits behind it? Does it need to remain the same in light and dark mode? A brand color may stay stable in a logo while using a lighter companion shade for links and a darker surface shade for selected navigation. Naming those roles prevents one adjustment from affecting unrelated elements.

Dark mode inspection checklist

• Is the main content separated from cards and navigation without relying only on shadows?
• Can body text, labels, placeholders, and disabled controls be distinguished from one another?
• Do links look like links without becoming the brightest element on the page?
• Are borders visible enough to define inputs and tables but quiet enough to avoid visual noise?
• Does the primary button have readable text and a clear relationship to the background?
• Is keyboard focus visible on dark surfaces and around dark buttons?
• Do error, warning, and success colors remain distinct from the brand accent?
• Do images, gradients, and translucent overlays change how nearby text reads?
• Are hover and selected states visible without creating large jumps in brightness?

A useful handoff groups the result into surface, text, action, state, and decorative roles. Include a screenshot or location for every exception. If a color appears in several roles, flag it for a design decision rather than silently assigning it a new meaning.

Make the review actionable

After identifying weak areas, fix the smallest set of roles that solves the problem. You may need a lighter muted-text value, a slightly brighter border, a less intense accent, or a different surface for elevated content. Recheck neighboring components because changing a background can affect every label, icon, and input placed on it.

Open the example below and compare the first visible surface, the strongest accent, and the softest text tone. The goal is not to copy the swatches. The goal is to see whether the palette has a clear brightness order that visitors can understand quickly.

Use this in your AI agent

> Inspect the saved website reference in dark mode. Group the observed colors by page background, raised surface, primary text, muted text, border, action, link, focus, and status roles. Compare repeated colors across components, note where contrast or hierarchy may be weak, and explain which roles should change together. Separate verified observations from suggestions and preserve the site's existing visual direction. > > Install Fudge for your AI agent

Look for a clear but restrained brightness order. The page background should establish the deepest or broadest level, while cards, navigation, inputs, and dialogs should separate from it through a small change in lightness, a border, or both. If every surface is the same dark value, the page can feel flat. If every panel is much brighter, the interface can become noisy.

Review common layouts rather than one isolated card. Compare the main canvas to a card, then compare a nested input or selected state inside that card. Check whether the edges remain visible at normal screen brightness and on a lower-quality display. Shadows often become less useful on dark surfaces, so a subtle border or surface shift may communicate structure more reliably.

Do not assign hierarchy using brightness alone. Spacing, grouping, typography, and consistent component treatment should reinforce it. If a card only works because its background is very bright, try a smaller surface shift plus clearer padding and a quiet border. Check text and icons again after each surface change because their contrast will change with it.

Give the developer a short role-based table rather than an unlabelled swatch list. Include the token or color name, observed value, intended role, surfaces where it appears, and any state that needs a separate value. Useful groups include canvas, surface, surface-raised, text, text-muted, border, action, action-text, link, focus, error, warning, and success.

Add a few representative component examples: a button, input, card, navigation item, alert, and link inside body copy. For each, note default, hover, focus, selected, and disabled states when they exist. Include the exact page location or screenshot so the developer can verify the observation in the browser.

Separate confirmed values from proposed replacements. Mark shared colors that currently serve several roles, since those may need to be split into separate tokens. Finish with a checklist for desktop, mobile, keyboard focus, long text, and content over images. This makes the handoff useful even when the final code names or theme structure have not been decided.

Related questions

• Inspect Text and Background Contrast on a Website
• Inspect accessible CTA colors on a website
• A tool for inspecting a website's color palette
• Extract a Website Gradient Palette from a URL