Extract a palette whose every colour is one the image actually contains, with the share of the picture each one covers. Median cut, k-means in CIE Lab or plain frequency, each named.
Initializing in your browser…
A tone curve drawn with its level count and clipping reported, per-range gains in stops of light whose three weights sum to exactly one, and a white balance that is a Bradford adaptation on a published locus. The neutral setting is proved to change nothing.
Turn an image into a data URL whose payload is decoded again and compared byte for byte with the file, with the media type taken from the file's own signature rather than its extension and the size cost of embedding stated in full.
Compare two images with a perceptual engine (pixelmatch) that ignores anti-aliasing, or an exact byte engine. Groups changes into regions with bounding boxes, reports SSIM, and handles size mismatches with an explicit policy.
A test image drawn with exactly five colours in exactly known proportions, so the right answer exists before the tool runs.
Input
bands.png 400×400 · 5 colours · median cut
Palette
#DC143C crimson 50.00% (80,000 px) #1E90FF dodger blue 25.00% (40,000 px) #FFD700 gold 12.00% (19,200 px) #228B22 forest green 8.00% (12,800 px) #4B0082 indigo 5.00% (8,000 px)
Every hex is a colour the image really contains and every share is the exact pixel count, checked against Pillow. Two things break that in a naive extractor: resizing before counting, which blends neighbours into colours that are in none of the picture, and printing the quantisation bin rather than a real member of it, which turns #1E90FF into #1E8CFA. Which five are the "main" colours is a choice, not a measurement, and the page says so.
Pull a colour palette out of an image, where every colour reported is one the image actually contains and comes with the share of the picture it covers. Three named grouping methods, and an honest statement of which half of this is a measurement and which half is a choice.
Get colours that are really in the picture, with how much of it each one covers.
Frequency mode returns the colours that appear most, exactly as counted.
Median cut is the classic quantisation algorithm and gives a spread rather than several shades of the same thing.
The closest pair is reported in dE2000, so two near-identical entries are visible as such.
Two different claims live in a palette extractor and only one of them can be settled.
DECIDABLE: is this colour in the picture, and what share of the pixels does it cover? That is a count. Every colour this tool reports is one the image really contains, with the count that makes it so, and the whole thing is checked against Pillow's own `getcolors()` reading of the same file: on a test image drawn with exactly five colours at exactly 50, 25, 12, 8 and 5 percent, all five come back with those shares to within a hundredth of a percent.
NOT DECIDABLE: which colours are the picture's "main" ones. There is no standard for that, no reference implementation to agree with and no experiment that settles it. Three grouping methods are offered, each named with where it comes from: plain frequency, median cut (Heckbert, SIGGRAPH 1982) and k-means in CIE Lab (Lloyd, with the k-means++ seeding of Arthur and Vassilvitskii, SODA 2007). They give different answers on the same picture, all three are defensible, and the page says so rather than presenting one of them as a measurement.
TWO MISTAKES MAKE A PALETTE REPORT COLOURS THAT ARE NOT THERE, and both are avoided here. The first is resizing before counting: drawing the picture smaller blends neighbouring pixels, and the blends are new colours. An image of alternating rows of pure red and pure blue, reduced, is largely purple, and purple is in none of it. Where speed matters this SAMPLES instead, reading every n-th pixel, which can only ever return a colour that is present. The second is quantising and then printing the bin: rounding (220, 20, 60) into a bin at (220, 20, 60) is fine and rounding (30, 144, 255) into a bin at (30, 140, 250) is not, because the second is a colour the image does not contain. Grouping here decides which pixels belong together; the colour reported for a group is always a real member of it.
k-means computes a cluster centre, and a centre is generally not a colour in the image. When it is more than half a dE2000 away from the colour reported, both are shown and the difference is stated, rather than the centre being handed over as though it had been read off the picture. The same seed always gives the same palette, so a result can be reproduced and therefore checked.
Each colour comes with its hex, RGB and HSL from one conversion module rather than three hand-rolled ones, its nearest CSS colour name out of the 148, its contrast ratio against white and against black, and the share of the picture it covers. The page also reports how far apart the two closest entries are in dE2000, so "these five colours" can be told from "these three colours and two versions of one of them". Exports carry the shares: CSS custom properties, SCSS, a Tailwind config, JSON, RFC 4180 CSV and a GIMP palette. Everything runs in the browser.
Median cut for a spread across the picture, which is what most people want. Frequency when you want literally the most common colours, which on a photograph of a sky means several near-identical blues, because that is the truth about the picture. k-means in CIE Lab when you want groups formed by how different colours look rather than by how far apart their numbers are.
Because "the main colours of a picture" is not a defined quantity. Each method optimises something different and all of them are reasonable. What does not change between them is that every colour reported is in the image, and that its share is correct.
Because the image has fewer. Asking for sixteen from a four-colour image gives four; inventing twelve more would mean reporting colours that are not there.
The centre of the cluster, which is a point in colour space and usually not a colour in the picture. The colour shown is the nearest real one, and the distance between them is printed so you can see how much of an approximation the group is.
No. For a very large picture it samples, reading every n-th pixel, which can only return colours that are present. It never scales, because scaling blends neighbouring pixels into colours the image does not contain.
Images are decoded, edited, and exported entirely inside this browser tab. No originals, exports, or metadata are uploaded.