How to Compress Images for a Website Without Ruining Quality

The practical answer

To compress website images without ruining quality, do not start by dragging a quality slider to the lowest number that looks acceptable. Start with the image's real job on the page. A hero image, product zoom photo, blog illustration, avatar, screenshot, and background texture all need different dimensions, formats, and quality settings.

The useful rule is: resize to the largest displayed size first, then compress just enough that the image still looks unchanged in the layout. If a blog image displays at 760 CSS pixels wide, a 1500-1600 px source is usually plenty for high-density screens. A 5000 px camera original is wasted data. A 760 px export may look soft on retina screens. The right file sits between those extremes.

"Without losing quality" also needs a plain definition. For website work, it usually means no visible quality loss at the size visitors actually see, not mathematical pixel perfection. A compressed WebP is not identical to the original file, but it can be visually indistinguishable in the page.

Decide what kind of website image it is

Before choosing WebP, AVIF, JPEG, PNG, or a quality value, classify the asset:

This table is deliberately opinionated. Most bad website-image compression comes from treating every asset the same way. A homepage hero can affect Largest Contentful Paint. A product detail image may affect trust and conversion. A decorative background can be much smaller because nobody studies it.

Resize first: dimensions do most of the work

Compression lowers the number of bytes used to store a fixed pixel grid. Resizing changes the pixel grid itself. If the source has far more pixels than the page can display, resizing is the cleaner win.

Use this simple sizing formula:

target source width = largest CSS display width x device pixel ratio

For example:

• A card image displayed at 320 CSS px should have a 640 px source for 2x screens.
• A blog image displayed at 760 CSS px should have a 1500-1600 px source.
• A full-width hero displayed near 1200 CSS px may need a 2000-2400 px source, depending on crop and audience devices.

Do not blindly use 3x for every image. web.dev notes that DPR and layout both matter, and in many cases users cannot perceive the benefit of very high DPR sources. A 2400 px hero can be sensible. A 5000 px hero because "more pixels is safer" usually just burns bandwidth.

PhotoTools separates these jobs. Use Resize when you need exact pixels or a smaller long edge. Then use Compress to choose JPEG, WebP, or AVIF and tune the quality.

Choose the format before touching quality

The format decides what kind of detail can be removed cleanly.

• Use WebP for most website photos. It is broadly supported in modern browsers and usually smaller than JPEG at similar visible quality. Google's WebP documentation reports 25-34% savings versus comparable JPEG images at equivalent quality.
• Use AVIF where every byte matters. AVIF can beat WebP on large photographic assets, but it can be slower to encode and adds pipeline complexity. Use it with fallbacks, not as the only file.
• Use JPEG as the compatibility fallback. It is still useful for email, older CMS workflows, downloads, and fallback <img> sources.
• Use PNG or lossless WebP for screenshots and text. Lossy JPEG/WebP can make small UI text fuzzy and add color noise around hard edges.
• Use SVG for logos and icons. A raster logo converted to WebP may be smaller than PNG, but a clean SVG is usually sharper and lighter.

If you use <picture>, put the most efficient format first and keep a compatible fallback in the nested img:

<picture>
  <source
    type="image/avif"
    srcset="/images/hero-1200.avif 1200w, /images/hero-2000.avif 2000w"
    sizes="100vw"
  />
  <source
    type="image/webp"
    srcset="/images/hero-1200.webp 1200w, /images/hero-2000.webp 2000w"
    sizes="100vw"
  />
  <img
    src="/images/hero-1200.jpg"
    width="1200"
    height="800"
    alt="A finished kitchen remodel with walnut cabinets and natural light"
  />
</picture>

The img element still matters. It carries the fallback source, alt, width, and height. Do not hide accessibility or layout information in source elements.

Quality settings that are useful in practice

Quality numbers are not standardized. JPEG quality 80 in one encoder is not guaranteed to match quality 80 in another encoder. WebP 80, JPEG 80, and AVIF 50 are also not equivalent. Treat quality as a starting point, then inspect the exported file.

A common trap is exporting every image at quality 95 or 100 because it feels safer. For most web photos, the extra bytes are visible in the network waterfall, not on the page. Another trap is forcing quality below 50 to hit an arbitrary target. If quality has to go that low, resize the image or switch formats before degrading it further.

Target file sizes by page role

These are not Google rules or magic ranking thresholds. They are practical review targets that help catch images that are obviously too heavy.

If a 760 px blog image is 900KB, it probably needs attention. If a full-width portfolio image is 410KB and looks excellent, shrinking it to 90KB may be the wrong goal.

Compressing LCP and hero images

The image most worth optimizing is often the largest above-the-fold image. In Core Web Vitals language, this is frequently the Largest Contentful Paint image. Compressing it can help, but only if the image is also discovered and loaded early.

For a hero image:

1. Crop it to the real aspect ratio used on the page.
2. Export responsive widths, such as 1200 px and 2000 px.
3. Use AVIF first and WebP/JPEG fallback if your stack supports it.
4. Do not lazy-load the hero or other above-the-fold LCP candidate.
5. Add width and height so the browser can reserve layout space.
6. Use fetchpriority="high" only for the single image most likely to be the LCP element.

Example fallback img:

<img
  src="/images/hero-1200.jpg"
  srcset="/images/hero-1200.jpg 1200w, /images/hero-2000.jpg 2000w"
  sizes="100vw"
  width="1200"
  height="800"
  fetchpriority="high"
  alt="A finished kitchen remodel with walnut cabinets and natural light"
/>

Do not use fetchpriority="high" on a whole gallery. Priority hints are sharp tools; use one for the image that actually needs to arrive first.

How to compare compression results

The right comparison is not original file versus compressed file at 100% zoom. That is how you talk yourself into shipping oversized images. Compare at the size and context visitors see.

Use this review pass:

1. Put the compressed image in the actual page or a same-width test layout.
2. View it at desktop and mobile widths.
3. Check the likely danger zones: faces, skin, sky, gradients, fabric, product labels, small text, and high-contrast edges.
4. Toggle between original and compressed versions at the rendered size.
5. Briefly zoom to 100% only to catch obvious artifacts, not to demand perfection nobody will see.

Compression artifacts have personalities. JPEG often shows blocky edges, ringing, or color noise. Over-compressed WebP can smear texture. AVIF can produce banding or plasticky detail if pushed too far. PNG screenshots usually fail in the opposite direction: they look perfect but weigh much more than necessary.

A PhotoTools workflow for website images

PhotoTools is useful before an image reaches your CMS, CDN, or repository. It does not replace a full build pipeline, but it gives you a clean manual workflow for small sites, blog posts, client previews, and one-off assets.

1. Keep the original source file untouched.
2. Decide the image role: hero, content image, product photo, screenshot, thumbnail, or background.
3. Use Resize first when the original is much larger than the display size.
4. Open Compress, choose JPEG, WebP, or AVIF, and start near quality 80 for WebP/JPEG.
5. Click Compress all and read each card's original size, output size, and percentage saved.
6. Download the result and inspect it in the page context.
7. If it fails visually, go back to the original or resized copy and export again at a higher quality.
8. If it is still too heavy, reduce dimensions before lowering quality into artifact territory.

Do not keep recompressing the already-compressed download. That compounds lossy artifacts. Go back to the master or the clean resized intermediate.

Metadata and privacy

Camera files often contain EXIF metadata: GPS coordinates, capture date, camera model, lens, and editing software. That metadata does not help website visitors see the image. It can also expose private information.

PhotoTools compresses images by decoding the file, drawing the pixels to a browser canvas, and exporting a new file. MDN documents that OffscreenCanvas.convertToBlob() can specify image type and quality for formats that support lossy compression. Because the output is generated from canvas pixels, camera metadata is usually not copied into the new file.

For sensitive photos, verify the final download with a metadata checker before publishing. Privacy is not just file size.

Common mistakes that make images look bad

• Compressing before resizing: You are trying to save bytes from pixels the layout will never show.
• Using PNG for photos: PNG is usually huge for camera images.
• Using JPEG for screenshots with text: The file may be smaller, but the text can look fuzzy.
• Judging at the wrong size: Full-resolution zoom makes harmless artifacts look dramatic.
• Exporting one giant hero for all devices: Mobile visitors download desktop pixels they cannot use.
• Lazy-loading the hero: Below-the-fold images can be lazy-loaded. The LCP image should not be.
• No width and height: The page may shift as images load.
• Recompressing the published file: Start from the source when possible.

A compact publishing checklist

Before uploading a website image, run through this:

1. Is this the right format for the content type?
2. Is the source width based on real display width and likely DPR?
3. Is there a smaller mobile candidate if the hero crop changes on mobile?
4. Is the quality setting high enough for faces, labels, gradients, and product detail?
5. Is the file size reasonable for its role?
6. Does the page include width, height, useful alt, and responsive srcset/sizes when needed?
7. Is the LCP image eager and prioritized, while below-the-fold images are lazy-loaded?
8. Did you check the exported image in the actual layout?
9. Did you keep the original source file?

The best compression workflow is boring in the right way: choose the right pixels, choose the right format, export at a sensible quality, inspect the real page, and stop before the image starts to look processed.

Technical sources checked

This article was reviewed against the current PhotoTools compression and resize implementation, web.dev's image performance guide, Chrome's Improve image delivery insight, Chrome's properly size images guidance, MDN's OffscreenCanvas convertToBlob() documentation, MDN's image file type guide, and Google's WebP documentation.