Color Picker

Colour Format Reference

How a colour picker works

A graphical colour picker is really three controls working together. The large square you drag inside is a two-dimensional saturation/value field: moving left to right changes how vivid the colour is (saturation), while moving top to bottom changes how light or dark it is (value, or brightness). The narrow strip beside it — the hue slider — chooses the base colour itself, sweeping through red, orange, yellow, green, cyan, blue and magenta before returning to red at 360°. A third optional slider sets alpha (opacity), from fully transparent to fully opaque, usually drawn over a chequerboard so you can judge how see-through the colour really is.

This square-plus-slider layout is built on the HSV model (Hue, Saturation, Value) and its close relative HSL (Hue, Saturation, Lightness) rather than on raw RGB, and the reason is human. HSV matches the way people think about colour: you first decide which colour you want — the hue — then how vivid and how bright it should be. Nudging three independent 0–255 red, green and blue numbers to land on "a slightly less intense sky blue" is far harder than dragging within a single square. Because the hue is held constant by the slider while you explore the square, the picker can render the entire saturation/value plane for that one hue as a smooth gradient — exactly the field you see on this page.

This design was popularised by Adobe Photoshop's colour picker and has since become the de-facto standard in tools such as Figma, Sketch, GIMP and almost every web-based picker. The conventions are so entrenched that most people can operate an unfamiliar picker instantly: vivid colours sit in the top-right of the square, white in the top-left, and black runs along the bottom edge regardless of hue.

The eyedropper and native browser pickers

Browsers ship their own colour-picking machinery, and it pays to know what each piece does. The HTML <input type="color"> element renders a native swatch that opens the operating system's colour dialog when clicked. Classically its value is always a seven-character lowercase hex string in #rrggbb form — it has historically had no alpha channel and defaults to #000000 if unset, which is why so many simple "colour pickers" output hex only. (Newer browsers are starting to expose an optional alpha attribute and wider colour spaces, but the plain hex value remains the lowest common denominator you can rely on everywhere.)

The eyedropper is a different and newer capability. The EyeDropper API lets a web page sample the colour of any pixel on the screen — not just inside the page, but anywhere the user can see, including other windows. Calling new EyeDropper().open() turns the cursor into a magnifier; the returned promise resolves only after the user deliberately clicks a pixel, handing back an object whose sRGBHex property holds the sampled colour. For privacy it can only be triggered by a genuine user gesture (such as the Eyedropper button on this tool), runs only in a secure HTTPS context, and never reads pixels silently — pressing Escape cancels it. Support is currently limited to Chromium-based browsers (Chrome, Edge and Opera); Firefox and Safari do not implement it yet, so a well-built tool disables the button when the API is absent, as this one does. Nothing you sample is uploaded — the colour is resolved entirely on your device.

How your eyes actually see colour

The reason a screen can fake every colour with just three lights is rooted in the biology of the eye. Human colour vision is trichromatic: the retina contains three types of cone cell, each tuned to a different band of wavelengths. The L (long) cones peak around 560 nm and respond most to reddish light, the M (medium) cones peak near 530 nm for greenish light, and the S (short) cones peak around 420 nm for bluish light. Your brain does not measure wavelength directly; it compares the relative firing rates of these three cone types and infers a colour from the ratio.

That comparison-based system has a profound consequence called metamerism: two completely different mixtures of wavelengths can produce identical cone responses and therefore look like exactly the same colour. A pure spectral yellow and an appropriate blend of red and green light are physically different yet perceptually indistinguishable. Displays exploit this shamelessly — by mixing only red, green and blue sub-pixels they recreate metamers of almost any colour the eye can name, which is precisely why the RGB model underpins every screen and every colour picker.

With 8 bits per channel a display offers 256 levels each of red, green and blue — 256 × 256 × 256 ≈ 16.7 million combinations. The eye can only distinguish on the order of ten million colours, so for ordinary screen work this "truecolour" depth is effectively beyond what most people can perceive, and visible banding is rare. One quirk worth knowing: the eye is markedly more sensitive to green than to red or blue — the L and M cones dominate while the S cones make up only a small fraction of the total — which is why green contributes most to perceived brightness and why mid-greens can look so intense in the picker.

Which colour format should you copy?

A picker is only useful if it hands you the colour in the notation your target actually wants. Hex (#rrggbb, or #rrggbbaa with alpha) is the universal currency of the web — compact, copy-paste-friendly and accepted everywhere — but it is opaque to read: nobody can glance at #5b8cff and know it is a light blue. rgb() / rgba() expose the same numbers in decimal and are handy when blending or scripting. hsl() / hsla() are the friendliest for hand-editing in CSS, because adjusting the lightness value alone lightens or darkens a colour predictably without disturbing its hue.

Beyond these, modern CSS adds several newer functions. hwb() (hue, whiteness, blackness) describes a colour as a base hue tinted with some white and shaded with some black — an intuitive painter's model that still lives in the sRGB space alongside HSL. More significantly, lab() and lch() use the device-independent CIELAB space, and oklab() / oklch() use the Oklab space. The key advantage of Oklab and OkLCh is that they are perceptually uniform: a fixed numerical step produces a roughly equal-looking change anywhere in the colour space. That makes them excellent for generating evenly-spaced palettes, smooth gradients without grey "dead zones", and predictable lightness ramps — which is why oklch() is increasingly recommended for design-system colour scales.

For most everyday web work, copy hex or rgb(); reach for hsl() when you want to tweak by hand, and for oklch() or lab() when you are building a systematic palette and want perceptually even steps. (The first three rows above show the current colour on this page; the lower rows show the function notation, not exact conversions of the same value.)

Designing for colour blindness and contrast

Picking a colour that looks great to you is not the same as picking one that works for everyone. Around 8% of men and 0.5% of women of Northern-European descent have some form of colour-vision deficiency, because the most common types are caused by genes on the X chromosome. The overwhelming majority is red–green deficiency — deuteranomaly, a shifted green response, is the single most common form — which makes reds, greens, browns and oranges easy to confuse. Blue–yellow (tritan) deficiency exists but is rare. The practical lesson is the long-standing accessibility maxim "don't rely on colour alone": never use colour as the only way to convey meaning. Pair a red error state with an icon or label, distinguish chart series with patterns or direct labels, and make links underlined as well as coloured.

Legibility is the other half of the problem, and here there are hard numbers. The Web Content Accessibility Guidelines (WCAG) define a contrast ratio between text and its background, and at the widely-used AA level they require at least 4.5:1 for normal-size text and 3:1 for large text (roughly 18pt, or 14pt bold), as well as for user-interface components and meaningful graphics. So when this picker hands you a hex value for body text, the real question is not "is it pretty?" but "does it clear 4.5:1 against the background?" A good habit is to pick the colour here and then verify the pair in a dedicated contrast checker before committing it.

A colour-picking workflow that scales

Picking one good colour is easy; staying consistent across a whole project is where a picker earns its keep. A repeatable workflow looks like this. First, capture — use the Eyedropper to lift an exact brand colour from a logo, screenshot or reference image rather than eyeballing it, so the value is precise to the pixel. Second, anchor — settle on a small set of core colours (a primary, a secondary, a neutral and a couple of accents) and save each with Add to Palette so you are not re-deriving them from memory. Third, expand — generate the tints and shades you need for hover states, borders and backgrounds from those anchors, keeping the hue constant so the family stays coherent. Fourth, export — push the finished set out as CSS custom properties (--color-1, --color-2, …) or JSON so the same tokens drive every page and component.

Transparency deserves its own mention. Use alpha rather than a hand-mixed solid colour whenever you want an overlay, a subtle tint or a colour that adapts to whatever sits behind it — an rgba(0, 0, 0, 0.5) scrim over an image stays correct no matter what the image is, whereas a baked-in grey does not. Because this tool keeps its history and palette in your browser's local storage, you can close the tab and return to the same working set later, then copy any swatch straight into your stylesheet. The aim is a single source of truth for colour that lives in your design tokens, not scattered hex strings duplicated across files.

Common colour-picking mistakes

A handful of mistakes show up again and again. The first is treating hex as the whole story: a hex code tells you nothing about a colour's lightness or hue at a glance, so editing directly in hex makes it easy to drift. Switch to HSL or HSV when you want to reason about a colour, and keep hex for storage. The second is ignoring alpha — forgetting that #000000 and a 50%-opacity black behave completely differently, or hard-coding a semi-transparent look as an opaque colour that then fails over a different background.

The third, and most consequential, is choosing low-contrast pairs because they look elegant on your bright, well-calibrated monitor. Pale-grey text on white may be invisible on a phone in sunlight and will fail WCAG outright; always check the ratio. The fourth is assuming on-screen colour equals print: monitors emit RGB light while print mixes CMYK inks on paper, and the two gamuts do not match — a vivid screen blue or neon green often cannot be reproduced in ink, so colours destined for print should be proofed in a CMYK workflow rather than trusted from the screen. Finally, not saving your colours wastes time: re-deriving the same brand blue five times a week guarantees five slightly different blues. Capture it once, save it to a palette, export it as tokens, and reuse it everywhere.