Squoosh Alternatives for Mac: Google Stopped Maintaining It

Four jobs where reaching for Squoosh instead of buying anything is the correct call, and we would tell you the same if you emailed to ask.

One image, right now. A hero shot for a blog post, a screenshot for a ticket, an avatar that needs to get under a form limit. Drag it in, pull the quality slider until the byte count looks right, check the slider view at 100%, download. There is no faster path and no reason to pay for one.

Learning what the settings actually do. This is Squoosh’s real gift and the reason it deserves to outlive its maintenance. Set MozJPEG to quality 90, then 75, then 60, and drag the divider across a face or a patch of sky. You can watch chroma subsampling smear a red logo, and see exactly where AVIF turns foliage into watercolor. Nothing else teaches encoder behavior that directly, and once you have seen it you make better choices in every other tool you ever use.

You are not on a Mac, or not on your own machine. Squoosh runs on Windows, Linux, ChromeOS, Android, and a locked-down work laptop where you cannot install anything. A $29 macOS app is useless to someone on a Chromebook.

You need JPEG XL, WebP2, or QOI. Smol does not output any of them. Squoosh does. If you are testing JXL for an archive or benchmarking QOI for a game asset pipeline, Squoosh is the tool with the encoders.

The line is batch and breadth. One image at a time, Squoosh wins on interface and price. The moment the job is a folder of forty product shots, a client delivery with PDFs in it, or a camera roll full of HEIC, the browser tab becomes the bottleneck and the manual loop starts costing real minutes.

Not by Google. The evidence is public and it is unambiguous, so here it is with dates.

The default branch of GoogleChromeLabs/squoosh is dev. Its most recent commit is e8d35e0f, “Replace deprecated terser plugin”, dated 19 August 2024. The branch that serves the live site, live, is older still: 13 August 2024. The repository has no GitHub releases at all. The only commits pushed anywhere in it during 2026 are automated Dependabot bumps sitting unmerged on their own branches, the most recent on 3 September 2026.

On 18 May 2026 a user opened issue #1472, “Abandoned?”, noting there had been no activity for two years and asking for an alternative with a similar feature set. Jake Archibald replied the same day:

“The problem is the folks who built it left Google, and Google refused to hand the project over, or maintain it.

That said, I still have commit & publish access, so I was planning on updating the JPEG XL and AVIF codecs some point soon.”

Read that second sentence carefully, because it is the part that gets dropped when this quote gets passed around. He still has the keys, and he has said he intends to refresh two codecs. As of 26 September 2026, four months later, no such commit has landed. That is not a criticism of anyone: Archibald does not work at Google and owes the project nothing. It is simply the status. A widely loved tool with no owner, kept alive by one person’s goodwill and a static hosting bill.

Frozen is not the same as broken. squoosh.app loads, the WebAssembly encoders run, and the output is as good as it was in 2024. What it means is that you should not wait for a batch mode, a HEIC decoder, or JPEGLI support, because there is no one whose job it is to add them.

Because the entire interface is built around comparing one image against itself. The split view, the draggable divider, the two independent encoder panels, the live byte readout: all of it assumes a single source image on screen. Batch processing is not a missing button, it is a different app.

The request is old and it is popular. Issue #1259, “Batch / Bulk process”, has been open since 11 July 2022 with 15 reactions and five comments. A second request, #1405, has been open since 8 March 2024. A community pull request titled “Feature/batch compression”, #1479, was opened on 1 July 2026 and has sat untouched since the day it was filed. With no active maintainer, an open pull request is a message in a bottle.

There used to be an answer for bulk work: @squoosh/cli, a Node wrapper that ran the same WebAssembly encoders over a glob of files. It was last published to npm as version 0.7.3 on 3 January 2023, and the cli/ and libsquoosh/ directories no longer exist on the dev branch. If you find a tutorial telling you to npx @squoosh/cli your way through a folder, that tutorial is three years stale.

So the practical cost of Squoosh’s design is arithmetic. Forty product shots means forty drags, forty settings checks, forty downloads, and forty files landing in your Downloads folder with names you then have to sort out. Even at a brisk fifteen seconds per image that is ten minutes of clicking, and the attention cost is worse than the clock: somewhere around image twelve you stop checking the slider.

A native app inverts that. Drop the folder, get the folder back. Smol also exposes the same operations through an MCP server, so an AI coding agent like Claude Code can compress a build’s image assets as a step inside a task rather than as a chore you remember afterwards. A browser tab cannot participate in that at all.

This one catches out almost every Mac user, and the explanation is genuinely interesting: Squoosh ships no HEIC decoder, and the reason is licensing, not neglect.

When someone asked for HEIF and HEIC support in issue #733 on 10 March 2020, Archibald closed it the same day: “Unfortunately those formats come with a licence fee, so we can’t add them to the app.” The request came back on 23 April 2026 as issue #1466, from someone whose iPhone photos would not load in Chrome. The reporter then noticed something odd and posted it himself: it worked in Safari. Archibald explained why: “the format isn’t open, so it comes with a licence fee… If the browser already supports it (which is the case with Safari), we can use the browser decoder.”

That is the whole behavior in one sentence. Squoosh has WebAssembly decoders for AVIF, JPEG XL, WebP, WebP2, and QOI, and for everything else it hands the file to the browser. macOS decodes HEIC at the system level, so Safari can open it and Chrome on the same Mac cannot. If your camera roll is HEIC and you use Chrome, Squoosh is not a tool you can use at all, and no amount of retrying will change that.

Anything that decodes HEIC natively on macOS sidesteps this. Smol treats HEIC as both an input and an output format, so an iPhone export goes straight to JPEG, WebP, or AVIF. Preview and sips handle it too, if all you need is a format change.

Here is a number we measured rather than one we found, using a corpus anyone can download and repeat.

Method. Nine publicly hosted sample images (five JPEG, four PNG, 2,068,780 bytes total) taken from the sample gallery on optimage.app, compressed in a single batch by Smol with output format set to original, image quality 75, and metadata stripping on. Machine: Apple M2 Pro, 16 GB, macOS 27.0 (build 26A428). Every image was already below the resize ceiling, so no image was resampled: input and output pixel dimensions are identical for all nine files.

Result. 2,068,780 bytes in, 559,774 bytes out, a 72.9% reduction. The whole batch took 4,338 ms: 4.3 seconds from one drop, including the PNGs, with the files written back beside the originals with a _compressed suffix.

Be careful what you take from that. The interesting figure is the clock, not the ratio. Quality 75 trades visible quality for bytes, so 72.9% is not a like-for-like score against a tool tuned for visually lossless output, and we are not presenting it as one. Squoosh, given the same nine files and comparable settings, would produce broadly comparable output, because underneath it runs broadly comparable encoders. What it cannot do is produce them in one action. Nine images is nine round trips through a browser tab.

That is the whole argument for a native batch tool, and it is an argument about time, not compression math. If you process nine images a year, four seconds versus four minutes does not matter. If you process nine images before lunch, it is the only thing that does.

Five options that cover essentially every reason someone searches for this, with the honest use case for each.

Most of those have their own page here, written the same way as this one. ImageOptim alternatives for Mac covers the free lossless route and where it runs out. Smol vs TinyPNG is the one to read if the real question is local app versus cloud service. Optimage alternatives documents another Mac compressor that stopped shipping in 2021 and is still Intel-only, and compressing images on Mac, every method compared covers Preview and the command line too.

If the answer for you is the native one, Smol is a one-time $29 purchase covering one Mac, with no subscription and no per-file limits.