Privacy

Your photograph is opened by the browser, held in the tab’s own memory while you work on it, and discarded when you close the tab. It is not sent to this site, because this site has nowhere to send it to — there is no server component here, only files served to your browser. Nothing about your picture is stored, logged, counted or remembered.

Choosing a file hands the browser a reference to it. The browser decodes it into pixels; a copy no more than 1600 pixels on its long edge is made for the screen; the effect kernels read that copy and write a new one. When you export, the original is decoded again at full size, run through the same kernel, encoded by the browser, and handed back to you as a download that was assembled entirely inside the tab.

The heavy arithmetic happens in a Web Worker, which is a second thread inside the same tab, with the pixel data passed to it directly in memory. Nothing crosses the network at any point in that sequence. One exception exists and it is worth naming: opening a HEIC file — what recent iPhones write by default — causes the page to fetch a WebAssembly decoder, because browsers do not decode HEIC themselves. That request downloads code to your machine; your picture does not travel in the other direction.

No part of your session lands in local storage, in session storage or in any in-browser database. Shut the tab and nothing you did here survives it, not even on your own machine.

Not at the moment, and you can check that from the page source. Measurement here would need a property token, the token has never been filled in, and the build leaves the beacon out entirely rather than shipping one that reports to nowhere — so no request is made on your behalf when this page loads, and nothing keeps a tally of it.

If that ever changes, the counter going in is a cookie-free one that builds no profile across sites, and it would see the sort of thing a server log sees: that a page was fetched, roughly from where, and what kind of device asked. It would still be blind to your picture, your settings and your filenames, because nothing in the lab ever hands those to anything. This paragraph gets rewritten the day that switch is thrown, not after.

This lab is built to carry Google advertising, and that is how it is meant to pay for itself. None of it is on the page you are reading: the domain is still pending AdSense approval, the master switch in the code is off, and no ad frame, no reserved band and no Google script is fetched while you work. The disclosure sits here in advance because it describes the arrangement the moment that account clears, and because terms are better read before they start applying than after.

Where the units will go when they do arrive: underneath the working surface and inside the reading, never between you and the picture. Google may set cookies to decide what to show you and may collect what any embedded advert collects — which page you are on, roughly where you are, what device you hold. Google’s own policies govern all of that; you can change it from Google’s advertising settings, or block the frames outright, and the lab works identically either way.

What an advert will never be able to do is read your photograph. It runs inside a frame of its own, with no reach into this page’s canvas and no reach into the file you opened, and nothing here is handed to it. That is how browsers isolate frames, not a promise you are being asked to take on trust.

The site is a general-purpose picture tool and is not directed at children, and it collects nothing from anyone that could identify them.

If this policy changes it will change here, and the change will be one you can read rather than a line saying the policy has been updated. The architectural part of it — that pictures stay on your machine — cannot change without the site being rebuilt as a different kind of thing, which would be obvious rather than quiet.