A developer who states in the post that they build ZipPic has published a comparison on dev.to arguing that Squoosh cannot handle three everyday image jobs: compressing many files at once, producing GIF output, and preserving animation in WebP or AVIF files. The piece carries an explicit disclosure that the author builds the competing product, so every claim about Squoosh's behavior should be read as an interested party's assertion rather than an independent audit.
The author says each limitation was checked against both the live Squoosh app and its public GitHub repository before writing. That is a stated method, not a documented one: the supplied excerpts contain no screenshots, issue numbers, commit references or reproduction steps, and no third party is cited as having confirmed the results. Readers who care about the specifics can repeat the checks themselves, which the author explicitly invites at the end of the piece.
The first claimed gap concerns batch work. According to the post, Squoosh's editor loads exactly one image, with no multi-file upload, no processing queue and no download-all option, so compressing fifty screenshots would mean fifty separate open-compress-download cycles. The author adds that users have requested batch support since 2018 and that the relevant GitHub issues remain open, and that maintainers at the time pointed users to the Squoosh CLI, which the post says has since been deprecated. Those historical details are asserted without links or dates beyond the year.
ZipPic's answer, as described, is a bulk compressor that accepts multiple files at once, processes them and returns everything as a single ZIP archive. The post says there is no strict file-count limit, recommends files under 50MB each, and lists JPG, PNG, WebP, GIF, AVIF, HEIC and RAW as accepted inputs. It also states that processing happens locally in the browser with nothing uploaded to a server, the same local-processing model the author attributes to Squoosh.
The second claimed gap is GIF output. The author says Squoosh's format dropdown offers AVIF, MozJPEG, OxiPNG, WebP, WebP v2, JPEG XL in beta, QOI and browser codecs, but no GIF, meaning the tool cannot save a GIF file at all. More pointedly, the post claims that opening an animated GIF in Squoosh returns only the first frame as a still image, discarding the animation.
ZipPic, by contrast, is described as treating GIF as a first-class format: GIFs go in and compressed GIFs come back with animation intact. The post also mentions a separate GIF Maker for trimming frames, adjusting delays and reordering, all performed locally. No details are given about output quality settings, size limits specific to GIFs, or how frame timing is preserved during re-encoding.
The third claimed gap involves animated WebP, the format many teams adopt specifically to replace heavy GIFs. The author quotes a Squoosh maintainer's repository comment that the tool does not support animation at all, and says animated WebP and animated AVIF inputs both collapse to a static first frame. The post presents that phrase as a quotation from the repository but does not link to a specific thread, so its exact wording and date cannot be verified from the supplied material.
On the ZipPic side, the post says the compressor lists Animated WEBP as an output format, returning a smaller animated WebP from an animated WebP input, and can convert an animated GIF into animated WebP. It cites a general figure that WebP typically cuts 60 to 80 percent off a GIF's size at similar quality. That range is presented without a source, a test corpus or a measurement method, so it should be treated as the author's characterization rather than a benchmark.
For freelancers and developers, the practical question is workflow shape rather than codec nuance. The author concedes that Squoosh remains strong for exactly the case it was built around: a single hero image where you want to compare AVIF, WebP and MozJPEG side by side with fine-grained settings and a preview. If your work is one-off codec exploration, the claimed limitations may never surface. If your work is a folder of product photos, a 12MB GIF or an animated banner, the post argues you need a tool that accepts those inputs at all.
The tradeoffs cut both ways. ZipPic is presented as broader in input handling and batch throughput, but the post supplies no information on output quality controls, pricing, account requirements, browser support or how its compression settings compare with Squoosh's per-codec tuning. A tool that accepts more formats is not automatically better at any one of them, and the comparison offers no side-by-side quality or file-size results for the same source images.
There are also open questions about durability. The post notes that Squoosh's CLI was deprecated and that batch requests have sat open since 2018, which, if accurate, suggests the single-image design is a deliberate scope choice rather than a pending fix. Whether Squoosh's web app will ever add queueing or animation support is not addressed beyond the author's account of past maintainer responses.
The most useful way to read this piece is as a specification of the gaps one competitor believes exist, written by someone with an obvious incentive to find them. The claims are concrete and, by the author's own framing, checkable in a public app and repository, which makes them falsifiable in a way that generic tool comparisons usually are not. But none of the Squoosh behavior described here was independently verified for this report, and the ZipPic capabilities are described only by their builder.
A reasonable next step for a developer weighing the two is to run the specific job that matters: drop an animated WebP into Squoosh and see what comes back, or try a multi-file upload and observe whether a queue appears. That takes minutes and settles the factual core of the comparison without relying on either party's account. The rest, including the 60-to-80-percent WebP figure and any quality claims, would need measured tests on your own images before it informs a workflow decision.