The complete guide to image compression in 2026.

Most image compression advice online is either hand-wavy ("just use a tool!") or buried in academic papers about DCT coefficients. This guide is the middle: enough detail to actually understand what's happening, few enough words that you can finish it in one coffee.

By the end, you'll know:

• Why your 4 MB hero image is actually 4 MB — and how to get it to 400 KB without anyone noticing
• When to use JPG, when PNG, when WebP, and when AVIF
• How quality settings actually work (spoiler: 80 is basically always right)
• Why batch-compressing matters, and how to do it without uploading sensitive images to random servers
• The two or three tools worth using, and which to skip

Let's go.

---

What "image compression" actually means

Every image on your screen is a grid of pixels, each with a color value. A 1920 × 1080 photo has 2,073,600 pixels. Stored naively — 4 bytes per pixel — that's an 8 MB file for every single image on a webpage. Obviously untenable.

Image compression solves this in two ways:

Lossless compression

Shrinks the file by finding patterns and encoding them more efficiently. The decompressed image is byte-identical to the original. PNG uses lossless compression. So does WebP, in lossless mode.

Lossy compression

Shrinks the file by throwing away information humans don't notice. JPG, WebP (lossy mode), and AVIF all use this. The key insight: your eyes don't care about fine color variations in complex areas (like a forest canopy) as much as they care about sharp edges (like text). Lossy formats exploit this.

---

Format by format — when to use what

JPG (or JPEG — same thing)

Best for: Photos, screenshots, complex images with lots of color gradients.

Invented in 1992. Yes, really. The format is ancient but it works. Every device and software supports it.

Pros: Universal compatibility. Good compression. Small file sizes.

Cons: No transparency support. Gets ugly at low quality (you'll see "mosquito noise" around edges). Doesn't handle sharp edges well — that's why JPG screenshots of text look slightly fuzzy.

When to default to it: Photos destined for email, older CMSs, image attachments. When in doubt and you just need it to work everywhere.

PNG

Best for: Logos, icons, UI screenshots, anything with transparency, anything with sharp edges.

Lossless, so it'll always look pixel-perfect. But file sizes can be huge — a simple gradient in PNG is often 10× the size of the same gradient in JPG.

Pros: Transparency. Perfect quality. Handles sharp edges beautifully.

Cons: Large files. Not ideal for photos.

When to default to it: Any image where transparency matters, or any image that contains text, UI, or hard edges.

WebP

Best for: Most things on a modern website.

Introduced by Google in 2010, universally supported since ~2020. At the same visual quality, WebP is 25–35% smaller than JPG for photos and often 25% smaller than PNG for graphics.

Pros: Small files. Supports transparency. Supports animation (rarely useful, but nice to have).

Cons: Still not universally accepted outside browsers — some email clients, legacy software, and print workflows choke on WebP.

When to default to it: Anything shipping to a modern website. This should be your default for 2026 unless you have a specific reason not to.

AVIF

Best for: The future, partially the present.

A newer format (2019) based on video codec technology. At the same visual quality, AVIF is ~20% smaller than WebP — so roughly 50% smaller than JPG.

Pros: Best compression available. Supports HDR. Transparency. Good for all image types.

Cons: Encoding is slow (noticeable when batch-processing). Browser support is good but not universal. Tooling is still catching up.

When to default to it: Not yet, in most cases. Use WebP for now and revisit AVIF in 2027 when encoder speed catches up and fallback workflows mature.

A decision tree, if you want it

When a more specific answer matters, the rest of this guide is about how to compress well, not which format to pick.

---

Understanding quality settings

Every lossy compressor has a "quality" slider that goes from something like 1 to 100. What does 80 actually mean?

It doesn't mean "80% of original quality." It's a knob that tells the encoder how aggressively to throw away information. Higher = less aggressive = larger file = closer to original. Lower = more aggressive = smaller file = more visible artifacts.

Here's a rough mental model (for JPG and WebP):

Quality	What it means	When to use
100	"Don't compress" (for JPG, this still isn't lossless)	Rarely worth the file size
90–95	Nearly invisible quality loss	Hero images, above-the-fold art
80–85	Visible only on direct comparison	Most web images — the sweet spot
70–75	Visible if you know what to look for	Thumbnails, non-critical images
60–65	Obvious on careful inspection	Only if size is paramount
<50	Visible artifacts for most viewers	Almost never

---

Batch compression — the workflow most people miss

If you're compressing one image, any tool works. If you're processing 50 product photos for a Shopify store, or 200 blog images during a migration, or 30 screenshots for a documentation update, you need a batch workflow.

Most free image compressors have a dirty secret: they cap free batch size. TinyPNG says "up to 20 images" on its free tier. Squoosh processes one at a time. Several other tools secretly upload your images to their servers for processing — which matters if your images contain sensitive info (screenshots of dashboards, photos with identifying details, etc.).

A good batch workflow should:

1. Process multiple files at once — at least 20–50
2. Run locally (in your browser, not on someone's server)
3. Apply the same settings to all files without manual per-file clicking
4. Let you download everything as a ZIP when done
5. Show before/after sizes so you can see what you saved
6. Strip EXIF metadata — photos from phones contain GPS, camera model, and timestamps you probably don't want public

Other good free options:

• Squoosh (by Google) — excellent for single-image fine-tuning, bad for batch
• TinyPNG — fine if you're only processing fewer than 20 files at a time and don't mind uploading to their servers
• ImageOptim (Mac only) — drag-and-drop desktop app, great if you're on Mac and want local processing

Tools to avoid for batch work: anything that requires an account to use, anything that shows ads between each compression, and browser extensions (they're usually slower and have worse UX than dedicated web tools).

---

Resize before you compress

This is the single biggest file-size win most people miss.

Your phone probably takes photos at 4032 × 3024 pixels. That's ~12 megapixels. A standard blog hero image is 1200 × 630. You're storing 16× more pixel data than anyone will ever see.

Compressing a 4032 × 3024 image from 8 MB to 800 KB feels great. But if you'd resized it to 1920 × 1440 first, then compressed, the same image would be ~200 KB — four times smaller than the "compressed" version, and no viewer would ever know.

Any resize-and-compress tool should let you set a max dimension. The Image Smusher does this with a segmented control (2560 / 1920 / 1280 / keep original).

---

Strip EXIF metadata

Every photo taken on a phone or modern camera includes EXIF metadata: GPS coordinates, camera model, focal length, timestamp, sometimes even the user's name.

This is fine (and often useful) on your own devices. But when you publish images on the web, EXIF can:

• Leak your location. A photo taken at home might contain your home's GPS coordinates.
• Identify your equipment and workflow (useful for some attackers, privacy issue for most people).
• Add 10–50 KB per image to file sizes unnecessarily.

Any good compressor should have a "strip metadata" toggle. The Image Smusher has it on by default — which is the right default for almost everyone.

Exception: If you're a professional photographer publishing portfolio work, you might want to keep EXIF to prove authenticity or preserve lens data. In that case, turn it off.

---

The fast-win checklist

If you're reading this because your site is slow, here's the 15-minute checklist that fixes most problems:

1. Audit your biggest images. Chrome DevTools → Network tab → filter to "Img" → sort by size. Anything over 500 KB is suspect.
2. Resize to actual display dimensions. That 4 MB hero image is probably being displayed at 1200px — resize it to 1920px max.
3. Re-compress at quality 80. Use a batch tool if you have more than 5 files.
4. Convert to WebP if your site's audience is modern browsers (>99% of public web traffic).
5. Strip EXIF on the way through.
6. Use <picture> tags to serve WebP with JPG fallback for legacy browsers:

<picture>
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="Hero image">
</picture>

Most sites see a 60–80% reduction in total image weight after doing this. Lighthouse scores jump 20+ points. Pages load noticeably faster.

---

The longer conversation

Image compression is a solved problem. The interesting conversation is what you do with the performance you save.

Every KB you shave off your images is a user who doesn't bounce on a 3G connection. Every hundred milliseconds you shave off Largest Contentful Paint is a higher Google ranking. Every photo you strip of EXIF is a privacy vulnerability you've closed for your users.

Doing this well isn't optimization for the sake of it. It's craft. Small decisions, compounded across hundreds of images, across thousands of page views, across years of a site's life.

Compress your images. Strip the metadata. Serve WebP. Your users will never thank you — they'll just come back more often.