Color Picker — pick a colour from an image and derive a palette

Pick a colour from an image

Load an image, move the pointer across it and click the spot whose colour you need. The magnifier enlarges the pixels so you hit the right one even on an edge. The value appears immediately as HEX, RGB and HSL, ready to copy, plus a palette of its main colours. Everything runs in your browser; the image never leaves it.

How do I hit the right pixel?

An image is almost never shown at its real size. A photo 4000 pixels wide fits into a 600 pixel column, so one displayed pixel stands for roughly seven real ones. That is exactly where a colour picker goes wrong: it reads the displayed pixel instead of the image pixel underneath.

This tool converts the pointer position into a fraction of the displayed area first, and from there into an image column and row. The magnifier shows nine by nine real pixels around the crosshair, with the picked one in the centre. At the border the cells stay empty instead of wrapping around to the opposite side.

Three ways lead to an image:

• Choose or drop. The area accepts any format your browser can display: JPG, PNG, WebP, GIF and usually AVIF.
• Paste. A screenshot on the clipboard lands in the tool with Ctrl + V (Mac: Cmd + V), no file needed.
• Keyboard. Focus the image with Tab, move the crosshair with the arrow keys — hold Shift for steps of ten — and pick the colour with Enter.

Can I pick colours outside this page?

In some browsers, yes. The EyeDropper API hands the picker over to the operating system: the pointer becomes a magnifier and reads any pixel on your screen, including one in another window, a video or a PDF. That is the real advantage over a picker limited to a loaded image.

It is not available everywhere. As of 2026:

That is why the button appears only when your browser really offers the feature. When it does not, a plain notice takes its place. A silent fallback that quietly does something else would be worse than the honest answer. Technical reference: MDN, EyeDropper API.

Without the API you still get there: take a screenshot, paste it with Ctrl + V, pick the colour.

How is the palette calculated?

Not by sampling five random pixels. That sounds obvious, yet it is exactly where many palette tools go wrong, for two reasons.

First, noise. In a photo no area is exactly one colour. A red wall consists of hundreds of slightly different reds. Counting exact colour values finds no cluster there and instead names the smaller but technically uniform area next to it first. So every sampled pixel first goes into a coarse grid of 32 steps per channel instead of 256, and neighbouring cells are merged afterwards.

The distance for that merge is not measured in RGB but in OKLab. In RGB two greens the eye can barely tell apart sit far away from each other numerically, while two clearly different blues sit close together. OKLab is built so that equal numeric distances correspond roughly to equal perceived distances (Björn Ottosson, 2020); the same colour space is available in the browser as of CSS Color Level 4.

Second, the background. In almost every product shot, screenshot and logo, white and black cover the largest area. Sorting strictly by area gives you a palette of five greys, and the colour you loaded the image for is not in it. Here near-white and near-black are counted separately from the start and reported separately. The colour list stays a colour list, and you still see how much area background and shadow occupy.

A vivid pale yellow does not slip into the white bucket: near-white only applies when a colour is both very light and very desaturated.

Which colour format do I need?

All three describe the same sRGB colour, so it is not a question of quality but of what you do next. If you also need HSV, OKLCH, CMYK or the matching CSS colour name, the colour converter produces all of them at once, plus tints, shades and harmonies.

Is this colour readable as text?

Right below the picked value you see the WCAG contrast ratio against white and against black. WCAG 2.1 success criterion 1.4.3 asks for at least 4.5:1 for normal text and 3:1 for large text (W3C).

That this check is not a side issue is shown by the WebAIM Million 2024 analysis: 81.0 percent of the one million home pages tested contained text with insufficient contrast, by far the most common automatically detectable failure (webaim.org/projects/million).

If neither white nor black reaches the required value, the colour is not usable as a text colour on its own. The contrast checker then evaluates the specific pair and suggests the nearest lightness that passes, without changing the hue.

Where are the limits?

• JPEG changes pixels. Compression works in blocks; at edges and in flat areas the stored value differs from the original. For an exact brand colour the design file is the source, not a photo of it.
• Colour profiles are converted. If the image carries a profile other than sRGB, the browser converts it before the pixels reach the canvas. You get the value visitors see, which is not necessarily the value stored in the file.
• A screenshot is not a file. It captures what your display shows, including brightness, night mode and the display profile.
• Very large images are scaled down. The browser canvas is limited to about 16.7 megapixels on iOS. Above that the tool scales proportionally and tells you; colours shift marginally as a result.
• Semi-transparent pixels come back with their alpha value and are skipped for the palette. What you actually see on a coloured background is the composited colour, not that value.
• CMYK is not a conversion without a profile. For print the value here is a starting point, not a specification.