In-browser compression never transmits your file. Server-side compression can use better encoders and handle bigger jobs. Both are legitimate; they suit different work.
Client-side. The page delivers JavaScript that runs in your browser. Your file is read from disk into the tab's memory, decoded, drawn to a canvas, re-encoded and offered back as a download. The server sends code and receives nothing.
Server-side. Your file is uploaded, processed by software on a machine the operator controls, and the result downloaded. The server can run any encoder its owner chooses.
It is worth being straight about this rather than pretending the choice is one-sided.
Better encoders. A browser gives you whatever its canvas implementation provides. A server can run MozJPEG, which produces smaller JPEGs than any browser; AVIF, which browsers can display but not write; or JPEG XL. On identical input, a well-configured server-side pipeline will beat a browser by a meaningful margin.
Formats browsers cannot read. HEIC, RAW files from cameras, TIFF and PSD are decodable server-side and simply are not available in Chrome or Firefox. This is a hard limit, not a matter of effort.
Scale and size. Each image must be held uncompressed in memory while it is processed. A browser tab has a ceiling, and very large files or very large batches will exhaust it — particularly on a phone. A server has as much memory as it is given.
Consistency. Every browser's encoder differs slightly, so the same settings produce slightly different files on different machines. For a production pipeline where reproducibility matters, that is a real problem.
Privacy, absolutely. Not "we delete after an hour" — there is no copy to delete, because none was transmitted. For identity documents, signatures and confidential material this is not a marginal advantage.
No round trip. Uploading a 5 MB photograph on a domestic connection takes longer than compressing it does. For one file, in-browser is usually faster overall.
No queue and no quota. Because the operator pays nothing per image, there is no reason to ration. Server-side services meter usage because processing genuinely costs them money.
Works offline. Once the page has loaded, it keeps working with no connection.
Every tool here is client-side, which is a deliberate trade and has costs we would rather state than hide.
There is no HEIC tool, because browsers cannot decode HEIC. There is no AVIF encoder, because browsers cannot write AVIF — and a canvas asked for a format it cannot produce silently returns a PNG, so an AVIF page would hand most visitors a mislabelled file. There is no RAW or TIFF support for the same reason. Very large batches can exhaust a phone's memory. And a server running MozJPEG would produce slightly smaller JPEGs than your browser does.
What you get in exchange is that no file ever leaves your device. For the work most people bring here — a photograph for a form, a batch for a website — that is the better trade. For the cases above it is not, and the right answer is desktop software or a server-side service chosen knowingly.
Everything below runs in your browser, so you can test any of this on your own files without uploading them.
Shrink JPG and JPEG photographs with a quality slider or an exact target size.
Open the toolOne setting across a whole folder, processed in parallel, downloaded as a ZIP.
Open the toolStrip GPS coordinates, camera model and timestamps before you publish.
Open the toolZero quality loss, every pixel preserved exactly. Honest about how modest the saving is.
Open the toolQuestions
Every answer below is present in the page source, expanded, so it can be read without opening anything.
Neither universally. Client-side is better for privacy, speed on single files, and unlimited use. Server-side is better for encoder quality, formats browsers cannot handle, very large files and large-scale automation. Choose by which of those matters for the job in front of you.
Slightly, in the sense that a browser's encoder is not as good as MozJPEG or a well-tuned AVIF encoder. The difference is a few per cent of file size at matched quality, not a visible difference in the image. For most purposes it is not the deciding factor.
Because browsers cannot decode those formats. It is a hard limitation, not an oversight — a client-side tool has only what the browser provides. Anything claiming to compress RAW in a browser is either uploading your file or shipping a large WebAssembly decoder.
Effectively yes, set by your device's memory rather than by the site. Each image is held uncompressed while processed, so a very large file or a very large batch can exhaust a browser tab — most noticeably on phones.
Because processing costs the operator nothing — your device does the work. Server-side services meter usage because each image consumes real CPU time they are paying for. That difference in economics is why one can be unlimited and the other generally is not.
Yes. Load the page, disconnect from the internet, and try to compress an image. Client-side tools keep working; server-side tools fail. You can also watch the Network tab for a large upload while it runs.
From the blog
Longer, more practical guides from the blog.
Resize before you compress. Measured on one photograph: half the width at quality 80 produced a 16.4 KB file, while full width at quality 40 produced 20.6 KB and looked far worse. The order of operations matters more than the settings.
8 min read
A photograph from a phone can carry the coordinates of the place it was taken, the camera serial number and the exact timestamp. Removing that data is straightforward. Removing it carelessly rotates your photos sideways.
9 min read
WebP produced a 27.0 KB file against MozJPEG's 41.1 KB on the same photograph at slightly higher measured fidelity — 34% smaller. It also produced a larger file than JPEG on random noise. The advantage is real and content-dependent.
9 min read