How to Compress Images for the Web Without Losing Quality

Images are almost always the heaviest thing on a web page. On a typical site they make up well over half of the total bytes a visitor has to download — more than the HTML, CSS, JavaScript and fonts put together. So when a page feels slow, unoptimised images are usually the first place to look, and the easiest place to win.

The encouraging part is how much room there normally is. Taking a 4 MB photo straight off a phone down to 200–300 KB — a saving of more than 90% — with no difference a visitor would ever notice is completely routine. The trick isn't one magic setting; it's understanding what actually makes an image big and then applying three or four small decisions in the right order.

This guide walks through exactly that: how compression really works, which format to use and when, how far you can push quality before anyone notices, and a repeatable workflow you can run on every image before it goes live.

Why image weight is worth fixing

Every kilobyte you send has to cross a network and be decoded on the visitor's device. On a fast laptop that's invisible. On a mid-range phone over patchy mobile data — which is how a huge share of the web is actually browsed — it's the difference between a page that snaps into view and one that makes people wait.

Google measures this directly. Largest Contentful Paint (LCP), one of its Core Web Vitals, is usually triggered by the biggest image on the screen — your hero shot or a large product photo. If that image is a bloated 3 MB file, your LCP suffers, and Core Web Vitals are a genuine ranking signal. Slow images don't just irritate people; they quietly cost you search visibility and conversions. We cover the wider performance picture in our technical SEO checklist.

There's a direct bandwidth cost too. If your images are four times larger than they need to be, you pay for four times the CDN traffic — and visitors on metered data plans pay as well.

Lossy versus lossless: the idea that explains the rest

Nearly every decision about image compression comes back to a single distinction.

Lossless compression shrinks a file without discarding any data — decompress it and you get the exact original back, pixel for pixel. It's how PNG works. The catch is that there's a firm limit on how much you can squeeze out when you're not allowed to throw anything away.

Lossy compression is more aggressive: it permanently removes information the eye is unlikely to miss — subtle colour shifts, fine detail in busy areas — to reach dramatically smaller files. JPEG is the classic example. Done well, a lossy image looks identical to the original at a fraction of the size. Pushed too far, you get the tell-tale blocky artefacts around edges and banding across smooth gradients.

The rule that falls out of this is simple: use lossy compression for photographs and rich imagery, and lossless for graphics with hard edges and flat colour — logos, icons, screenshots, diagrams, anything containing text.

The four formats you'll actually use

You'll see a dozen formats mentioned online, but for the web in 2026 four of them matter.

Which format should you actually pick?

Here is the decision that covers most cases, in order of preference:

• Photographs: reach for WebP or AVIF first. Both beat JPEG comfortably on size at the same visual quality. Keep a JPEG fallback only if you must support very old software.
• Logos, icons and flat graphics: PNG when you need crisp edges and transparency, or WebP in its lossless mode for the same result at a smaller size.
• Screenshots: PNG for interface shots with text, since lossy formats blur small type. If the screenshot is mostly a photo, WebP is fine.
• Anything needing transparency: PNG, WebP or AVIF — never JPEG, which has no alpha channel and will fill transparent areas with solid colour.
• Simple animations: WebP or AVIF instead of the ancient GIF format, which produces enormous files for what it does.

How far can you push the quality?

Most tools express lossy compression as a quality value from 0 to 100. It's tempting to assume you need 90 or higher, but that's rarely true. The relationship between quality and file size is steeply diminishing: dropping from 100 to around 80 can halve the file with no perceptible change, while the last few points from 80 to 100 add a lot of weight for detail almost nobody can see.

For most web photography, a quality setting between 75 and 82 is the sweet spot — big savings, no visible loss. Go lower only for thumbnails and background images where fine detail doesn't matter. The honest way to choose is to compress, then look: view the result at the size it will actually appear on the page, not zoomed to 400%.

The workflow: four steps, every time

Optimising an image well is less about one clever setting and more about doing a few things in the right order.

1. 1Resize to the largest size it will ever display. A 4000-pixel-wide photo shown in a 600-pixel column wastes roughly 85% of its data before compression even starts. Resize first — it's the single biggest win.
2. 2Choose the format that matches the content. Photo or graphic? Transparency or not? That decision, from the section above, often matters more than the quality slider.
3. 3Compress at quality 75–82 and compare. Nudge the slider, view the result at real display size, and stop the moment you can see a difference — then step back up one notch.
4. 4Export a modern format. Save a WebP or AVIF version for the browsers that support it, keeping a JPEG or PNG as the fallback.

You can run every one of these steps for free, right in your browser — nothing you upload leaves your device:

The Image Compressor above batch-processes JPG, PNG and WebP with a live quality slider and a before/after size readout, so you can see exactly what each setting costs. When you need to change format — including HEIC photos straight off an iPhone — the Image Converter turns them into JPG, PNG, WebP or AVIF in a couple of clicks.

Resize first — the win almost everyone skips

This point is worth labouring because it wastes the most bytes. Modern phone cameras shoot photos around 4000 pixels wide. A blog body column is rarely more than 700 pixels wide; a product thumbnail might be 300. Serving the full-resolution file into that space forces the browser to download millions of pixels it will only throw away when it scales the image down.

A good rule is to resize to no more than twice the maximum size the image will display — that covers high-density "Retina" screens — and no larger. Our Image Resizer sets exact pixel dimensions in seconds, the Social Media Image Resizer has ready-made presets for Instagram, YouTube, LinkedIn and the rest, and if you're working to a specific ratio the Aspect Ratio Calculator does the arithmetic for you.

Serve modern formats without breaking older browsers

The one hesitation people have about WebP and AVIF is browser support. In practice both work across every current browser, but if you need to cover older ones, the <picture> element lets you offer modern formats with a graceful fallback. The browser picks the first source it understands:

<picture>
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="Team celebrating a product launch"
       width="1200" height="630" loading="lazy">
</picture>

A browser that understands AVIF loads the AVIF; one that only knows WebP takes that; anything older falls back to the JPEG. Note the width and height attributes — they let the browser reserve space before the image arrives, which prevents layout shift (the CLS in Core Web Vitals) — and loading="lazy" defers off-screen images until they're actually needed.

Common mistakes that quietly bloat pages

• Saving photos as PNG. PNG is lossless, so a photograph saved as PNG can be five to ten times larger than the same image as a well-compressed JPEG or WebP. Reserve PNG for graphics.
• Skipping the resize step. Compression alone can't fix an image that is simply too many pixels. Always resize to display size first.
• Re-compressing an already-compressed image. Every lossy save throws away more detail. Keep a high-quality master and export from that, rather than re-saving the same JPEG over and over.
• Forgetting descriptive alt text. It doesn't affect file size, but it's essential for accessibility and image search — and it costs nothing to add.
• Shipping one giant hero image to phones. The image that looks great on a desktop banner is usually far too large for a phone. Serve appropriately sized versions to each.

A quick word on privacy

Many free "compress image online" sites work by uploading your files to their servers, processing them there, and sending them back. For a holiday snapshot that may not matter, but for product mock-ups, client work, screenshots of internal tools, or anything with personal information in it, you're handing your images to a third party you know nothing about.

Every image tool on motifuse runs locally in your browser, using the built-in Canvas and WebAssembly APIs. Your files are read, resized, compressed and converted on your own device and never uploaded anywhere — which is faster, keeps working offline once the page has loaded, and keeps private images private.

Frequently asked questions

The bottom line

Fast-loading images are one of the highest-leverage improvements you can make to a website: better Core Web Vitals, stronger rankings, lower bandwidth bills, and visitors who actually stay. The recipe is refreshingly consistent — resize to display size, match the format to the content, compress to around quality 80, and serve a modern format with a fallback.

None of it needs expensive software. Start with the Image Compressor to shrink what you already have, use the Image Converter to move to WebP or AVIF, and resize before you compress. Do that consistently and most sites can cut their image weight by well over half without a single visitor noticing a drop in quality — which is exactly the point.