Compress images for web, a Mac developer's 2026 workflow

Web pages should not ship 8MB hero images. In 2026 we have three formats that beat JPEG by 25 to 77 percent, and most browsers ship every one of them. Here is the workflow that a small handful of Mac developers, photographers, and designers are settling on.

The decision tree

• Photograph going on a website? AVIF or WebP, quality 80.
• Photograph for an archive? JPEG XL lossless transcode.
• Screenshot or UI mock? PNG via pngquant.
• Image with transparency for web? WebP lossless.
• One file that has to work everywhere? JPEG via jpegli, quality 85.

That covers maybe 95 percent of the images a typical web project needs. The rest of this post walks through the workflow that turns this tree into a routine you can run in about a minute and a half.

The 90-second routine

Pick a folder of source images. Whatever the camera, screenshot tool, or designer hands you. The routine is the same:

1. Drag the folder into a batch compressor.
2. Pick the format and quality from the tree above.
3. Hit start, wait for the progress bar.
4. Drag the output folder into your project’s public/ or assets/ directory.
5. Spot-check one image visually at 100 percent zoom.

Steps 1 through 3 take about 60 seconds for a batch of 20 images on an M-series Mac. Steps 4 and 5 take about 30. That is the whole loop.

The trick is having the compressor open and configured. Every workflow that takes longer than this is the same five steps wrapped in friction: hunting for a CLI flag, uploading to a browser tool one image at a time, or fighting a desktop app that wants you to pick a format for each file individually.

A worked example

Say a photographer sends you 20 JPEGs from a product shoot. Each one is about 4 MB out of the camera. You need them on a marketing page that already loads slowly on mobile.

The decision tree says: photographs going on a website, AVIF or WebP, quality 80.

Drag the folder in. Pick AVIF, quality 80. Start. About 90 seconds later you have 20 AVIF files averaging around 600 KB each. Total page weight drops from 80 MB to 12 MB, an 85 percent reduction. The photographs look identical to a human eye at any reasonable zoom level.

If you want a JPEG fallback for old browsers, run the same source folder again with jpegli, quality 85. You now have two output folders, one with AVIF and one with JPEG. Wire up the HTML:

<picture>
  <source srcset="/photos/hero.avif" type="image/avif">
  <img src="/photos/hero.jpg" alt="Product hero shot" loading="lazy">
</picture>

The browser picks AVIF if it can. Old browsers fall back to JPEG. The page is now 85 percent smaller for the 99 percent of visitors on a modern browser.

Quality settings, in plain language

You will see two sliders in any compressor that takes the format choice seriously. Quality and effort. They do different things.

Quality controls the trade-off between file size and visual fidelity. 100 is lossless. 0 is incoherent. The sweet spot for photographs is usually 75 to 85. Below 70 you start to see artifacts on smooth gradients. Above 90 the file size jumps without much visible benefit. For web work, stick to 80 unless you have a reason to move.

Effort controls how long the encoder spends searching for the smallest file at the chosen quality. Higher effort means smaller file, longer encode. For a one-off image, max effort and walk away. For a batch of a hundred, the default mid-effort setting is usually right.

The thing to avoid is treating quality and effort as the same dial. Bumping effort never makes the image look worse, only smaller. Bumping quality always makes the image both bigger and better.

Batch versus single image

Two modes show up in every workflow.

Batch mode is for the common case. A folder of photos, a uniform format choice, hit start. You want a tool that handles this without making you click through each file.

Single image mode is for the special case. A hero image that has to look perfect, a screenshot you want to tune by hand, a transparent logo where the wrong setting kills the alpha channel. For these you want a tool that shows you the output preview next to the original at the quality you picked.

Most Mac compressors do one mode well and the other poorly. The ones worth installing do both.

Verifying the result

Open the output folder. Pick one image. Zoom to 100 percent in Preview. Compare against the original at the same zoom level.

Look for: blocky edges around text, banding in smooth skies, color shifts on saturated reds and greens, lost detail in shadows. If you cannot see a difference, the quality setting was right. If you see any of the artifacts above, bump quality up by 5 and re-encode.

For batch workflows, spot-check three images. The first, a middle one, and one with content the encoder will find hard. Hard content means lots of fine detail, sharp text, or saturated highlights.

The pitfalls

Color profile loss. Camera files often ship with embedded ICC profiles. Cheap compressors strip them. Your photo looks slightly washed out compared to the original. The fix is a compressor that preserves the profile through encoding.

EXIF preservation. If the image is going on the web you probably want EXIF stripped for privacy. If the image is going to an archive you probably want EXIF kept. Pick the right setting per workflow.

Transparency handling. AVIF supports alpha. WebP supports alpha. JPEG does not. If you compress a PNG with transparency as JPEG, the alpha is gone. Some compressors warn you. Many do not.

Animations. WebP and AVIF both support animated images. GIF is enormous by comparison. If you ship animations, the conversion is worth doing once and never thinking about again.

How Sqz fits

Sqz is the app I work on. It is on the Mac App Store at $14.99 once, supports every format the decision tree mentions, runs locally, and includes the lossless JPEG to JPEG XL path that no other App Store app offers. It is one of several Mac tools that handle this workflow. The point of the post is not to sell the tool, it is to make the workflow itself unambiguous so that any compressor you pick produces the right output.

The format is the last decision, not the first one. The first decision is to stop shipping 8 MB hero images.