# Inspect Text and Background Contrast on a Website [Open the live Fudge conversation](https://design.withfudge.com/share/tool-for-inspecting-text-and-background-contrast-on-a-website) Last updated: 2026-08-25 A useful tool for inspecting text and background contrast should compare each visible text or control color with the surface directly behind it. The practical result is a list of readable combinations to keep, weak combinations to revise, and components that need a separate check because their background changes by state. ## Start with the combinations people use Do not test only the main heading against the page background. Review the combinations visitors actually encounter: - Body text on the main page surface - Headings on cards, panels, and banners - Muted text and metadata on raised surfaces - Placeholder text inside inputs - Links in normal, hover, and visited states - Button labels against button fills - Icons that communicate meaning without nearby text - Focus rings against both the component and the surrounding page - Error, warning, success, and information messages - Disabled controls, where low contrast may be intentional but still needs context The same text color can pass on one surface and fail on another. Record the foreground, background, component, and state together rather than saving a contrast number without context. If you are checking against an accessibility standard, apply the relevant threshold for the text size and role, and record the standard used. The examples below include observed green colors ranging from dark values such as `#496c10` and `#254f1a` to lighter values such as `#2a966f` and `#799c92`. They are useful references for thinking about relationships between text, accents, and surfaces, but they are not proof that any particular pair passes. Open the example and check each color where it is used. ## Captured pages [![Pangram AI Detector](https://pin.fontofweb.com/9687?format=jpg)](https://design.withfudge.com/share/pin-9687) [Pangram AI Detector](https://design.withfudge.com/share/pin-9687) ## Colors - `#496c10` - `#15502e` - `#14532d` - `#233f2a` - `#254f1a` - `#1e6f30` - `#295631` - `#556659` - `#4a5a4a` - `#2c7a4a` - `#2a966f` - `#799c92` ## Use a repeatable review checklist For each component, work through this sequence: 1. Identify the visible foreground: text, icon, border, or focus indicator. 2. Identify the actual background, including gradients, images, and overlays. 3. Test the default state and interactive states separately. 4. Check large text, normal text, and small text as different cases. 5. Check both light and dark page states when both exist. 6. Record whether the color is essential, decorative, or redundant. 7. Decide whether to change the foreground, background, or component treatment. A failing pair does not always require making text brighter. You might darken a light surface, reduce the saturation of an accent, add a solid panel behind text, increase font weight or size, or replace color-only communication with a label or icon. Choose the least disruptive change that preserves the intended hierarchy. ## Check more than text Borders and icons deserve their own review. A field outline may technically exist but be hard to locate against the page. A gray icon may be too faint to distinguish from decorative artwork. Focus indicators need to remain visible beside similar-colored surfaces. Test hover, pressed, selected, invalid, and loading states because these are often where the palette becomes inconsistent. Do not treat disabled controls as a general excuse for faint text. If people still need to understand why an action is unavailable, add supporting explanation or a clear state label. Likewise, do not rely on color alone to communicate success or failure. Pair color with text, shape, an icon, or another visible cue. ## Turn findings into fixes Group findings by shared role. If many components use the same muted text color and all are weak, one token change may fix the page. If only a single banner fails because it uses a unique background, fix that component instead. Keep a table with the component, state, foreground, background, result, proposed fix, and owner. After changes, review the actual page again. A palette report tells you which combinations need attention, but it does not replace checking layout, content, focus behavior, or interaction states. When you save an implementation reference, distinguish observed colors and contrast notes from final approved design tokens. The former describes the current page; the latter is a design decision that still needs review. ## Use this in your AI agent > Inspect the saved website reference for text and background contrast. Create a component-by-component checklist covering body text, headings, muted labels, links, buttons, inputs, icons, borders, focus rings, and success, warning, error, and disabled states. For each item, identify the foreground color, actual background, page state, and whether the combination needs review. Group repeated problems by shared color role, propose the smallest practical fix, and do not invent pass or fail results where the captured evidence does not support them. Use the examples below as references, not as automatic approvals. [Install Fudge for your AI agent](/mcp) --- Start with combinations that affect the most reading and navigation. Check body text on the main surface, headings on the primary content surface, navigation labels, links, buttons, and form labels first. These combinations appear often and expose broad palette problems quickly. Next, check muted text, placeholders, borders, icons, and focus indicators. These details are easy to overlook because they are visually quiet, but they can make a page difficult to scan or operate. Review them on the surfaces where they actually appear, not only against the base background. Then test hover, pressed, selected, invalid, success, warning, loading, and disabled states. A component may look fine at rest but lose clarity when its background or border changes. Include overlays, banners, images, and gradients because they can alter the background behind text. If time is limited, record the ten combinations that appear most frequently and the five that carry the most important actions. Fix shared colors before one-off components, then rerun the same checklist. This gives you a practical order of work without pretending that every visual detail has equal impact. --- Use a table that connects each finding to a component and a proposed change. Useful columns are: component, state, foreground, background, observed use, issue, suggested adjustment, and verification status. Include the page or screen where the combination appears so the developer can reproduce it. Separate shared fixes from local fixes. A repeated muted-text problem belongs with the shared color, while a single colored banner may need its own background or text treatment. If a change affects a button, check its hover, pressed, focus, and disabled states at the same time. Write fixes in concrete terms. For example: replace the secondary label color on dark cards, add a solid background behind text over imagery, strengthen the focus outline, or add a visible status label beside the color cue. Avoid handing over only ratios or hex codes because implementation still needs component context. After implementation, ask for screenshots or a live review of the same states. Mark each finding as fixed, intentionally retained with a reason, or still open. Keep the original observed colors beside the revised values so the team can see which changes were design decisions rather than facts about the source page. ## Related questions - [A tool for inspecting a website's color palette](/share/tool-for-inspecting-website-color-palette-on-a-website) - [Inspect a website's dark mode color palette](/share/tool-for-inspecting-dark-mode-color-palette-on-a-website) - [Inspect accessible CTA colors on a website](/share/tool-for-inspecting-accessible-cta-colors-on-a-website) - [Inspect a Website's Gradient Palette and Color Use](/share/tool-for-inspecting-website-gradient-palette-on-a-website)