How to Compress Images on Mac: Every Method Compared

macOS ships with two ways to shrink images, and both are worth knowing even if you outgrow them.

Preview can resize and re-export: open an image, choose File → Export, pick JPEG, and drag the quality slider. It works for one-off jobs, but it re-encodes with dated settings, strips no metadata by default, can’t batch beyond crude multi-select exports, and has no idea what WebP or AVIF are for output.

sips, the command-line scriptable image processing system, can batch resize and convert (sips -Z 1600 *.[jJ][pP][gG]). It’s free and already installed — but it exposes almost none of the encoder controls that matter, produces larger files than modern encoders at the same visual quality, and requires you to be comfortable in Terminal.

If you compress images once a month, Preview is fine. If images are part of your actual work, the built-ins leave quality-per-byte on the table. In our benchmark, Apple’s AVIF encoder needed 18 to 26% more bytes than Smol’s for the same quality score, and its JPEG encoder 2 to 12% more at web quality.

Lossless compression repacks the same pixels into fewer bytes — nothing is discarded. How much that saves depends on the picture: about a third to a half on flat graphics such as screenshots and logos in our tests, and only a few percent on photographs. It’s the right choice for screenshots with text, UI assets, and logos.

Lossy compression discards information your eye is bad at noticing — fine noise in shadows, subtle color gradients in busy areas. Done well, a photo can lose 85% of its bytes before anyone can tell in a blind test. Done badly, you get smeared detail and blocky skies.

The practical rule: photos want lossy, graphics want lossless. The quality slider isn’t a “damage” dial — between roughly 70 and 85 on a modern encoder, differences are invisible at normal viewing sizes while file size drops steeply. Below ~60 you start trading visible quality for diminishing savings.

This is also why the free app most people try first disappoints on photos. ImageOptim is lossless by default, and on 24 test photographs it made the JPEGs 8.9% smaller and the PNGs 4.3% smaller. It has a lossy mode in Preferences, which does most of the work on a JPEG, but it cannot change format: from the same photos, Smol’s AVIF needed 20 to 22% fewer bytes than ImageOptim’s lossy JPEG at the same quality score. The full comparison is on our ImageOptim alternative page. For graphics that must stay pixel-identical, ImageOptim is still the right free tool.

Format choice moves file size more than any quality slider. As of 2026 the decision tree is short:

AVIF is the best image format available today. In our benchmark it was 22 to 26% smaller than JPEG at the same SSIMULACRA2 quality score, and it has support in every major browser. If you’re optimizing a website or shipping assets where you control the viewer, AVIF is the right default.

WebP sits in the middle: ~25–35% smaller than JPEG, universally supported for years, and safer than AVIF when files pass through older tools, CMSs, or clients’ hands.

JPEG remains the compatibility king. Every device, app, and grandmother’s email client opens it. A well-encoded JPEG (a modern encoder, quality ~80) is still a perfectly respectable deliverable.

HEIC — your iPhone’s default — is great inside Apple’s ecosystem and a headache outside it. For sharing, convert HEIC to JPEG or AVIF first.

TinyPNG, iLoveIMG, Squoosh and dozens of similar sites will compress images in the browser, and for a single small file on someone else’s computer they’re genuinely handy. Their trade-offs show up with real workloads:

1. Upload limits and quotas. Free tiers cap file size (TinyPNG: 5 MB per image) and batch counts — exactly the files that need compression most are the ones that get rejected.

2. Your files leave your machine. Client work under NDA, unreleased product shots, family photos with GPS metadata — all uploaded to a third-party server you don’t control, processed under a privacy policy you probably haven’t read.

3. Round-trip time. Upload, queue, process, download — for a folder of 50 MB of images on ordinary broadband, minutes instead of seconds. Native local encoders on Apple Silicon and Intel Macs are dramatically faster than an upload loop.

Smol is our answer to all of the above — a Mac app that compresses and converts JPEG, AVIF, WebP and PNG entirely on your Mac. The workflow is deliberately boring:

1. Drop images onto the menu-bar icon or the window — JPEG, PNG, WebP, AVIF, HEIC, or RAW, individually or as folders.
2. Pick an output format (or keep the original) and a quality preset.
3. Done. Files typically come out 50–90% smaller, and Smol always keeps the smaller result — if compression would grow a file, it keeps your original.

The interesting part is Neural compression: before encoding, Smol maps faces, text, edges, and fine detail in the image, then protects those regions while compressing low-detail areas (skies, smooth backgrounds, shadows) harder. You get the small file of aggressive compression with the sharp subject of conservative compression — that’s the difference between an encoder that treats every pixel equally and one that knows what a face is.

Because everything runs locally on your Mac, there is no 5 MB cap, no daily quota, no account, and nothing ever uploads. A 4 GB folder is as fair game as a single screenshot.

The moment you’re compressing more than a handful of images, per-file workflows collapse. Whatever tool you use, look for three things: recursive folder support, per-file results (so one bad input doesn’t sink the run), and the ability to re-process individual files at different settings afterward.

In Smol, batch is the default mental model: drag in a folder of 500+ mixed files — images, PDFs, and videos together — and it processes everything with per-file progress and savings. Virtual scrolling keeps the UI responsive past 1,000 files, and you can cancel mid-batch or re-optimize outliers when the run finishes.

If the destination is a website, compression is half the job — the other half is not shipping more pixels than the layout renders. A hero image displayed at 1,600 px wide doesn’t need a 6,000 px original behind it.

A dependable recipe for 2026: resize to at most 2× the largest rendered width, encode as AVIF around quality 60–70 (with a WebP or JPEG fallback if your stack wants one), strip metadata, and set explicit width/height attributes so the page doesn’t shift while loading. Hero images at web sizes should land well under 200 KB — often under 100 KB in AVIF — which is the difference between passing and failing LCP on a median mobile connection.

Every photo carries EXIF data — camera model, timestamps, editing software, and very often precise GPS coordinates of where it was taken. Compressing a file does not necessarily remove any of that.

Before images go anywhere public, strip the metadata. In Smol, enable Strip metadata and every EXIF, GPS, IPTC, and XMP field is removed — and because it can strip without recompressing, the pixels stay untouched while the identifying information disappears. It’s a one-checkbox habit that has saved a lot of people from publishing their home address inside a JPEG.