For most of the web’s history, compressing an image online meant the same thing: pick a file, watch an upload bar crawl across the screen, wait for the server to finish processing, and download the result. The browser was a thin client. Anything heavier than a checkbox had to happen somewhere else, on a machine the user did not control.<\/p>\n\n\n\n
That assumption is outdated. Modern browsers can run the same compression codecs that servers use, and they can do it without uploading the file anywhere. The shift was quiet, but its consequences are large enough to be worth examining in detail.<\/p>\n\n\n\n
Speed.<\/strong> Round-trip time dominates the user experience. A 4 MB photo on a typical home connection takes 8 to 30 seconds to upload, then the server processes it, then the result comes back down. The actual compression work is the smallest part of the entire timeline. Users perceive the wait as one continuous slow operation, but most of it is network transport, not computation.<\/p>\n\n\n\n Cost.<\/strong> Image compression is CPU-bound work. Every photo a user processes consumes cycles on a server somebody is paying for. That cost is either passed back to users as paywalls or absorbed by advertising. It is why most “free” online image tools are full of banners and pop-ups, and why bulk operations on most platforms hit a quick paywall after a handful of files. The economics simply do not allow free at scale.<\/p>\n\n\n\n Privacy.<\/strong> Once a file leaves your machine, you have to trust that the receiving service will not log it, train a model on it, or leak it in a breach. For ordinary product photos that may not matter much. For a passport scan, a medical document, a screenshot of a private conversation, a confidential design draft, an unreleased product photo, or anything else with restricted distribution, it absolutely does. Most users have no way to verify what happens to the file after it arrives. Privacy policies routinely allow logging for “operational purposes” without further detail.<\/p>\n\n\n\n Two technologies removed the reason for the round-trip: WebAssembly and Web Workers.<\/p>\n\n\n\n WebAssembly is a low-level binary format that the browser can execute at near-native speed. It lets compiled C, C++ and Rust code run inside a web page, with performance close to what the same code achieves on a server. The major image codecs – MozJPEG, libavif, libwebp, OxiPNG, gifsicle – have all been compiled to WebAssembly and shipped as small JavaScript libraries. The libraries are typically 100 KB to 2 MB each. They load on demand, run on the user’s CPU, and never touch a server.<\/p>\n\n\n\n Web Workers solve the second half of the problem. Heavy work in a single-threaded JavaScript page would freeze the UI, which is unacceptable. A worker is a background thread the browser provides to the page. Compression runs there. The main thread stays responsive, and the worker can be terminated if the user changes their mind or navigates away.<\/p>\n\n\n\n Together, WebAssembly and Web Workers make the server completely optional for interactive image processing tasks performed by an individual user.<\/p>\n\n\n\n The skeptical reader will ask the only question that really matters: is the output actually as good as a server would produce? The fair answer is “within two to five percent of identical, with the gap closing further every year.”<\/p>\n\n\n\n Google’s own Squoosh project published benchmarks years ago showing that MozJPEG compiled to WebAssembly produces output bit-for-bit identical to the native binary at comparable quality settings. The wall-clock time is two to four times slower than native on the same machine, but that does not matter when the alternative includes an upload round-trip that itself takes longer than the entire WebAssembly operation.<\/p>\n\n\n\n For a typical 12 MP photo, server-side compression with a fast network produces a result in roughly 6 to 12 seconds end-to-end. Browser-side compression with WebAssembly takes 0.8 to 2 seconds end-to-end, because the upload and download phases are zero. The user sees less waiting, not more, even though the raw compute is slower.<\/p>\n\n\n\n On AVIF, which is computationally heavier than JPEG, the picture is similar. The libavif WebAssembly build encodes a 12 MP image in roughly 6 to 10 seconds on a 2022-era laptop. The same image uploaded and processed server-side takes 10 to 20 seconds even on a good connection. Browser-side AVIF is actually faster end to end for most users, despite being two to three times slower per byte processed.<\/p>\n\n\n\nWhat Changed in the Browser<\/h2>\n\n\n\n
How the Numbers Stack Up<\/h2>\n\n\n\n
What the Practical Tooling Looks Like<\/h2>\n\n\n\n