How compressing an image in the browser works
Your file is decoded into a bitmap, drawn onto a canvas at the output size, and re-encoded by the encoder built into your browser. Nothing is edited in place: a brand-new file is written every time. That is why even a “quality 100” pass produces different bytes from your original, and why re-encoding an already-compressed JPEG can add artifacts instead of removing them.
JPEG and WebP are lossy: the 1–100 slider is handed to the encoder as 0.01–1.00. PNG is lossless, so a quality slider would do nothing at all — PNG sources take a different path and have their colour palette reduced instead (256 colours by default, down to 2). The browser’s own PNG encoder is deliberately never used on a PNG, because canvas PNG output is routinely larger than the file you started with.
The canvas has hard limits — 16 megapixels of area and 4,096 px on the long edge — above which browsers (iOS Safari first) simply fail. A 6,000×4,000 photo is 24 MP, so it is downscaled to fit and the row is marked “Downscaled to 4096 px” rather than failing silently.
Quality mode vs Target size mode
Quality mode encodes every image once at the level you choose. It is predictable and fastest, and it is the right choice for a batch where consistency matters more than any particular byte count.
Target size mode is a binary search on quality. Type 200 KB (or 1.5MB, or a plain 204800) and the first encode runs at quality 0.80; a result over the target lowers the ceiling, a result under it raises the floor, and the highest quality that still fits is kept. The search stops after 8 encodes, once the bracket is narrower than 0.01, or as soon as a result lands within 5 % under the target — in practice 3–5 encodes.
Two edge cases are reported instead of hidden. PNG cannot hit a byte target losslessly, so target mode encodes to WebP and says so on the row. If even quality 0.05 is still bigger than your target, you get the smallest possible file plus a note like “Smallest possible: 240 KB (target 100 KB)”. Targets outside 1 KB – 50 MB are rejected before anything runs.
Which quality level to pick
- 90–95 — archive and print. Savings of only 10–30 % on a camera JPEG, but no visible change even at 200 % zoom.
- 80 (the default) — the point where most photographs stop looking different at 100 % zoom. A 4 MB phone photo typically lands between 700 KB and 1.2 MB.
- 70–75 — blog and web page images. Roughly half the size of the same picture at 85, and fine on any screen.
- 55–65 — thumbnails and previews. Smoothing starts to show in skies, skin and gradients.
- Below 50 — blocking around edges and text is obvious. Resize instead; you will get a smaller file that still looks sharp.
Flat graphics, screenshots and text on a solid background are the worst case for JPEG: the encoder spends its budget on the sharp edges and leaves ringing around every letter. Keep those as PNG or WebP.
JPG, WebP or PNG: choosing the output
WebP at matching visual quality is typically 25–35 % smaller than JPEG and, unlike JPEG, keeps transparency. Every current browser displays it, Safari included since version 14. It is the default answer for anything that will live on a web page.
JPG is what you choose when the file has to open everywhere without thought — email attachments, print shops, older document systems, upload forms that check the extension. It has no alpha channel, so transparency is filled before encoding.
PNG stays lossless here; compression means palette reduction. 256 colours is invisible on most screenshots and UI captures, 64 shrinks flat graphics a great deal, and 16 will band a photograph badly. If the reduced file comes out larger than the original, your original file is kept untouched and the row says “Already optimized”.
“Keep original” re-encodes each file in its own format, which is what you want for a mixed batch of screenshots and photographs.
Resizing saves more than the quality slider ever will
File size follows pixel count, so halving width and height removes about 75 % of the pixels before the encoder even runs. A 4,032×3,024 phone photo (12 MP) capped to 1,600 px wide becomes 1,600×1,200 — 16 % of the original pixels. That one change usually beats anything the quality slider can do.
Max width and Max height are downscale-only bounds: an image already smaller is passed through unchanged, and the smaller of the two ratios wins so the aspect ratio never changes. Leave a field empty for “no limit”, and run a mixed batch through a single cap without touching the small files.
Practical caps: 1,920 px for a full-width hero, 1,200 px for a blog body image, 800 px for a product thumbnail, 1,080 px for Instagram, 2,048 px for anything the destination is going to re-compress anyway.
When the file barely shrinks — or grows
- It was already compressed. A JPEG saved at quality 75 and re-encoded at 80 gets bigger, not smaller; the row shows “+3%” instead of a saving. Lower the quality below the file’s original setting or switch the output to WebP.
- It is a PNG screenshot of text. 256 colours may already be everything the image uses, so palette reduction changes nothing. Drop to 64 or 32 colours, or convert it to WebP.
- The file is tiny to begin with. Below roughly 30 KB the JPEG header and quantisation tables are a meaningful share of the file and there is little left to remove.
- Transparency is in the way. PNG → JPG adds a background colour and often shrinks dramatically; PNG → WebP keeps the alpha channel and still shrinks.
If none of that helps, resize. A file that refuses to compress almost always has more pixels than its use requires.
EXIF, GPS and what re-encoding removes
Canvas re-encoding produces a bare image stream, so every metadata block disappears: EXIF, GPS coordinates, camera and lens model, capture time, copyright fields, embedded thumbnails. For anyone publishing photographs that is the point — a picture straight from a phone’s camera roll can carry the exact coordinates of the place it was taken.
Orientation is handled before the metadata goes. Images are decoded with imageOrientation: "from-image", so a photo taken sideways is rotated into place and stays that way. Without that step, dropping the EXIF orientation tag would silently lay every portrait photo on its side.
Keep an original copy whenever the metadata itself matters — a photographer’s copyright field, timestamps that may be evidence, a Lightroom catalogue. Colour profiles are not preserved either: a wide-gamut Display P3 photo is re-encoded without its ICC profile and can look slightly flatter.
Your images never leave the device
Decoding, resizing, encoding and ZIP packing all happen inside this tab. Because there is no upload there is also no queue, no maximum file size, no daily limit and no copy sitting on a server waiting to be deleted “within 24 hours”.
You can check it yourself: open DevTools → Network, compress a batch and count the requests carrying your files. There are none, and the counter under the file list says the same. Turn Wi-Fi off after the page loads and everything still works.
The ZIP is built with STORE rather than deflate, because JPEG, PNG and WebP payloads are already compressed — deflating them again costs seconds and saves almost nothing.