What actually happens to your photo.

Decoding, editing, re-encoding — with no upload step

A file you choose is read from disk with the File API, decoded into a Canvas or an OffscreenCanvas inside a Web Worker, and re-encoded either by the browser's own image encoder or by a WebAssembly codec compiled directly into the page. @jsquash/webp handles WebP everywhere, because Safari still cannot produce WebP from canvas.toBlob — a real gap in the standard, not an oversight here.

Resizing uses a Lanczos resampling kernel rather than the browser's default nearest-neighbour or bilinear scaling, which is why a downscaled image here does not come out visibly softer than the source deserves.

What EXIF removal actually deletes

A photograph carries more than the picture: a phone writes GPS latitude and longitude, a capture timestamp, the device make and model, and often a lens serial number into the file's EXIF block. The EXIF Viewer & Remover strips this without touching the pixels at all.

The mechanism is byte-level, not a re-encode: the JPEG's APP1 and COM marker segments are dropped while the entropy-coded scan data is copied through unchanged. The result is bit-identical to the source image and the ICC colour profile survives — this is the one image tool that does not decode and re-encode, because there is no reason to touch pixels to delete metadata sitting in a separate part of the file.

Getting good compression without visible loss

A few things determine whether a smaller file still looks right at the size you are viewing it.

• Quality is not linear: dropping from 90 to 80 usually costs little, dropping from 40 to 30 usually costs a lot. Compare at the size you will actually display the image, not at 100% zoom.
• WebP typically beats JPEG at the same visual quality, but check compatibility if the image needs to work in an older tool that only reads JPG or PNG.
• Batches are processed strictly one image at a time, decode → encode → release → next, to keep peak memory to roughly one image regardless of how many are queued.
• iOS caps canvas area at about 16.7 megapixels — 4096×4096 on older devices — so a very large photo is clamped rather than silently coming out blank.

Why this runs in your browser

None of this needs a server: decoding, resampling and re-encoding are all things a browser already does natively or can do with a WebAssembly codec loaded once into the page. Uploading a photo to do it anyway means handing over whatever the file's own metadata discloses — including exactly where it was taken — to a site whose retention policy you have not read.

You can verify the claim rather than take it on faith: open your browser's network inspector, run any image tool, and watch that no request carries the file.