Photo2PatternFree color reduction
Reduce colors in an image, and see what it cost
Counts the distinct colors your picture actually holds, then clusters them down to as few as 2 or as many as 64 by median cut in Oklab. What comes back is not only the reduced picture: it is the surviving palette with the number of source shades merged into each entry, the exact pixel count per color, and the single worst shift the reduction imposed, named with both hex values. Free to use, no account required, and the bitmap never leaves the tab you dropped it into.
- 100% free
- No signup
- 2 to 64 colors
- Census before reduction
- Same file, same palette
Press Ctrl+V anywhere on the page to drop in an image you copied out of another browser tab — no need to click the field first.
Fixed stops rather than a slider, because each one is a whole re-clustering of the picture and dragging through 63 of them would compute 63 palettes you never looked at. 8 and 16 are where a photograph starts reading as a poster; 32 and above the change is mostly in the file rather than in the picture.
The offered widths depend on your file: the ceiling is the widest picture whose PNG still comes back on every browser.
How to cut a picture down to a set number of colors
One of these readings happens before you choose anything, and it is the one that tells you what to choose.
Read the census before you choose a number
The moment a file is decoded the page counts the distinct colors in it and prints that figure beside the number you are about to keep. A phone photograph routinely holds tens of thousands; a screenshot of a website holds a few hundred; artwork exported from a vector tool may hold twelve. That first number is what decides whether reducing to 16 is a drastic act or a formality, and no tool that skips it can tell you which one you are performing.
Pick the count, then look at the survivors rather than the picture
The strip under the census is the palette the clustering kept, in the order the colors cover the image, and under each swatch is the number of distinct source shades that merged into it. A swatch carrying four merged shades has barely changed anything; a swatch carrying nine thousand has absorbed a whole region of the photograph. Reading that strip is how you tell an over-reduction from a clean one without hunting for artifacts in the result.
Check the worst shift, then take the file
The note under the strip names the single source color that moved furthest and the color it became, with both hex values and the Oklab distance between them — under 0.02 would read as the same color, and a figure several times that is a visible change somewhere in the frame. If it is acceptable, take the PNG or the palette CSV; if it is not, step the count up rather than blaming the algorithm, because that shift is the arithmetic doing exactly what you asked.
Technical specifications
| How the palette is chosen | Median cut. All the colors present start in one box; the box holding the most pixels is split along its widest axis, at the point where half the pixels lie on each side. Repeated until the requested count is reached |
|---|---|
| Why the split is made in Oklab | So that a box's widest axis means the direction its colors look most different, rather than the direction their numbers happen to spread furthest. Oklab's two color axes span roughly a fifth of what its lightness axis spans, so they are weighted 2.5× before comparison — without that every split is a lightness split and a sunset reduces to a gray ramp |
| Pixels examined | Up to 60,000, taken by walking the file at a constant step. Sampling randomly instead would hand you a different palette every time you reloaded, so the step is fixed; a picture of 60,000 pixels or fewer is read whole, and the page states which of the two happened |
| Counts offered | 2, 4, 8, 12, 16, 24, 32, 48 and 64 colors |
| Refinement pass | One round of Lloyd relaxation, on by default: each kept color moves to the mean of the pixels that chose it, and any cluster left with nothing is dropped rather than listed at zero. One round, not to convergence — later rounds move the palette by less than the width of a rounding step |
| How a kept color is labeled | A 1-based index as its code and its hex as its name, because a palette derived from your own file has no catalog to be looked up in and a hex string in the code column would be a lie about what that column means |
| Output size | 200 to 800 px across, filtered per file to the widths whose PNG stays inside the 4-megapixel canvas budget at that shape |
| What leaves the tab | Nothing. The census, the clustering and the rendering all run on your own processor, and there is no request carrying any part of the picture |
Frequently asked questions
I asked for 32 colors and the palette came back with 29. What happened?
Three clusters ended up with no pixels choosing them and were dropped rather than shipped as key entries covering nothing. It happens after the refinement pass: every kept color moves to the mean of the pixels that actually chose it, some of them move past each other, and a cluster can be left with nothing on its side of the new boundary. Returning it anyway would put a row in your palette that no pixel in the picture uses, which is a bug report waiting to be filed. It also happens the simple way — a file holding only 12 distinct colors cannot be clustered into 16, and the tool returns the 12 rather than inventing four.
Why are the hex values not colors that appear in my photograph?
Because a kept color is the center of a group, not a delegate elected from it. Median cut divides the colors present into as many boxes as you asked for, and each box reduces to the pixel-weighted mean of its contents — a mean computed in linear light, so a box holding black and white returns a genuine mid-gray rather than the too-dark value that averaging sRGB bytes produces. That mean is usually a color the file does contain somewhere, and on a photograph it always sits within the group it represents, but nothing guarantees it. If you specifically need the colors an artist placed rather than averages of them, the palette generator is the page for that, because it counts exact colors instead of clustering them.
Will this make my image file smaller?
Usually yes, but not because of this download. The PNG handed back is written by the browser as a full-color file that happens to contain few colors, not as an indexed one — the browser canvas has no way to emit an 8-bit palette PNG. A full-color PNG of a 16-color picture still compresses far better than the original did, because the filtering and deflate stages love large runs of identical pixels, so the file will normally shrink anyway. If you need a genuinely indexed PNG or a GIF, both of which are capped at 256 colors, treat this download as the input to that encoder rather than as the encoder.
Why did two shades I can barely separate both survive while a bright red vanished?
Because the algorithm splits by area, not by how interesting a color is. At each step it takes the box holding the most pixels and cuts it, so a large expanse of nearly identical sky earns several entries between them, while a small bright object — a red jacket, a warning light, a flower — is a handful of pixels in a box with much bigger neighbors and is merged into whatever is nearest. That is the right default for a photograph, where most of the picture is the picture. It is the wrong default for a logo or a diagram, where the small saturated thing is the subject: crop to it, or step the count up until it earns its own entry.
Is this the same thing as posterizing?
No, and the difference is which colors you end up with. Posterizing snaps each channel to a fixed ladder of levels that is decided before your picture is looked at, so a beach and a boardroom flattened at the same setting are drawing from one identical set of possibilities. This page derives its palette from your file, so two different photographs reduced to 16 share nothing at all. That makes reduction better at keeping a picture recognizable and posterizing better at making a set of pictures look like a set — they are different tools rather than two names for one.
Can I protect a color I care about from being merged away?
Not on this page, and saying so is more useful than a control that half-works. Median cut has no notion of importance: it sees a list of colors with pixel counts, and a color's fate is decided entirely by how much of the frame shares its neighborhood. Two things do work. Crop to the region you care about before reducing, which raises that color's pixel weight and usually earns it an entry. Or raise the count until it survives and read the strip to confirm — the merged-shades column tells you the moment it stops being absorbed into something else.
How few colors can a photograph survive?
Around eight for a portrait and around four for a graphic subject, and past that the answer stops being about the tool. A face needs at least a light, a mid, a shadow and a background to keep its form, and the moment two of those merge it reads as a mask rather than a person. High-contrast subjects with a plain background — a silhouette, a building against sky, a single object on a table — go much further and often look deliberate at four. The honest test is the merged-shades column: when one entry has absorbed more than about half of the distinct colors present, the picture is no longer a reduction of itself.
About median cut, and which colors a reduction spends
Reducing a picture to N colors is a choosing problem before it is a drawing problem, and the naive answers are both wrong in the same instructive way. Keeping the N most frequent colors returns N shades of whatever dominates the frame and no skin, no highlight and no sky. Dividing the color cube into an even grid and keeping the occupied cells spends most of the budget on regions your picture never visited. Paul Heckbert’s 1982 median cut answered it properly: start with every color in the file inside one box, then repeatedly take a box and split it in two, so that the palette’s density follows the picture’s density rather than the color space’s geometry. The two decisions that make or break the implementation are which box to split and where to cut it, and this one takes the box holding the most pixels and cuts at the point where half those pixels lie on each side. Cutting a sorted list in half by length instead puts the boundary wherever the rare colors happen to be.
The third decision is the one most implementations still get wrong, because the original paper predates any practical alternative: the splitting happens in Oklab here, not in RGB. In RGB a box’s widest axis is the direction its numbers spread furthest, which has no reliable relationship to what anybody would call a difference — dark greens get split finely while light blues collapse together, and a picture reduced that way looks muddy in exactly the places you were looking. In Oklab the widest axis really is the direction those colors look most unlike each other. One consequence is visible in the strip on this page: the entries land where your eye would put them, not where the arithmetic finds room. If what you want is the colors an artist deliberately placed rather than the centers of clusters, that is a different question and the palette generator answers it by counting exact colors instead; if you want the reduced regions numbered and outlined ready to fill, that is the paint-by-numbers page, which runs this same clustering and then merges the slivers no brush could reach.
What almost nothing else reports is the bill. A reduction is a set of merges, and a merge is a claim that two colors were close enough to be one — a claim that is sometimes true and sometimes the reason a photograph suddenly looks cheap. So this page counts how many distinct source shades each survivor absorbed and names the worst single shift, because those two figures tell you where the damage went and no amount of looking at the result will. It is also worth knowing which reduction you actually want. Cutting colors and cutting resolution are different operations that people reach for interchangeably: if the problem is that a region is legible and should not be, coarsening the grid is the tool and pixelating does it, while a picture with fewer colors is still perfectly readable at full size. And once the palette is settled, the speckle-or-banding question is separate again — that is the dithering comparison.
Where the census and the clustering happen
Your picture is opened by JavaScript running in the tab you are reading this in. It is never uploaded, never sent to a server and never stored anywhere — there is no upload step to undo, because there is no upload. Close the tab and nothing of it remains.
The colors it reports are read out of the decoded bitmap in memory and are never written anywhere — not to storage, not to a log, not into the URL. Reloading the page starts from an empty census.