Image Compressor topic guide

How to optimize images for the web

Direct answer

Optimizing an image for the web is a four-step decision chain, not a single slider. Pick the format that matches the content (JPEG for photos, PNG for graphics, WebP or AVIF for the smallest file), resize to the actual display size including the 2x retina slot, re-encode at a balanced quality default, and serve the result with a modern-format fallback. The two Lighthouse audits that map directly to this chain are Properly size images and Efficiently encode images — Chrome for Developers publishes both and PageSpeed Insights runs them against every page it audits.

Try the Image Compressor

What this workflow handles

Each step addresses a different part of the payload problem. The format choice has the biggest single effect on bytes: switching a photograph from PNG to JPEG usually shrinks the file by 60 to 80 percent at quality 80, and switching the JPEG to WebP usually saves another 25 to 35 percent at the same visual quality per Google's WebP documentation. Resizing addresses a separate problem: a 4000 by 3000 source served in a 400 by 300 slot carries about 100 times more pixel data than the slot needs, and Properly size images flags exactly this case. Re-encoding at a balanced quality (JPEG quality 80, WebP quality 80 to 85) is the third lever — the difference between quality 60 and quality 95 is often a 5x file-size multiplier. Serving a WebP or AVIF copy alongside the original JPEG or PNG, through a <picture> element, is the fourth lever and the one web.dev recommends for any site that has modern browsers in its audience. The references for each step — web.dev's image optimization guides, Chrome for Developers Lighthouse audits, MDN's format guide, and the Pillow encoder documentation — are listed in the Sources block below.

Use the image compressor to re-encode a single image in its original format at the same pixel dimensions, then compare the byte counts in the result panel before keeping the output.

How to use it

  1. Open the source image and identify what it is — a photograph, a screenshot, a logo, a UI graphic, or a product shot.
  2. Pick the format that matches the content: JPEG or WebP for a photograph without transparency; PNG for a graphic with sharp edges or transparency; WebP lossy for the smallest file on a website; AVIF for the smallest file on a hero photograph.
  3. Resize the image to the actual display size including the 2x retina slot. The Image Compressor here keeps the source dimensions, so use a resizer first if the source is larger than the destination.
  4. If the destination enforces a different aspect ratio than the source (Amazon 1:1, Etsy 4:3, YouTube 16:9), pick the right fit operation — crop for feed cards that need to fill the slot, letterbox for marketplace main images that need the whole product visible. See the Crop vs Resize guide for the full decision.
  5. Re-encode at a balanced quality default — JPEG quality 80, WebP quality 80 to 85, PNG optimize-on. The Image Compressor applies these defaults in the source format; the WebP Converter produces a WebP copy at quality 85.
  6. Serve the modern format in a <picture> element with a JPEG or PNG <source> as fallback so older browsers still get a viewable file. The WebP vs JPEG guide covers the fallback pattern in detail.
  7. Mark images below the fold with loading='lazy' and provide width and height attributes on every <img> element so the browser can reserve layout space before the image loads.

Common mistakes

  • Uploading a 4000 by 3000 source and letting the browser scale it down with CSS. The browser still downloads all 4000 by 3000 pixels; the displayed size is unrelated to the bytes shipped. Chrome for Developers' Properly size images Lighthouse audit flags exactly this case — the cure is to resize to the actual display slot (plus the 2x retina slot) before encoding, not to rely on the browser to scale the served file.
  • Re-encoding an already-optimised source at the same quality. A JPEG exported from a camera at quality 80 has already been squeezed as far as the format allows; a second encode at the same quality produces a file of similar size. The result is not a smaller file — it is an extra encode step that costs time and may introduce a second round of lossy artefacts. The Image Compressor and WebP Converter both report the source and output byte counts in the result panel so the actual saving is visible.
  • Picking the wrong format for the content type. A photograph saved as PNG (or a screenshot saved as JPEG) is usually several times larger than the same image in the right format. PNG is lossless and keeps every pixel exactly, which is the right choice for sharp edges and transparency but is wasted bytes on a photograph where JPEG's lossy compression is invisible at quality 75 and above. The JPEG vs PNG and WebP vs JPEG guides cover the format decision in detail.
  • Forgetting width and height on the <img> element. Without width and height the browser cannot reserve layout space before the file loads, so the page jumps as each image arrives and hurts Cumulative Layout Shift and Largest Contentful Paint. The WHATWG HTML Living Standard describes width and height as the mechanism browsers use to compute the aspect ratio for layout before the image bytes arrive. Always set both, even when the actual file served is a different size from the attribute values.

Check the output

After running the workflow, verify these four things on the actual file before you upload it anywhere.

  • Dimensions. Confirm the final width and height match the actual display slot, including the 2x retina slot for web pages or the documented canvas for a marketplace listing. A 4000 by 3000 source served in a 400 by 300 slot is wasted bytes; a 2000 by 2000 Amazon main image is correct.
  • File size. Confirm the file is at or below the destination's documented limit and below the size you actually need. PageSpeed Insights' Efficiently encode images audit flags images that could save roughly 4 KiB or more by a more efficient encoder; the byte counts in the Image Compressor and WebP Converter result panels let you check the saving against the source.
  • Visual quality. Open the actual output at the display size and look for: sharp text edges (no fuzzy outlines from JPEG block artefacts), correct colour (no banding in sky / gradient regions), intact transparency (no white halos around transparent edges), and intact fine detail (no smearing of hair, fabric texture or small UI elements). If any of these show, drop to a lower compression level or switch format.
  • Real destination. Upload the final file to the actual destination — the page, the product listing, the social post — and view it there. Browser preview, design tool preview and the live page can render colour, transparency and layout differently; the live page is the only check that catches all of them at once.

Frequently asked questions

What does it mean to optimize an image for the web?

It means producing the smallest file that still looks correct at the actual display size and that the destination can decode. Optimization is the combination of four decisions: which format the file is saved as, how many pixels the file contains, what quality the encoder runs at, and how the file is served (with or without a modern-format fallback). web.dev's image optimization guides describe the same four steps in their canonical 'Serve images in modern formats' and 'Use responsive images' articles.

What is the best image format for websites in 2026?

It depends on the content. JPEG for photographs without transparency, PNG for graphics with sharp edges or transparency, WebP for a smaller file at the same visual quality on any modern browser (Chrome, Firefox, Edge, Safari since version 14 in 2020), and AVIF for the smallest file on a hero photograph or high-detail image where encoding time is not a constraint. web.dev recommends WebP and AVIF for web performance work, and MDN's compatibility tables confirm that every modern major browser decodes all four.

What image size should I use for my website?

Use the actual display size, including the 2x retina slot. A hero image that fills a 1920 pixel wide desktop slot should be served at 1920 wide for 1x displays and 3840 wide for 2x retina; a 4000 pixel source served in that slot is wasted bytes. Chrome for Developers' Properly size images Lighthouse audit flags exactly this case — images whose intrinsic dimensions are far larger than the rendered display size — and is the canonical reference for what counts as 'oversized' for web delivery.

Should I use WebP or AVIF on my website?

Both are recommended by web.dev for web performance. WebP encodes faster (5 to 10x faster than AVIF on typical hardware) and is supported in slightly more tools; AVIF compresses 20 to 50 percent smaller than WebP for photographs per Google's AVIF documentation, but encoding is slower. WebP is the safe general-purpose default; AVIF is the right choice for hero images and high-detail photographs where the extra compression saving matters and encoding time is acceptable.

How do I serve WebP or AVIF with a fallback for older browsers?

Use the <picture> element with multiple <source> children, listing the most modern format first. The WHATWG HTML Living Standard and the MDN <picture> reference describe the pattern: the browser picks the first source it can decode, so AVIF-first, WebP-second, JPEG-third serves the smallest file to modern browsers and falls back to JPEG for older clients. This is the pattern web.dev recommends for sites that want modern-format savings without breaking old clients.

Does lazy loading images help with performance?

Yes, for images below the fold. The HTML loading='lazy' attribute tells the browser to defer fetching images that are not yet in the viewport, and Chrome for Developers' Lighthouse audit Defensively enable lazy loading flags images that should use it. Don't lazy-load the first hero image — it should be eager so it renders immediately — and don't lazy-load above-the-fold images on a slow connection.

Does image optimization help with SEO?

Indirectly, yes. Google Search Central's image SEO best practices call out fast-loading pages as a positive ranking signal, and Core Web Vitals (which depend heavily on image bytes) are part of the page experience signals Google uses. Smaller images also make the page easier for Google's crawler to fetch and index, and the image file itself can appear in Google Images search results when the source page is indexable. The direct ranking lever for individual images is descriptive file names, alt text, and the surrounding page context.

Sources

Explore the image compressor topic cluster

Each guide answers a different image-decision question. Pick the one that matches your situation, then use the linked tool to produce the output you need.

Related guides

  • Resize vs Compress: which one actually shrinks your image

    Resizing changes the pixel dimensions of an image; compression keeps the dimensions and re-encodes the file at a smaller byte count. Pick resize when the source is larger than the display size, and compression when the dimensions are right but the bytes are still too high. Backed by Chrome for Developers' two Lighthouse audits and the Pillow documentation.

  • JPEG vs PNG: which format should you actually use

    JPEG is lossy and intended for photos; PNG is lossless and carries an alpha channel, so it is the right format for graphics, screenshots and anything that needs transparency. Pick by content type, not by file size. Backed by MDN, WHATWG and the Pillow documentation.

  • Transparent image format: PNG vs WebP vs AVIF for alpha

    PNG is the safest format for transparent images on the web — lossless, alpha preserved, supported everywhere. WebP and AVIF also carry alpha channels and produce smaller files, but JPEG cannot. A practical guide to choosing the right format for transparent backgrounds, with browser compatibility data from MDN.

  • Image file size vs dimensions: why pixels do not equal bytes

    A 500 by 500 image can be larger in bytes than a 2000 by 2000 image. File size depends on pixel dimensions, compression format, quality setting, colour depth and image complexity — not dimensions alone. A practical explanation with sources from MDN, web.dev and Pillow.

  • Why is my image still large after compression

    Your image may still be large after compression because the source was already optimized, the format is inefficient for the content type, the dimensions are too large for the destination, or the quality setting is too high. A troubleshooting guide with actionable checks from MDN, web.dev and Chrome for Developers.

  • Crop vs resize: how to fit an image into a target shape

    Crop keeps the target pixel dimensions and removes pixels at the edges of the source; resize keeps all of the source pixels and fits them into the target by scaling. A third option - letterbox - keeps all of the source and adds padding so the target aspect ratio is preserved. Pick by what the destination needs the image to do, not by which sounds simpler. Backed by the Pillow documentation, MDN and platform specs.

  • JPEG vs PNG vs WebP: how to choose the right image format

    JPEG, PNG and WebP are not interchangeable. The right choice depends on what is in the image, whether it needs transparency, the file-size budget, and where the image will be displayed. A practical decision guide backed by MDN, Google Developers, web.dev, the WHATWG HTML Living Standard and the Pillow documentation.

  • Image alt text and SEO: how to write alt text Google Images can use

    Alt text is the value of the alt attribute on an <img> element. Google Images uses alt text together with the file name and the surrounding page text to understand what an image shows. A practical guide grounded in Google Search Central, MDN and the WHATWG HTML Living Standard.

  • How to tell if an image is over-compressed

    An over-compressed image shows visible JPEG block artefacts, ringing around edges, colour banding in gradients and smearing of sharp text. A practical checklist for spotting each symptom at the actual display size, plus when to re-encode at higher quality or switch format. Backed by MDN, web.dev, Pillow and Chrome for Developers.

All image compressor guides