Color Palette Generator & Picker

Color palette generation, CSS color models, and WCAG contrast — the 2026 guide

Color is the loudest signal in a user interface. Pick well and your product feels confident, accessible, and on-brand; pick badly and your buttons disappear, your charts mislead, and your sign-up form fails screen-reader audits. This guide walks through how the five CSS color models actually work, the math behind color-harmony rules, the WCAG 2.1 contrast formula in plain English, and how to pick palettes that work in light mode, dark mode, and on the wide-gamut displays that have shipped in every iPhone and MacBook since 2017. Need the raw conversion? Use the hex to RGB converter alongside this picker.

Hex, RGB, HSL, OKLCH — what each model is for

CSS lets you write the same color in five different notations. They are not interchangeable in workflow even though they describe the same on-screen pixels. Use the right one for the job:

Here is the practical workflow most teams converge on: design tokens stored as hex for portability, runtime calculations done in HSL or OKLCH, and any color carrying transparency written in rgb(). The picker above outputs all three so you can paste whichever your codebase expects.

Color harmony rules — the math behind "this just looks right"

The reason complementary and triadic palettes feel balanced is not magic, it is geometry on the HSL hue wheel. Hue is a 360° circle: red sits at 0°, yellow at 60°, green at 120°, cyan at 180°, blue at 240°, magenta at 300°. Every harmony rule is a fixed rotation around that circle:

The picker generates these by taking your base hue and adding the offsets, then producing extra tints by holding hue/saturation constant and varying lightness. The result is a palette that is mathematically harmonious — you still have to decide which color dominates and which accents.

WCAG 2.1 contrast — the formula in plain English

Web Content Accessibility Guidelines (WCAG) 2.1 defines contrast as a ratio between the relative luminance of two colors. The math is fixed by W3C and looks like this:

1. Convert each RGB channel from 0–255 to a 0–1 float, then linearize: if the float is ≤ 0.03928, divide by 12.92; otherwise raise ((v + 0.055) / 1.055) to the 2.4 power.
2. Combine the three linearized channels with the luminance weights: L = 0.2126·R + 0.7152·G + 0.0722·B.
3. Add 0.05 to each color's luminance, then divide the larger by the smaller. That is your contrast ratio, between 1:1 and 21:1.

The thresholds you need to hit:

The contrast checker above runs this exact formula. AA is the legal floor in the EU (European Accessibility Act, June 2025), the US (ADA Title III, settled case law), Canada (AODA), and Australia (DDA). AAA is the goal for text-heavy products like documentation and news. For dedicated workflow, the standalone WCAG contrast checker tests pairs in bulk.

Note on APCA: WCAG 3.0 introduces APCA (Accessible Perceptual Contrast Algorithm), which corrects the 2.1 formula's known weaknesses with bright yellows and dark navy. APCA is in candidate-recommendation status as of 2026; sites that ship to government regulators should still validate against 2.1 today and plan for 3.0 next.

Design-system palettes — going from one color to a 50–900 ramp

Tailwind, Material, Radix, and most modern design systems expose 9–11 shades per color (50, 100, 200 … 900, sometimes 950). The shades are not random — they follow a luminance ramp tuned so that 500 hits the brand color, 900 hits AA on white, and 50 hits AA on near-black. The reliable way to build one yourself:

1. Pick your 500 (the brand color). Convert to OKLCH.
2. Hold chroma roughly constant. Reduce lightness in even steps for 600/700/800/900; increase it for 400/300/200/100/50.
3. Slightly drop chroma at the extremes (50, 900, 950) so they do not look fluorescent or muddy.
4. Verify each shade against your background pair: 700+ should clear AA on white; 100– should clear AA on a near-black surface.

This is why OKLCH wins for design systems: equal lightness steps in OKLCH produce equal perceptual steps. Equal lightness steps in HSL do not — yellow at L=50 looks brighter than blue at L=50.

Color generator tool, CSS color generator, color palette generator CSS — same intent

Top-of-page-1 GSC queries land here under several phrasings: "color generator tool", "css color generator", "color palette generator css", "web color palette generator", "css generator gradient". They all describe pasting or picking a base color and getting a coordinated set of CSS-ready values back. The picker above does this directly — pick a hex (or paste rgb/hsl/oklch), get five harmony palettes (complementary, analogous, triadic, split, monochromatic), each with hex/RGB/HSL/OKLCH output and WCAG contrast scores against white and black backgrounds. For gradient generation specifically, the dedicated CSS gradient generator produces multi-stop linear and radial gradients with copy-ready CSS.

CSS color generator — output formats and copy-paste targets

The picker outputs every color in five CSS-valid formats: hex (#00d084), rgb() (rgb(0 208 132) — modern space-separated syntax), rgba() with alpha, hsl() (hsl(158 100% 41%)), and oklch() (oklch(72% 0.19 158)). Click any value to copy. Paste destinations: --brand-500: #00d084; in your CSS variables, theme.extend.colors.brand['500'] = '#00d084' in tailwind.config.js, color tokens in your design-system JSON. For palette ramps that pass WCAG AA on both light and dark surfaces, build in OKLCH (perceptually uniform) — see the OKLCH H3 below for the workflow.

Web color palette generator — picking accessible palettes

"Web color palette generator" implies palettes that work in browsers — meaning every color must clear WCAG AA contrast against the surfaces it appears on, render correctly on sRGB monitors (not just wide-gamut Mac displays), and degrade gracefully when CSS Custom Properties aren't available. The contrast checker below the picker runs WCAG 2.1's exact luminance formula on every generated swatch against both white and near-black backgrounds, so you see at a glance which shades clear AA (4.5:1 for body text) and which clear AAA (7:1). Pair with the dedicated WCAG contrast checker for explicit pair-by-pair testing of arbitrary foreground/background combinations.

Tailwind CSS color palette and Figma variable export

Most modern teams target two destinations from one palette: Tailwind theme.extend.colors in code, and Figma color variables in design. The pattern that survives both: name semantically (brand-500, danger-700, surface-50) instead of by hue (green-500, red-700). When marketing pivots from green to teal, you change one HSL/OKLCH value and every consumer updates — no rename across components or Figma libraries. Export the swatches above as a JSON token block, paste into tailwind.config.js under theme.extend.colors, and import the same JSON into Figma via the Figma Variables import dialog or any Token Studio plugin. After exporting, run the result through the CSS minifier to see the gzipped weight of your color layer.

OKLCH vs HSL — perceptual uniformity in palette ramps

HSL is mathematically uniform but perceptually broken: a 10% lightness increase looks far brighter on yellow than on blue because HSL ignores the human eye's luminance response. OKLCH (perceptual lightness, chroma, hue, defined in CSS Color Module Level 4) corrects this — equal lightness steps in OKLCH produce equal perceived steps. Practical rule for design-system ramps in 2026: define the 500 shade in your brand color, convert to OKLCH, then walk lightness in even 7–9% steps for 600 → 900 and the inverse for 400 → 50, holding chroma roughly constant. Ramps built this way pass WCAG AA at the 700+ shade on white surfaces and at the 100– shade on dark surfaces without manual tweaking.

Reading colors from images — the EyeDropper API

Modern Chromium browsers (Chrome 95+, Edge 95+, Opera 81+) ship the EyeDropper API, which lets web apps sample any pixel on the screen, including outside the browser window. Firefox does not implement it as of 2026. The picker uses native <input type="color"> for cross-browser fallback. If you need cross-browser dropper behavior, render a canvas with the image and pick the pixel under the click using getImageData.

Color blindness and accessible status indicators

About 8% of men and 0.5% of women have some form of color vision deficiency. The big three patterns:

• Deuteranopia (most common, ~6% of men): green appears tan/grey. Red and green look similar.
• Protanopia (~1%): red appears dim. Reds and dark greens collide.
• Tritanopia (rare, <0.01%): blue–yellow confusion.

Practical rules: never encode meaning in color alone — pair it with an icon, a label, or shape. Status traffic-lights (red/yellow/green) should add a check/exclamation/cross icon. Charts should use both color and texture or position. Test palettes through Sim Daltonism, Stark, or Chrome DevTools' "rendering → emulate vision deficiency" panel before shipping.

Common color-picker mistakes I see in code review

• Hard-coding hex values inside components. Buttons, alerts, and charts should reference design tokens, not raw #00d084. When you rebrand, you change one variable, not 80 files.
• Using opacity instead of an rgb() alpha channel. opacity: .5 fades the entire element, including text. background: rgb(0 0 0 / .5) fades only the background — the text stays readable.
• Treating dark mode as "invert everything." Inverting a light palette produces neon-on-black UIs that fail AA. Build a parallel ramp with its own contrast verification.
• Picking colors on a wide-gamut Mac display. P3 reds and greens look fine on your iMac and dull on every Windows monitor. Test in sRGB-only mode — DevTools → Rendering → Emulate CSS media feature: color-gamut: srgb.
• Forgetting hover/focus states need their own contrast. A button that hits 4.5:1 normally can drop to 3:1 on hover when it lightens. Run the contrast checker on every interactive state.
• Using pure black (#000) for body text. Pure black on pure white feels harsh and creates eye strain. #1a1a1a on #fafafa is gentler and still clears AAA.