# Email Color Contrast Checker and Palette Audit

> Audit an email color system as a collection of real relationships: body and quiet text, links within surrounding copy, labels on buttons, component boundaries against the canvas, meaningful graphics, transparency, and authored light and dark presentations.

- **Canonical page:** [https://emailbump.com/tools/email-color-contrast-checker](https://emailbump.com/tools/email-color-contrast-checker)
- **Interactive tool:** [Open the email color contrast checker](https://emailbump.com/tools/email-color-contrast-checker)
- **Category:** email accessibility, visual design, design systems, and quality assurance
- **Updated:** July 2026
- **Standards model:** WCAG 2.2 relative luminance and contrast-ratio definitions
- **Supported inputs:** #RGB, #RGBA, #RRGGBB, #RRGGBBAA, rgb(), and rgba()
- **Roles:** text, inline link, user-interface component, meaningful graphic, and decorative or logo exception
- **Privacy:** Color values, labels, notes, calculations, repair candidates, and exports remain in the browser
- **Network boundary:** The tool does not upload a template, fetch remote CSS, render mailbox clients, inspect an image, or modify a design
- **Decision boundary:** Passing source-color ratios does not establish full WCAG conformance, accessible email, reliable dark mode, sufficient semantics, or readability in every client

## Why a palette audit is more useful than a two-color checker

A basic contrast calculator compares one foreground with one background. That arithmetic is necessary, but an email is not one relationship.

A typical message can include:

- a headline over the email canvas;
- body copy over a content panel;
- quiet metadata and timestamps;
- a link inside body text;
- text inside a primary button;
- the button fill or outline against the surrounding canvas;
- an icon against its container;
- status colors that communicate meaning;
- legal and unsubscribe copy in a footer;
- text over a tinted card;
- a logo with an exemption;
- text over an image or gradient;
- fallback colors when an image does not load;
- and different authored or client-transformed colors in dark mode.

Each foreground must be tested against the background immediately behind it. A button label can pass against the fill while the visual boundary that identifies the button fails against the canvas. A link can pass against white yet be indistinguishable from neighboring body copy. A dark-mode token can pass in the source while a mailbox client rewrites only one side of the pair.

The tool therefore maintains a ledger of scenarios. Every scenario records a label, theme, role, source foreground and background, effective composite colors, typography where relevant, full unrounded ratio, applicable threshold, enhanced threshold where defined, link evidence, status, repair candidate, and operator note.

That ledger is the unit of evidence. A single green badge is not.

## WCAG contrast ratio

WCAG contrast ratio uses relative luminance in the sRGB color space.

For each red, green, and blue channel:

1. divide the 0–255 channel value by 255;
2. when the normalized value is at most 0.04045, divide it by 12.92;
3. otherwise add 0.055, divide by 1.055, and raise the result to the power 2.4.

Relative luminance is:

0.2126 × linear red + 0.7152 × linear green + 0.0722 × linear blue

Contrast ratio is:

(lighter luminance + 0.05) ÷ (darker luminance + 0.05)

The possible range is 1:1 through 21:1.

WCAG 2.2 uses the 0.04045 branch point. An earlier WCAG value was 0.03928. W3C notes that the correction has no practical effect in the context of these guidelines, but the tool implements the current definition.

The interface displays ratios to two decimals for scanning. Pass and fail comparisons use the complete calculated number. A computed 2.999:1 does not meet a 3:1 threshold even if a poorly designed interface would round the display to 3.00.

The JSON and CSV exports preserve the unrounded numeric ratio as well as the shortened display value.

## Text thresholds

WCAG 2.2 Success Criterion 1.4.3, Contrast (Minimum), is Level AA.

It requires:

- at least 4.5:1 for normal text and images of normal text;
- at least 3:1 for large-scale text and images of large-scale text.

Success Criterion 1.4.6, Contrast (Enhanced), is Level AAA.

It requires:

- at least 7:1 for normal text;
- at least 4.5:1 for large-scale text.

The tool reports both minimum and enhanced results for applicable text. Meeting enhanced contrast does not imply that the email meets every Level AAA requirement.

### Large-scale text

WCAG defines large-scale text as at least 18 point, or at least 14 point and bold.

Using the CSS reference conversion of 1 point to 1.333 CSS pixels, the tool classifies text as large when:

- its size is at least 24 pixels at any weight; or
- its size is at least approximately 18.67 pixels and the selected weight is at least 700.

This classification models the supplied source values. Email rendering can substitute fonts, synthesize bold, zoom, scale, or ignore part of a style declaration. A source declaration of 18.67 pixels and 700 is not proof that every client presents an equivalent large-scale glyph.

Where a design sits at a threshold, provide margin rather than engineering for the smallest passing value.

### Incidental, decorative, and logo text

WCAG 1.4.3 provides exceptions for:

- text in an inactive user-interface component;
- text that is pure decoration;
- text that is not visible to anyone;
- text that is part of a picture containing significant other visual content;
- and text that is part of a logo or brand name.

The tool records decorative and logo scenarios as exceptions. It does not label them “passes,” because there is no automatic minimum being passed.

An exception is a scope conclusion, not a way to hide useful information. A pale order number, unsubscribe link, expiration date, delivery status, discount code, or instructional icon does not become decorative because its contrast is inconvenient.

Logotype text can be exempt from the contrast success criterion while still being hard to perceive. Brand teams can choose stronger contrast even where WCAG does not require it.

## Non-text contrast

WCAG 2.2 Success Criterion 1.4.11, Non-text Contrast, is Level AA. Visual information required to identify user-interface components, their states, and meaningful graphical objects needs at least 3:1 against adjacent colors.

In email, likely examples include:

- an outline required to identify a button;
- a checkbox or radio boundary inside an interactive-email experience;
- a selected-state indicator;
- a meaningful status icon without redundant text;
- a chart line or segment needed to understand data;
- an arrow whose shape communicates an action;
- and a focus or state indicator when an email experience actually supports interaction.

The exact relationship matters.

A button does not automatically require its entire fill to contrast 3:1 with the canvas when text, placement, shape, or context already identifies the action. W3C's Understanding document explains that only visual information required to identify the component and state is in scope. A visible boundary that is required to perceive the button does need to meet the adjacent-color requirement.

The tool allows a pair to be classified as a UI component or meaningful graphic and applies 3:1. The operator note should describe the exact cue being measured:

- blue button fill against white canvas;
- gray input border against white field;
- green success check against pale-green badge;
- chart line against plot background;
- or selected radio dot against control interior.

Do not label a general brand swatch as “UI” without identifying its visual function and adjacent color.

Thin lines and anti-aliased shapes can appear weaker than the source-color calculation. W3C recommends avoiding particularly thin shapes or using contrast beyond the nominal threshold. Rendered review remains necessary.

## Inline links and use of color

An inline link has at least two color relationships.

First, link text must meet the appropriate text threshold against its background:

- 4.5:1 for normal text;
- or 3:1 for large text.

Second, a reader must be able to distinguish the actionable link from surrounding non-link text without relying on color perception alone.

WCAG Success Criterion 1.4.1 says color must not be the only visual means of indicating an action or distinguishing a visual element.

A persistent underline is the most robust email choice. It survives the absence of hover, supports touch environments, and avoids requiring the reader to infer action from hue.

W3C technique G183 describes using at least 3:1 contrast between link color and surrounding text together with an additional cue on hover or focus. That technique is sufficient, not the only possible technique. Email clients have inconsistent support for authored hover and focus behavior, and touch interfaces have no durable hover. The tool therefore reports:

- pass when the operator marks the link visibly underlined;
- conditional when a non-underlined link differs from surrounding text by at least 3:1;
- fail when a non-underlined link differs by less than 3:1 or the surrounding color is invalid.

“Conditional” is a review state, not a conformance guarantee. The exported finding states that an additional cue is still required and recommends persistent underlining for email.

The link-to-surrounding-text ratio does not replace the link-to-background text threshold. Both relationships matter.

## Alpha and compositing

Contrast is computed from the colors a reader perceives after transparency is composited.

For a translucent foreground over an opaque background, each effective channel is:

foreground channel × foreground alpha + background channel × (1 − foreground alpha)

The tool performs standard source-over alpha compositing before calculating relative luminance.

For example, rgba(0, 0, 0, 0.5) over white is not evaluated as black on white. It becomes an effective middle gray, producing a much lower ratio.

The tool accepts alpha in:

- four- and eight-digit hex;
- rgba() with a decimal alpha;
- rgba() with a percentage alpha;
- and modern rgb() syntax with a slash alpha.

The color picker supplies opaque hex because the native picker does not reliably preserve alpha across browsers. The adjacent text input retains authored alpha.

### Translucent backgrounds

A translucent background needs a canvas behind it. One foreground/background pair is otherwise incomplete.

When the supplied background has alpha below one, the tool composites it over white and adds a finding that the canvas is an assumption. If the real email body, card, image fallback, or client canvas is another color, enter the final effective background or create a scenario representing the complete stack.

The tool does not currently model an arbitrary chain of translucent layers. Keep the audit legible by recording the final effective background and explaining the source layers in the evidence note.

### Why source CSS still matters

W3C says source colors should be used instead of trying to sample anti-aliased glyph edges. Font smoothing creates intermediate pixels that should not be treated as the authored text color.

Source values remain insufficient for:

- gradients;
- photographs;
- textures;
- blend modes;
- embedded raster text;
- SVG filters;
- client-inverted colors;
- and areas where the background changes beneath one text run.

Those cases require rendered inspection of the least-contrasting meaningful area.

## Text over photographs and gradients

Two swatches cannot establish the contrast of text over a variable background.

For text over an image:

1. render the image at the actual email dimensions and crop behavior;
2. identify every area behind the full glyph shapes;
3. test the least-contrasting area, not an average;
4. repeat for responsive crops, image blocking, and high-density variants;
5. inspect fallback background colors;
6. repeat for dark-mode transformations where applicable.

Practical ways to create a stable relationship include:

- placing text in a solid panel;
- adding a sufficiently opaque scrim whose final composite is tested;
- moving text away from variable imagery;
- using a solid fallback that remains usable when images are blocked;
- and including critical text as live HTML rather than embedding it in the image.

A drop shadow or text outline can sometimes create a local contrasting boundary, but it must be thick and consistent enough to function around the glyphs. A faint decorative shadow is not a substitute for an owned contrast relationship.

For a gradient, sample the point that creates the lowest ratio behind each foreground element. If the gradient can animate or change, evaluate the full state range.

## Email dark mode

“Dark mode” is not one deterministic rendering algorithm.

Mail clients can:

- leave authored colors unchanged;
- invert the entire message;
- selectively invert light backgrounds;
- change text but preserve images;
- preserve explicit dark-mode CSS;
- ignore media queries;
- use client-specific selectors or attributes;
- add outlines;
- or behave differently by operating system, account type, and app version.

The tool's light and dark labels organize intentional scenarios. They do not simulate a particular mailbox client.

Use them to record:

- authored light text and background;
- authored dark text and background;
- button label and fill in each theme;
- logo variants and protective plates;
- quiet copy in each theme;
- link and surrounding copy in each theme;
- and fallback colors when client-specific dark styles do not apply.

Then render representative messages in the actual clients important to the audience. Capture screenshots with client, platform, version, account/theme state, date, and template revision.

If a client rewrites colors, sample the effective solid areas for diagnostic evidence, but do not assume the same transformation will remain stable indefinitely.

Images with transparent backgrounds can become unreadable when the surrounding canvas changes. Add a protective plate, outline, or dark-mode asset where brand and meaning require it.

## Repair candidates

For a failing applicable scenario, the tool produces one foreground-only candidate.

It searches two straight lines in sRGB channel space:

- from the effective foreground toward black;
- and from the effective foreground toward white.

For each direction capable of meeting the selected threshold, binary search finds the smallest sampled amount that clears the full unrounded ratio. The candidate with the smaller Euclidean RGB-channel movement is displayed.

This has useful properties:

- it is deterministic;
- it preserves the background;
- it is guaranteed to be tested by the same calculator;
- and it gives a designer a concrete starting point.

It is not a claim that the candidate is:

- perceptually nearest;
- optimal in OKLCH or another perceptual space;
- brand compliant;
- visually harmonious;
- robust across dark mode;
- safe for all linked states;
- or the best repair for the system.

Changing the background, size, weight, boundary, underline, layout, or component design may be the better repair.

The candidate is opaque because it represents the effective color required against the selected background. Reintroducing alpha changes the composite and must be retested.

## Default scenarios

The tool opens with a practical mixed ledger:

- primary light-theme body copy;
- intentionally weak muted metadata;
- an underlined inline link;
- primary CTA text;
- CTA boundary against the email canvas;
- a meaningful status icon;
- dark-theme body copy;
- dark-theme CTA text;
- and a brand wordmark recorded as an exception.

The weak sample is deliberate. An all-green default can teach users to trust the decoration rather than understand remediation. Select “Muted metadata” to see the failing ratio, evidence, and foreground repair.

Default values are demonstrations, not design recommendations. Replace them with the exact source values from the email system.

## Recommended audit workflow

### 1. Inventory templates and tokens

Collect active:

- campaign templates;
- transactional templates;
- automation messages;
- localization variants;
- shared modules;
- brand tokens;
- footer and legal modules;
- light and dark assets;
- error, warning, success, and informational states;
- and image fallback styles.

Identify which templates override shared tokens.

### 2. Build the relationship ledger

Add one scenario for each meaningful foreground/background relationship. Name it for where it appears, not only the token:

- Receipt body on content panel;
- Password reset CTA label on blue fill;
- Newsletter link in body paragraph;
- Footer legal copy on dark plate;
- Success check in status badge;
- Chart line on plot canvas.

Two components that use the same colors can share a pair only when role, adjacency, typography, and state are genuinely equivalent.

### 3. Classify the role

Choose:

- text for readable characters;
- inline link for text that must be identified as actionable among surrounding copy;
- UI component for visual information required to identify a control or state;
- meaningful graphic for non-text visual information needed to understand content;
- decorative or logo only when the exception truly applies.

Record the reason in the evidence note.

### 4. Enter source values

Use exact CSS or template values. For transparency, enter rgba or alpha hex and confirm the solid background beneath it.

Do not sample the anti-aliased edge of rendered text as the foreground source. Use the authored text color.

### 5. Enter typography

For text and link scenarios, enter the actual CSS pixel size and numeric weight. Confirm that email clients receive and honor those properties. When fallback fonts or styles can reduce visual weight, keep margin above the threshold.

### 6. Resolve failures

Use the repair candidate as one option. Also consider:

- stronger shared tokens;
- larger or heavier text;
- a solid panel behind text;
- underlining links;
- a thicker meaningful boundary;
- redundant text for a status icon;
- removing unnecessary quiet styling;
- or redesigning a chart to use labels and patterns.

Retest every state that consumes the changed token.

### 7. Inspect the whole palette

The summary counts applicable minimum passes, failures, enhanced text passes, alpha scenarios, invalid inputs, exceptions, and link reviews.

Do not divide passes by all scenarios without interpreting exceptions and invalid entries. A deleted failing scenario is not remediation.

### 8. Render representative email clients

Test:

- desktop and mobile widths;
- images on and off;
- light and dark system settings;
- forced colors where supported;
- zoom and text scaling;
- common font substitutions;
- interactive states that exist;
- and representative clients based on audience evidence.

Inspect thin icons, borders, and small text even when source math passes at the exact threshold.

### 9. Export the evidence

Attach the CSV or JSON to design QA, accessibility review, and template release records. Keep rendered screenshots and raw email artifacts alongside the source-color evidence.

### 10. Re-audit on change

Re-run the ledger when:

- brand tokens change;
- a shared module is redesigned;
- dark-mode handling changes;
- an email client begins rewriting colors differently;
- new states or charts are added;
- a font size or weight changes;
- or a provider transforms CSS during compilation.

## Export formats

### CSV ledger

The CSV contains:

- label, theme, and role;
- source foreground and background;
- effective composite colors;
- text size, weight, and large-text classification;
- full and displayed ratios;
- minimum and enhanced thresholds;
- pass states;
- underline and surrounding-text link evidence;
- status;
- repair candidate;
- and operator note.

This format is suitable for spreadsheets, design-token inventories, or accessibility issue tracking.

### JSON evidence

The JSON includes:

- generation timestamp;
- method and model boundary;
- summary counts;
- every scenario and finding;
- source and effective colors;
- typography;
- unrounded ratio and thresholds;
- link distinction;
- repair candidates;
- and primary W3C sources.

It does not include screenshots or rendered-client results because the tool does not generate those tests.

### CSS tokens

The CSS export creates foreground and background custom properties from scenario labels. It is a handoff convenience, not production-ready token architecture. Duplicate or ambiguous labels can produce overlapping semantic concepts even when the generated variable names differ.

Review names, cascade, client support, fallbacks, and inlining before using CSS in email.

### Plain-text brief

The brief summarizes counts and one line per scenario, followed by the model boundary. It is suitable for a ticket comment but less complete than JSON.

## What the tool cannot prove

The tool cannot prove:

- that every email relationship was inventoried;
- that entered values match production output;
- that a declared exception is valid;
- that a large-text style renders at the supplied size and weight;
- that anti-aliasing, thin strokes, or font substitution remain readable;
- that text over an image or gradient passes everywhere;
- that a mailbox client preserves source colors;
- that dark-mode transformations are safe;
- that a link has a reliable non-color cue in every client;
- that color is not the only means of conveying status elsewhere;
- that focus and interaction states are accessible;
- that the HTML has semantic headings, language, tables, or link names;
- that images have appropriate alternative text;
- that text resizes and reflows;
- that motion is safe;
- or that the email conforms to WCAG as a whole.

Run the [email accessibility checker](https://emailbump.com/tools/email-accessibility-checker.md) for structural source evidence and complete manual rendering tests.

## Frequently asked questions

### Why does 2.999:1 fail if the interface displays 3.00?

WCAG says threshold values must not be rounded. The displayed value is shortened for readability; the internal comparison and export retain the complete calculated result.

### What is the safest body-text target?

WCAG AA requires 4.5:1 for normal text. Treat that as the floor, not an aspirational target. Extra margin protects against rendering variability, quiet font weights, and design changes. The appropriate target depends on the system, but 7:1 also satisfies the enhanced text contrast criterion.

### Does font weight change the ratio?

No. The color ratio is unchanged. Weight can affect whether text qualifies as large-scale when it is at least 14 point and bold, and it strongly affects practical readability.

### Can I make failing text bold instead of changing color?

Only if the resulting size and weight genuinely meet the large-scale definition and render that way. Turning 16px copy bold does not make it large text. A stronger color is often the more durable repair.

### Do disabled controls need contrast?

Inactive UI components are exempt from the minimum text criterion and inactive components are excepted in non-text contrast. Ensure the control is truly inactive, the state is programmatically conveyed where applicable, and the visual design does not create avoidable confusion.

### Do logos need 4.5:1?

Text that is part of a logo or brand name is exempt under WCAG 1.4.3. The exemption does not make low-contrast branding easy to perceive.

### Does an underlined link still need text contrast?

Yes. Underlining addresses distinction from surrounding text. The link characters still need the applicable contrast against the background.

### Does a button fill need 3:1 against the page?

Only when that fill or boundary is visual information required to identify the component or state. Classify the actual cue. Button label text still needs its own text contrast against the fill.

### Does a status icon need 3:1 if visible text says the same thing?

If the icon is not required to understand the information because equivalent visible text communicates it, the icon can be decorative. Verify that the text is truly equivalent and that color is not the only status cue.

### Can the tool simulate color-vision deficiencies?

No. WCAG luminance contrast already addresses an important dimension of low vision and color perception, but simulation is a separate diagnostic method and cannot prove what every person perceives. Use redundant labels, shapes, patterns, and text rather than depending on simulated hue differences.

### Why not use APCA?

The tool is explicitly a WCAG 2.2 evidence calculator and uses the normative WCAG 2 contrast model. It does not mix experimental or alternative contrast methods into the pass/fail result. Teams may perform additional research-oriented evaluations separately while preserving the applicable conformance evidence.

### Does Email Bump upload my brand palette?

No. The interactive state and exports are produced in the browser.

## Primary W3C references

- [Web Content Accessibility Guidelines 2.2](https://www.w3.org/TR/WCAG22/)
- [Understanding SC 1.4.3: Contrast Minimum](https://www.w3.org/WAI/WCAG22/Understanding/contrast-minimum)
- [Understanding SC 1.4.6: Contrast Enhanced](https://www.w3.org/WAI/WCAG22/Understanding/contrast-enhanced)
- [Understanding SC 1.4.11: Non-text Contrast](https://www.w3.org/WAI/WCAG22/understanding/non-text-contrast.html)
- [Understanding SC 1.4.1: Use of Color](https://www.w3.org/WAI/WCAG22/Understanding/use-of-color)
- [Technique G183: Link contrast and additional cues](https://www.w3.org/WAI/WCAG22/Techniques/general/G183)

## Related Email Bump tools and guidance

- [Email accessibility checker](https://emailbump.com/tools/email-accessibility-checker.md)
- [Email signature builder](https://emailbump.com/tools/email-signature-builder.md)
- [Email preheader generator](https://emailbump.com/tools/email-preheader-generator.md)
- [Email word and structure analyzer](https://emailbump.com/tools/email-word-counter.md)
- [Spam-language and content-risk reviewer](https://emailbump.com/tools/spam-trigger-word-checker.md)
- [Email design guide](https://emailbump.com/docs/editor.md)
- [Transactional email guide](https://emailbump.com/docs/transactional-api.md)
- [Email accessibility glossary and guidance](https://emailbump.com/glossary/email-deliverability.md)