How to Choose a Website Color Palette

Quick answer: assign colors by job, not by mood. Start with a primary brand accent, a neutral scale for backgrounds and text, and semantic colors for success, warning and error. Test every text/background and control/background combination before publishing.

A screenshot of attractive swatches is not yet a website palette. Interfaces need repeatable roles, readable states and predictable behavior across pages.

Start with the content and brand constraints

Collect the existing logo, photography style, product packaging and brand requirements. Then describe the interface in plain language: calm editorial publication, high-energy event, clinical service, premium store or practical developer tool.

Do not extract ten colors from the logo and give each equal prominence. Most websites benefit from one dominant accent and quiet neutrals that let content lead.

Define functional color roles

Create tokens for roles such as:

• page background;
• raised surface;
• primary text;
• secondary text;
• borders and dividers;
• primary action;
• links;
• focus indicator;
• success, warning and error;
• disabled controls.

One color can serve several roles only when contrast and meaning remain clear. Name tokens by purpose (text-primary) rather than appearance (dark-purple) so a future redesign does not require renaming the system.

Build a neutral scale first

Choose backgrounds and text before accents. Test body copy, headings, muted text, borders and disabled states on every surface.

Avoid low-contrast gray text to create visual hierarchy. Hierarchy can also come from size, weight, spacing and placement. Secondary content still needs to be readable.

Pure black on pure white is not mandatory; slightly softened neutrals can reduce glare. What matters is measured contrast and consistency, not a universal hex code.

Choose a primary accent with usable variants

The logo’s main color may work for large decoration but fail for small text or a button label. Create darker and lighter variants for:

• default action;
• hover;
• active/pressed;
• subtle background;
• border;
• text link.

Do not lighten a button on hover until its label loses contrast. Test interactive states separately.

Meet WCAG contrast requirements

WCAG 2.2 Level AA requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text, subject to the standard’s definitions and exceptions. The official WCAG contrast explanation provides the rationale and calculation details.

Also test:

• icons and control boundaries;
• focus indicators;
• placeholder text;
• selected and unselected states;
• text over images or gradients;
• disabled controls where readability still matters operationally.

Automated tools catch numerical failures, but manual review is still needed for background images, states and meaning.

Do not communicate by color alone

An error field needs text and an icon or other programmatic indication—not only a red border. A chart should use labels, patterns or shapes in addition to hue. Links inside body copy should remain identifiable without relying solely on blue color.

This helps users with color-vision differences and makes the interface clearer for everyone.

Add semantic colors carefully

Define success, warning, error and informational colors as systems with text, background and border variants. Do not reuse the primary brand color for every state.

Test semantic messages inside banners, form fields, badges and dark surfaces. The same green that works as a thick icon may fail as small text on a pale green background.

Test the palette on real components

Apply colors to a small interface inventory:

• page and article body;
• header and navigation;
• primary and secondary buttons;
• form labels, fields and validation;
• cards and dividers;
• links and visited links;
• alerts;
• tables;
• keyboard focus.

Use real long titles, error messages and disabled states. A palette that works only on a brand board is unfinished.

Consider dark mode as a separate system

Do not invert every hex value mechanically. Dark surfaces need controlled elevation, reduced glare and retested semantic colors. Shadows may become ineffective, and highly saturated accents can vibrate against dark backgrounds.

Map the same functional tokens to dark-mode values and test contrast again. Respect the user’s color-scheme preference only when every component is ready.

Implement palette tokens in CSS

Store the roles as custom properties:

:root {
    --color-bg: #fcfbf9;
    --color-surface: #ffffff;
    --color-text: #191634;
    --color-text-soft: #4a4668;
    --color-accent: #4b20ff;
    --color-rule: #ded9ce;
}

Component styles should consume these tokens rather than repeat raw colors. This makes contrast corrections and future rebranding controlled changes.

Final palette checklist

1. Every color has a defined role.
2. Text and controls pass contrast in every state.
3. Meaning does not rely on color alone.
4. Focus is clearly visible.
5. Links remain distinguishable in prose.
6. Real components work on mobile and desktop.
7. Tokens are documented and used consistently.

After colors, define typography with How to Choose Fonts for a Website rather than selecting fonts independently from layout and readability.