Web vs. CLI image compression: choose by workflow, not habit
Browser tools cut setup for occasional work; command-line tools fit repeatable pipelines, but they add engineering and quota decisions.
Use PiPic to compress each format family, then connect the assets with picture markup and a simple check for missing or mismatched files.
A modern image can have a legacy escape route without forcing every visitor to download the same file. The HTML picture element lets the browser choose among offered formats, while the nested img supplies the fallback. The practical challenge is keeping those sibling assets small, visually acceptable and present at the paths the markup expects.
PiPic can compress JPG, PNG, WebP and AVIF images. Pair it with ordinary HTML markup and the build checks you already use: PiPic handles compression, while your asset naming and release process keep the variants together. This is a workflow for an existing site with opaque photographic images; JPG is not a suitable fallback when the image needs transparency.
Choose one representative image, such as a page hero, and make its variants siblings in a predictable directory. For example, use hero.jpg, hero.webp and hero.avif. Keep the same base name so a reviewer can see that all three files belong to one image. Avoid making a new crop or changing the subject between formats: format choice should not also change the content.
Before processing a batch, check the file sizes and split the work if needed. PiPic’s browser version accepts up to 100 images per batch, with a limit of 8 MB per file. It needs no account or sign-up and adds no watermark. Uploaded files are deleted from PiPic’s servers immediately after compression. For occasional work, that keeps setup light. For repeatable jobs, the CLI is available as @pipic/cli on npm, and its client code is open source on GitHub. The CLI free tier allows 100 compressed images per month; Pro raises that limit to 5,000. Choose the route that fits your cadence, and account for the CLI quota before putting recurring work into a pipeline.
Process the JPG fallback and the WebP and AVIF assets as image files in their respective formats. Keep an untouched source copy until you have checked the results. Do not assume that a successful compression run proves the right file landed at the right path: inspect the outputs, confirm their format and compare the appearance at the size the page will display them.
Pay particular attention to gradients, fine textures and dark areas. A smaller file is not a win if the fallback looks visibly worse than the modern version. If the image is central to the page, check it on a real page layout rather than judging it only as a thumbnail. For a more focused AVIF review, the earlier guide to testing an AVIF hero against visual quality and mobile loading is useful background.
Keep all variants under one naming rule and record where each file belongs. That makes later replacements less error-prone: when the source image changes, update the whole family instead of swapping only the JPG or only the AVIF.
Offer the modern formats first and put the JPG in the nested image element. The browser can select a supported source; the image element remains the fallback path. For example:
<picture>
<source type='image/avif' srcset='/media/hero.avif'>
<source type='image/webp' srcset='/media/hero.webp'>
<img src='/media/hero.jpg' alt='A description of the scene'>
</picture>
Use an accurate text alternative, and keep the fallback URL pointed at the JPG you actually tested. If your site has responsive image sizes, extend the same naming and review discipline to each size rather than mixing a small modern asset with a large fallback by accident.
Before publishing, check that every path in the markup resolves and that each file is the intended variant. A small check in your existing build or review process can flag a missing JPG, WebP or AVIF file. Also inspect the rendered page in the browsers and devices your audience uses; markup alone cannot prove that the right image looks right in context.
The trade-off is straightforward. Maintaining three files adds storage, naming rules and review work. In return, visitors whose browsers support a modern source can use it, while the JPG remains available through the image element. A disciplined family of compressed assets is more dependable than treating a fallback as an afterthought. The useful target is not a format checklist; it is a complete, reviewed set where every URL works and the fallback remains acceptable.
Browser tools cut setup for occasional work; command-line tools fit repeatable pipelines, but they add engineering and quota decisions.
Regional demand is best measured against your own workloads; package audits and explicit batch limits still shape a safer compression pipeline.
AVIF is part of everyday delivery planning, but format choice, retention and batch size still need testing against a real workflow.