Squoosh is frozen, not gone: what changed and what to use in 2026
There is a piece of advice floating around the web right now that says Squoosh is gone and you should move on. We went and checked, because being wrong about this in either direction would be bad advice. Squoosh is still running — the site loads, it still compresses, and it still does everything in your browser. It has not been shut down.
What is actually true is more interesting than "it's dead", and it matters a lot if you are about to build a workflow on top of it. I checked three things directly rather than trusting blog posts that repeat each other: the live site, its repository, and what each one can still do.
What I checked, and what I found
| What | Status, checked October 2026 |
|---|---|
| squoosh.app (web app) | Live, no shutdown notice, still compresses locally |
| Command-line tool & libsquoosh | Deprecated in January 2023, removed from the repo |
| Repository default branch | Last commit 19 August 2024 |
| Batch processing in the web app | Still absent — one image at a time |
| Codecs (MozJPEG, OxiPNG, WebP, AVIF) | Still offered |
So the accurate summary is three sentences long: the web app works, the project is no longer being developed, and it has never handled more than one image at a time. Any article telling you Squoosh is "shut down" is overstating it. Any article telling you nothing has changed is understating it.
Why people think it died
The likely source is a commit in the repository that removed the CLI and the shared library. The message attached to it is unusually candid: the maintainer explained that people had left the team, that staffing was the constraint, and that there was simply not enough time to keep working on it — adding that anyone who wanted to fork it had their blessing. That is a project winding down by circumstance rather than by decision, and those two things get reported identically in comment sections.
What followed was silence. Nearly two years of no commits to the default branch is what convinced most people to write it off. Google never published an end-of-life date, so the tool did not break — it simply stopped moving, and a project that stops moving ages badly in a field where image codecs change every year.
The limitation that was always there
Set the maintenance question aside and Squoosh is genuinely good. The side-by-side before-and-after preview with a draggable divider is a better way to judge compression than a slider and a number. The codec choice is unusually broad for a web tool, and everything runs locally.
But it has always handled exactly one image at a time. There is no batch mode, no folder drop, and no ZIP export. For three hero images that is not a limitation. For the 500-file media library behind a normal website, it means repeating a drag-save-adjust cycle five hundred times, which is the kind of task people quietly abandon rather than complain about loudly — so it gets described as "one image at a time" in passing instead of being named as the real reason to look elsewhere.
This is also the single most common thread running through the developer communities when they discuss browser-based compressors: privacy is what pulls people in, and batch support is what pushes them out.
So what should you actually use
It depends entirely on the shape of the job, and it is worth being blunt that different tools fail at different things.
If you are compressing a handful of images
Keep using Squoosh. There is no reason to move for three or four files, and the comparison view is genuinely better than most alternatives. Its silence about the future is a fair reason to plan an exit, but not a reason to abandon it today.
If you are doing a whole library, a product shoot or a batch for a client
Batch support is the deciding feature, and this is where the options split cleanly by whether your files get uploaded:
- Browser-based, no upload, batch + ZIP — the SnapTools compressor does the work on a canvas in the page and hands the results back as a zip. Files never touch a server, so client assets and unreleased work are not sitting on someone else's machine. The trade-off is honest: no JPEG XL, no OxiPNG, no AVIF encoding, because browsers cannot produce them without shipping large codec bundles.
- Server-based batch — the established hosted tools handle bulk work well and support more formats. The cost is that your images are uploaded, and the free tiers cap how much you can do per month.
- Command line or CDN — for CI pipelines and sites with thousands of assets, encode-on-build beats any browser tool. Since the Squoosh CLI was deprecated, the usual choices are Google's own encoder binaries and sharp. This is the right answer for a team, and the wrong answer for anyone who would have to install something first.
One thing worth saying plainly: if you are moving a client workflow, "no upload" is not a nice-to-have. Agencies and freelancers get asked about it constantly, because putting proprietary assets on a third-party server is a compliance question before it is a preference.
If you need a codec Squoosh has and nothing else does
Then Squoosh is still the tool. JPEG XL and OxiPNG are not things a plain canvas can produce, and the underlying codecs are maintained independently of Google's app — only the wrapper is stalled. Pulling one of those codecs into a command-line pipeline is a reasonable response to this whole situation.
What I would actually do
If I were picking a setup today: keep Squoosh bookmarked for one-off precision work, and move the bulk of your volume to something that accepts a folder. Whatever you choose, verify the upload behaviour yourself rather than taking a marketing page for it — open the network tab, drop in a file, and look at what actually leaves the machine. That check takes ten seconds and it is the only claim on this page that does not depend on my judgement.
Frequently asked questions
Is Squoosh shut down?
No. We checked squoosh.app in October 2026 and it still loads and still compresses images in your browser. The site carries no shutdown notice. What was deprecated is the command-line tool and the libsquoosh library, not the web app.
Why do people call Squoosh dead?
Because its public GitHub repository has not seen a commit to the default branch since 19 August 2024, and the CLI and libsquoosh library were deprecated in January 2023. The code still runs, but nothing is being added to it, which is why planning around it is risky.
What was the main limitation of Squoosh all along?
It handles one image at a time. There is no batch mode, no folder drop and no ZIP export in the web app, so cleaning up a media library means repeating the same drag-and-save cycle hundreds of times.
Does SnapTools upload my images?
No. SnapTools draws images onto a canvas element and re-encodes them in your browser using JavaScript. There is no upload step, so there is no server that could retain a copy. You can verify this in your browser's network tab with the connection switched off.
Can I still use the Squoosh codecs?
The underlying codecs such as MozJPEG and OxiPNG remain available and independently maintained. Squoosh simply no longer ships a command-line interface, so any guide telling you to run squoosh-cli is out of date.