Compressing images for the web
— the complete 2026 guide

How to compress images so your website loads faster, eats less bandwidth, ranks better on Google — and still stays sharp. With concrete numbers, format recommendations, a tool comparison, and a step-by-step workflow.

By Jonathan Hedderich · Published: May 31, 2026 · Updated: June 21, 2026 · ~22 min read

Why image compression matters more than ever in 2026

Images today make up roughly 50% of the average page weight — a median of 880 KB per page according to the HTTP Archive Web Almanac, and that's only the median. On e-commerce platforms the figure is often two to four megabytes for product photos alone. Fail to actively compress here and you give away three things at once: speed, money, and visibility.

Speed, because the image is the longest journey from server to device. On a 4G mobile connection at 10 Mbit/s, an 800 KB hero image loads in 600 to 1500 milliseconds — and during that time it blocks the Largest Contentful Paint (LCP), the most important Core Web Vitals signal. An equivalent-looking WebP at 180 KB is there in 130 ms. That's not a little faster. That's a different league.

Money, because bandwidth costs money. On Vercel, Cloudflare, AWS, or any CDN, egress is billed per gigabyte. A site with 100,000 pageviews a month, 2 MB of image weight each, generates 200 GB of traffic — that's between 8 and 40 euros a month for images alone, depending on the provider. Sensible compression cuts that to a fraction.

Visibility, because since the Page Experience Update (May 2021) and the full migration to Core Web Vitals (March 2024), Google officially factors load speed into ranking. A slow LCP won't drop you from the index, but it pushes your position down a few places — and in a competition where the top-3 results take over 60% of all clicks, that's relevant. More background in our Core Web Vitals post.

What happens during compression — the mechanics in 4 minutes

To make the right decisions, a quick look at the theory helps. Image compression comes in two variants: lossless and lossy. With lossless compression the image is reconstructed byte-exact; only the storage is made more efficient by clever algorithms (Deflate, LZ77, Huffman). PNG works this way, as do WebP-lossless and FLIF/JPEG-LS in specialized applications.

Lossy compression uses psychovisual models: it deliberately discards information the human eye perceives poorly anyway. JPG, WebP-lossy and AVIF split the image into 8×8-pixel blocks (DCT for JPG, transform blocks for AV1) and quantize the high-frequency components we're insensitive to. Anyone who has ever zoomed into a heavily compressed JPG sees the result: the typical 8×8 block boundaries and the "mosquito noise" at sharp edges.

The trick is to push quantization just far enough that the file gets small but the eye still can't see the artifacts. Where that sweet spot lies depends on the format — and is the most important practical question, which we'll answer next.

The 2026 formats compared head to head

Six formats are relevant for the web in 2026. Here's the key rule of thumb at a glance:

For deeper format detail, see our specialized guides: AVIF explained, WebP guide, JPG vs PNG, PNG vs WebP and the big image-format comparison.

The quality sweet spots — numbers you can remember

The standard recommendation "quality 80" dates from the 1990s and applied to classic JPG. Today, with modern encoders and better formats, the sweet spots are more finely tuned. From countless A/B tests on photo, graphic, and screenshot material, the following crystallizes:

• JPG (mozjpeg encoder) — sweet spot between 75 and 82. Below 65 visible artifacts, above 88 only marginally larger files with no visible quality gain. Default recommendation: 78 for hero images, 72 for thumbnails.
• WebP (lossy) — sweet spot at 70–80. WebP tolerates lower quality values better than JPG because its quantization layer is finer. Default: 75 for web photos.
• AVIF — sweet spot at 50–65. AVIF needs surprisingly low quality values for equivalent results. Default: 55 for standard photos, 65 for skin tones and faces (especially prone to banding artifacts).
• PNG (lossless) — quality isn't scaled here; instead optimization: run palette reduction (256 → 64 colors), remove unused chunks, use an encoder like pngquant (lossy) or oxipng (lossless).

Follow these values slavishly and you make no visible mistakes in 95% of cases. When compressing skin tones, gradients, or fine hatching, move up the scale by 5 — that content is more susceptible to quantization artifacts.

How to find quality sweet spots in the multi-format comparison

Instead of guessing, you can determine the sweet spot empirically. Load a representative image into the JNRT Pixel multi-format comparison — it renders the same image simultaneously in JPG, PNG, WebP and AVIF at the chosen quality. Next to it you see the resulting file size in a mono-font display. That way you compare in one minute what would otherwise take ten tool switches.

In the detail view you can then compare pixel-precise: slider, side-by-side, 1:1 zoom — and decide whether the quality value still fits or whether you can reduce further. If your eyes can't see the difference at quality 75, quality 80 is wasted storage.

Tool comparison: what the major compression services really do in 2026

There are roughly three classes of online compressors. Here I compare the five best-known representatives on privacy, format support, quality, and cost.

The structural distinction: local tools (JNRT Pixel, Squoosh) process the image in your browser and send nothing up — privacy-friendly, fast, suitable even for confidential content like family photos, patient scans, product renders. Cloud tools (TinyPNG, ShortPixel, iLoveIMG) need an upload — usually faster for very large batches, but with a privacy trade-off and account mechanics.

If you regularly compress large volumes identically (a newsletter send, say), you can combine the local approach with a browser PWA install. More on that below.

Step by step: compressing images for a WordPress site

Example workflow for a realistic task: you run a travel blog and have 30 holiday photos to embed in a new post. The goal: web-optimized in under ten minutes.

1. Filter your selection. Twelve good photos beat 30 mediocre ones — compression is no substitute for curation.
2. Back up the originals. Put a copy of the originals in a cloud folder. Compression is lossy — you want to keep the source.
3. Set the maximum output width. On a standard WordPress site with a 1100 px container, you need no hero images wider than 2200 px (retina factor 2). Scale anything above that in the resizer.
4. Open multi-format. Drag and drop all 12 images into the multi-format comparison.
5. Set quality. To 75 (for JPG/WebP); the sticky settings bar at the bottom of the screen applies it to all images at once.
6. Pick the best format per image. The "optimal summary" automatically shows the smallest format per file. For skin tones it's usually AVIF; for few colors and hard edges WebP; for logos PNG.
7. Set a filename affix. With prefix 2026-italy- and suffix -web all downloads get consistent names.
8. Download the ZIP. One click, all 12 images bundled as WebP or AVIF.
9. Upload to WordPress. WordPress 6+ recognizes WebP automatically; AVIF currently still needs the WebP Express or EWWW plugin as a fallback. Tip: also provide a JPG fallback for browsers without AVIF support, ideally via a <picture> tag.

More detail on WordPress images in our dedicated post: Optimizing images for WordPress.

Responsive images — srcset & <picture>

Compression is one half. The other half is delivering the right size to the right device. A 2400 px hero on a 360 px iPhone display is wasted bandwidth, no matter how well compressed. The solution is srcset:

<img
  src="/img/hero-1200.jpg"
  srcset="
    /img/hero-480.webp  480w,
    /img/hero-800.webp  800w,
    /img/hero-1200.webp 1200w,
    /img/hero-1800.webp 1800w
  "
  sizes="(max-width: 600px) 90vw, 1100px"
  alt="..."
  loading="lazy"
  decoding="async"
/>

The browser picks the right image based on display pixel density and viewport width. Go one step further and combine it with <picture> to serve AVIF for modern browsers plus WebP and JPG fallbacks:

<picture>
  <source type="image/avif" srcset="/img/hero-1200.avif 1200w, ..." />
  <source type="image/webp" srcset="/img/hero-1200.webp 1200w, ..." />
  <img src="/img/hero-1200.jpg" alt="..." loading="lazy" />
</picture>

So iOS Safari users get AVIF, Android Chrome likewise AVIF, a Firefox user on an 8-year-old laptop gets the WebP, and a theoretical Internet Explorer user (there are none left) would get the JPG. The art direction is solved elegantly because the browser picks the optimal match itself.

Lazy loading — the often-forgotten multiplier

Even the best compression is useless if all 30 images load in parallel on the first page view. The attribute loading="lazy" ensures only images in the viewport download immediately — everything below the first screen edge loads only on scroll. This is natively supported today; no polyfill needed anymore.

Important: the hero image above the fold should explicitly not be lazy-loaded — that would be counterproductive for the LCP. Instead: loading="eager" on the hero, loading="lazy" on everything below the first pixels.

Common beginner mistakes — and how to avoid them

From several audits of typical mid-size-business sites, five mistakes emerge that in combination explain 80% of image-weight problems:

1. 4000×3000 px original in a 600 px slot. The CMS displays the image "only 600 px wide" but loads the original. Solution: always scale to realistic maximum dimensions on upload.
2. PNG for photos. PNG is brilliant for logos and pixel graphics — for photos it's 4–8× larger than JPG at identical perception. Rule: PNG only for transparency or < 16 colors.
3. Quality 95+. The extra bytes above quality 90 are invisible but expensive. 78 is enough for 99% of use cases.
4. EXIF/XMP metadata. A modern smartphone camera packs 50–200 KB of metadata into every photo — GPS, lens model, edit history. It has no place in web output. The EXIF editor removes it in one click.
5. No modern formats. "WebP doesn't work in old browsers" — no longer true. WebP has been supported by all evergreen browsers since 2020, AVIF since 2023. Serve pure JPG in 2026 and you leave 30% performance on the table.

Best practices by use case

E-commerce product photos

Here detail perception is critical — nobody buys a fabric whose texture looks blurry. Recommendation: WebP at quality 80, with srcset variants of 320, 640, 960, 1280 px width, plus a 2400 px variant for zoom. Also offer AVIF if your shop system supports it. More in the e-commerce image guide.

Blog articles

Inline images in body text are rarely business-critical for detail perception. Here you can compress more aggressively: WebP at 72, AVIF at 55, maximum output width 1200 px for a typical content layout. Treat hero images like product photos.

Landing pages

Here the first impression counts — and with it the LCP. Hero image as AVIF + WebP fallback, prepared in two sizes for mobile and desktop. Set fetchpriority="high" on the hero so the browser loads it with priority. Lazy-load CSS background images with an IntersectionObserver if they aren't visible right at the top.

Social media previews (Open Graph)

Here you need JPG (Facebook), not WebP — Meta's tools still can't reliably read WebP. Recommendation: 1200×630 px, JPG at quality 85, no compression artifacts. See our social media sizes tool.

Build automation — when you really want to scale

Browser tools like JNRT Pixel are perfect for ad-hoc compression or smaller batches. If you maintain a site with hundreds of images, you'll want to automate. Three proven routes:

• Next.js / Astro / SvelteKit image components. Generate AVIF/WebP automatically at build time, with responsive srcset out of the box. Recommended for modern static-site stacks.
• Sharp / libvips in Node.js. The library behind most build tools. Callable directly in a build script, very performant — a photo-processing pipeline standard.
• Cloud CDNs with on-the-fly transformation. Cloudflare Images, Imgix, Cloudinary, Vercel Image Optimization — send the original once, the CDN does the rest. Handy for CMS-driven sites, but paid.

Verification: is my compression working?

Three free tools to validate:

• Google PageSpeed Insights — tests your LCP, gives a rating and concrete recommendations. Mobile and desktop separately.
• Lighthouse in Chrome DevTools — the same audit locally, without your URL needing to be publicly reachable. Handy for staging tests.
• WebPageTest.org — the classic, with a filmstrip visualization of the load. Shows you frame by frame how your page builds. Essential when you want to prove a specific optimization worked.

If your LCP is under 2.5 seconds, you're in the green. Between 2.5 and 4.0 seconds "needs improvement", over 4 seconds "poor" — and Google penalizes that in ranking.

Practical workflow recommendation

If you want to start right after this article, here's the fastest path to a noticeably faster site:

1. Identify the 5 largest images on your homepage (DevTools → Network → sort by size).
2. Load all 5 into the JNRT Pixel multi-format comparison.
3. Pick the best format per image from the optimal summary.
4. Download the ZIP, replace the originals on the site.
5. Measure the LCP before and after with Lighthouse — the difference is usually striking.

These five steps typically achieve between 30 and 70 percent weight reduction on the average mid-size-business site. That's half a workday of effort for a performance gain that would otherwise only come from a bigger hosting change or a theme refactor.

Conclusion & next steps

Image compression in 2026 is no black magic. With the three tools from this article — modern formats (WebP, AVIF), smart quality sweet spots (75, 55), and browser-local processing — you achieve in half a day what a decade ago took a dedicated build server a week. And all without upload, cloud account, or subscription.

Read next: our AVIF deep dive or the WebP guide. If you want to start right away, jump straight into the multi-format comparison.