How Client-Side Image Compression Actually Works

image-reducer.com is a free, complete image toolkit: batch processing, every common format (JPG, PNG, WebP, and AVIF), an exact-KB target-size mode, a crop/rotate/flip editor, a before/after compare slider, and full support in 7 languages including right-to-left Arabic. All of that runs on one underlying pipeline — and this article is the plain-language, honest explanation of what that pipeline actually does the moment you drop a photo in, what it technically means for images to be "processed entirely in the browser and never sent to a server," and how that claim is checked rather than just stated.

What happens when you drop a photo in

Add a photo — by dragging it onto the page or picking it from a file browser — and the app decodes it into raw pixel data, the same way any image-viewing app would. From there, a small pipeline runs entirely inside your browser using Canvas 2D, a standard drawing API built into every modern browser, not a proprietary trick: any rotate, flip, or crop you apply gets baked into the pixels first, the image is resized if you've set a target width/height, and then it's re-encoded into the output format you chose.

Because encoding a photo is genuine computation — real CPU cycles, not a lookup — doing it on your own device instead of a server means it has to happen without freezing the page. So the heavy part of that work runs on a background thread (a Web Worker), separate from the thread drawing the screen, with a fallback path for older browsers that don't support it. You keep scrolling and adjusting settings while the encode happens behind the scenes.

The exact-KB search works the same way, just aimed at a number instead of a quality slider. Turn on target-size mode and enter a KB budget, and the pipeline tries an encoding quality, checks the resulting file size, and adjusts up or down — narrowing in on the highest-quality version that still lands at or under your number, in a handful of tries instead of dozens of manual guesses. (This mode currently targets JPEG output specifically; WebP and AVIF are controlled with the quality slider rather than a KB target.)

What "never sent to a server" technically means

Stated precisely: no request made by the app during the add → edit → download flow ever carries any of your image's bytes, in a body or a URL, to any origin. The decode, the edit, the resize, the encode, and the ZIP packaging for a batch download all happen on-device; there's nothing on the other end waiting to receive your photo, because nothing is ever sent.

Two things enforce that beyond just the app's own code. First, a Content-Security-Policy — a browser security header — tells your browser itself which origins the page is allowed to talk to at all; anything outside that short allowed list is refused by the browser, not by the app's own good behavior. Second, an automated check runs on every release that inspects the network traffic of a full add-edit-download cycle and fails the build if a single request carrying image data appears, alongside a companion check that the whole flow still completes with the network disconnected — proof there was never a server round-trip to depend on in the first place.

You don't have to take any of that on faith. Open your own browser's developer tools, switch to the Network tab, and run through adding, editing, and downloading a photo yourself — you'll see no request leave with your image in it, because none is made.

A side effect worth knowing: your download loses its metadata

Because the pipeline decodes and redraws every photo pixel-by-pixel rather than copying the original file byte-for-byte, none of the source file's metadata carries into the output — no camera make/model, no capture timestamp, and no embedded GPS coordinates. This happens automatically on every processed image, whether or not you touch the editor.

One nuance worth knowing: many phone photos store an orientation tag rather than physically rotating the pixels, and that tag doesn't survive the redraw either — so the pipeline reads it *before* the strip happens and applies the correct rotation itself, which is why your download still comes out right-side up. Your original file, still sitting on your device, is never touched or altered; only the new file you download is affected.

It works offline, too

Because none of this depends on a server, image-reducer.com keeps working with no network connection at all once the page has fully loaded — add, edit, and export a whole batch on a flight, a train, or anywhere a connection is unreliable mid-form. That's a direct consequence of the architecture above, not a separate feature bolted on top of it.

The honest limits — real computation, not magic

None of this is free. Encoding is real work, which is why a very large batch or a very high-resolution photo takes a moment rather than being instant, and why images above 64 megapixels are rejected up front rather than risking a crash trying to process them. Occasionally a very detailed photo simply can't reach an aggressive KB target at a usable quality — when that happens, the tool says so plainly ("closest achievable…") instead of quietly pretending it hit the number.

It's also worth being upfront that this approach isn't unique to image-reducer.com. Google's open-source Squoosh project popularized browser-based image compression years earlier and remains a well-known, well-built example of the same technique. What differs here is the rest of the toolkit built around this particular pipeline — batch processing, the exact-KB mode, the full format matrix, an in-browser editor, a compare slider, and 7-language support in one place — with the no-upload behavior standing as one tested property of that toolkit, not the whole pitch.

Keep going

Curious how the exact-KB search plays out on a real deadline? See how to compress a photo to exactly 100KB, 50KB, or 20KB, or head back to image-reducer.com to try the pipeline above on your own photos. Have a specific question about privacy, formats, or metadata? Check the FAQ.

---

image-reducer.com is an independent product operated by ZIX DEV Inc. It is not affiliated with, endorsed by, or sponsored by Squoosh or any other third-party product mentioned for comparison.