How we handle your images

What happens when you open an image

1. Your browser reads the file you chose through the standard file input, drag-and-drop, or clipboard API. The bytes stay in your browser's memory.
2. The browser decodes it — the same decoder that shows you the picture — and produces two things: a bitmap for on-screen display, and a raw pixel buffer for sampling.
3. Sampling and palette extraction read that buffer directly. Extraction runs in a web worker so the interface stays responsive. A worker is a thread inside your browser tab, not a server.
4. When you move to another image or close the tab, the bitmap and buffer are released. If you press “New image”, the same thing happens immediately.

What we never do

• We never upload your image. There is no upload endpoint and no server-side processing. The tool is a set of static files; the page you are reading was fetched once, and nothing you drop onto it is transmitted anywhere.
• We never store your image. No IndexedDB, no cookies, no cache of your file, and nothing derived from it — not the file name, not its dimensions, not a coordinate, not a sampled colour. Recently picked colours stay in memory for the session only and disappear when you close the tab.
• We do store the palette you build, and only that. When you press “Add to my palette” we keep those hex values in your browser's local storage, on your device, under one key, so they survive a reload. That is the entire content of what we write: a list of six-character hex strings. There is no identifier beside them and no way for us to see the list — it never leaves your browser. The Clear button in the same panel deletes the record immediately, and clearing your site data removes it too.
• We never record anything about your image. Not the file name, not its dimensions, not its metadata, not the colours you picked. There is no analytics on the tool itself.
• We never read your metadata. GPS coordinates, camera model, shutter settings and edit history are left entirely alone. The tool does read the embedded colour profile, because it affects the colour values you get — but only to label the source as wide-gamut, and only in your browser.
• We never load third-party scripts. No ad networks, no social widgets, no font CDNs, no tag managers. The fonts are system fonts, so there is not even a font request.

What localStorage means for the word “anonymous”

Worth being precise about, because it is the kind of detail privacy pages tend to skip. A value in local storage is stored per site, not per person: we never read it, transmit it or join it to anything, and there is no account for it to belong to. But it does sit on your machine, and a palette you saved is visible to anyone with access to this browser profile and the developer tools to look. That is a reasonable trade for a palette you wanted to keep — and it is why the panel offers a Clear button rather than leaving you to find the setting.

What we do not claim

Trust is easier to keep when a promise is precise, so here is where we are deliberately conservative.

• We say “not uploaded” rather than “we never see it”. There is no upload step to bypass, and “not uploaded” is a statement about the architecture you can verify.
• We say “processed by your browser” rather than “on your device”. The file is read by browser code, and that is the whole of it.
• We do not claim to be anonymous, because you still requested a page from a web server and that server necessarily sees an IP address. What we can say is that the page request tells us nothing about your image.

If the tool ever carries advertising

It does not today, and no ad code exists anywhere on this site. If a display network is ever added, it will not be placed on the tool itself: the picker and the palette generator depend on third-party scripts being absent, both for your privacy and for the page's speed. That is a design constraint, not an intention.

Try it yourself

Open your browser's developer tools, switch to the Network tab, and drop an image onto the image color picker . No request carries it. That is the test we would run on someone else's privacy claim, so it is the one we expect you to run on ours.