Skip to main content
Images & Media

Design & Icons

Generate favicons, app icons and other web design assets right in your browser — every size is drawn locally and nothing is uploaded.

3 tools

Colour tooling splits into two jobs that are easy to mix up: choosing colours that look right, and choosing colours that work. Looking right is a matter of taste and of the space you mix in. Working is measurable — a contrast ratio against a background, a distinguishable hue distance, a consistent lightness ramp — and it can be checked against a published standard rather than argued about.

Sponsored

This space is reserved for a sponsor.

About Design & Icons

The space you generate in changes the result more than most people expect. Mixing in HSL holds the hue constant but produces lightness steps that look uneven, because HSL lightness is not perceptual: two colours with the same L can differ noticeably in apparent brightness. Perceptually uniform spaces such as OKLCH fix this by making numerically equal steps look visually equal, which is why ramps generated in those spaces hold together while HSL ramps tend to look muddy through the middle.

Everything is computed locally and nothing is stored: no account, no palettes on a server, no colour history. The values you copy out are the entire output.

Frequently asked questions

Should I use HEX, rgb() or hsl()?

They describe the same sRGB colours and are interchangeable; the choice is about what you need to do with the value. HEX is compact and universally supported, which makes it the right form for a token that will be pasted between tools. rgb() is convenient when computing channel arithmetic or an alpha value. hsl() — and, better, oklch() — is what you want when you intend to modify a colour, because shifting lightness or saturation in a perceptual space holds the hue steady in a way that editing a hex triplet cannot.

How do I know whether two colours pass accessibility contrast?

Compute the contrast ratio, (lighter luminance + 0.05) / (darker luminance + 0.05), using relative luminance rather than brightness as perceived by the eye, and compare it against the WCAG threshold for the text size: 4.5:1 for normal text, 3:1 for large text (about 18.66 px bold or 24 px regular) and for user-interface boundaries and graphical objects. The ratio must be evaluated for the pair actually used together, including whatever sits behind a semi-transparent overlay. Colour should never be the only signal carrying meaning; pair it with text or an icon.

Why does my gradient look grey or banded in the middle?

Two separate problems. Greying happens when interpolation between two saturated hues is done in a non-perceptual space, so the midpoint is a mix that is lighter and less saturated than either end — blue to yellow passes through grey. Banding happens when a smooth gradient is rendered in 8-bit colour over a large area, so neighbouring steps differ by a visible quantisation step. Interpolating in a perceptual space such as OKLCH removes the first; dithering or a subtle noise layer removes the second.

Why does a generated palette look uneven?

Because the ramp was generated in HSL or HSV, where a fixed numeric step in lightness does not correspond to a fixed step in perceived brightness. Yellow and blue at the same HSL lightness differ dramatically in luminance, so a ramp that looks perfectly smooth in the numbers can appear to jump. Generating in a perceptually uniform space, or verifying the ramp by converting each step to relative luminance, is the fix.

Do these tools store my colours?

No. Generation, conversion and contrast checking all run inside the page, and there is no account or server-side history. Closing the tab discards the palette unless the values have been copied out, so copy the format you intend to reuse — a plain list of HEX values is the safest thing to paste into a design file, and it is also the format that will survive a round trip through any other tool.

Related categories

Sponsored

This space is reserved for a sponsor.