Color palette from image — full-pixel extraction

Extract a color palette from image pixels, not a resized thumbnail

Choose, drop or paste a PNG, JPEG, WebP or AVIF image. The browser decodes it with the source orientation applied, then a local worker reads the complete RGBA pixel buffer. There is no sampling grid and no hidden resize. A 4,000 × 3,000 image therefore contributes all 12,000,000 decoded pixels to the count. Decoded area and compressed file size do not predict palette time: the local worker first counts the exact RGB histogram. Only images with millions of distinct decoded colors pause for confirmation before the expensive palette sorts, and that warning remains advice rather than a limit.

Pixels with alpha below 128 are excluded. This prevents nearly transparent matte colors from becoming prominent swatches, while pixels at alpha 128 or above keep their decoded RGB values. The receipt reports total, included and excluded pixel counts so the threshold is visible rather than an undocumented cleanup rule. That threshold is also why a product shot on a busy backdrop is worth cutting out first: the transparent background maker turns the surroundings transparent, and those pixels then drop out of the coverage count.

Deterministic median cut with measured coverage

Median cut groups the exact RGB histogram into 5, 8 or 12 initial colors. Every included source pixel is then assigned to its nearest initial swatch in RGB distance, and each swatch is recentered on the pixels assigned to it. That second pass keeps the displayed color and its coverage count tied to the same pixels. It also makes the ranking reproducible: greater coverage comes first, and equal counts are ordered by lowercase HEX ascending.

Coverage is descriptive, not semantic. A frequent color is not automatically a brand color, background or accessible text color. The generator does not invent names such as primary and accent. It exports neutral numbered CSS properties along with CSV rows and a JSON receipt, leaving role assignment to the designer who understands the image and its intended interface.

The reproducibility boundary starts after browser decoding

Identical decoded RGBA bytes always produce the same histogram, median-cut initialization, recentered palette, coverage values and ordering. Image decoding happens before that algorithm. ICC profiles, color-space conversion and lossy JPEG reconstruction can yield slightly different bytes across browser engines or decoder versions. For an exact cross-machine comparison, use images normalized to the same unprofiled PNG RGBA bytes and compare the exported JSON receipts.

HEX output describes the browser-decoded RGB pixels; it is not a Pantone lookup, a CMYK separation or a calibrated print proof. It also does not identify a color at a clicked point. Point sampling is an eyedropper job, whereas this page summarizes the distribution of the whole image. If the source is a rendered web page rather than an image file, use the website color palette extractor. That tool measures resolved CSS colors, font stacks, spacing and shadows from an open page instead of reducing raster pixels.

Local analysis and portable exports

The source image remains in this tab. Decoding uses the browser image API, and the full pixel count runs in a worker so the page can continue painting while a large histogram is built. JSON keeps the source filename, MIME type, byte size, dimensions, decoder statement, algorithm version and alpha threshold beside every swatch. CSV is convenient for analysis; CSS provides numbered custom properties ready for a reviewed design system. Copying or downloading never sends the original image to CreatorValet.