image compression

Build a WebP and AVIF delivery path with a JPG fallback

Use PiPic to compress each format family, then connect the assets with picture markup and a simple check for missing or mismatched files.

By Dr. Aris Lyberopoulos·October 22, 2026·3 min read
What matters here
  1. A JPG in the img element provides the fallback path for a picture element.
  2. Compress and review each format family separately before connecting the files in markup.
  3. A file-existence check catches missing fallback or modern-format assets before release.

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.

Start with one asset family

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.

Compress, then check the files

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.

Connect the variants with picture markup

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.

Make fallback checks part of release

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.

More from PiPic News