BlogImage Compression

How to Compress Hero Images Without Hurting Quality

A quality-first workflow for shrinking hero images to visually lossless sizes, covering codec quality settings, where compression damage appears first, banding and text-artifact fixes, and how to verify quality at display size.

Updated: July 20, 2026

To compress a hero image without hurting quality, resize it to the width it will actually display at, export it to AVIF or WebP, then lower the quality setting in small steps until you can no longer see a difference when viewing it at its real rendered size—then stop. Almost all visible quality loss comes from two mistakes: compressing without resizing first, and judging quality at 100% zoom instead of at the display size visitors actually see.

The goal is "visually lossless," not numerically lossless. A hero that is indistinguishable from the original at the size it renders is fully acceptable, even if its pixels differ at high zoom. Hero images carry a lot of weight because they are large and often the page's Largest Contentful Paint (LCP) element, so shrinking them matters for Core Web Vitals—but the constraint is that they are also the first thing a visitor sees, so visible artifacts hurt more here than anywhere else.

Key Takeaways

  • Judge quality at the display size, not at 100% zoom. Zooming over-represents artifacts and leads to both over- and under-compression. Compare side by side at the real rendered dimensions.
  • Resize before you compress. Downsampling is barely perceptible; visible loss comes from the compressor. Resizing first lets the codec spend its bitrate on fewer pixels.
  • Always compress from the original. Re-compressing an already-lossy file compounds damage with every pass.
  • Quality numbers are not comparable across codecs. JPEG 80, WebP 80, and AVIF 80 do not mean the same thing. Start high and reduce until you cannot see a difference.
  • Inspect the three danger zones first: skin tones and faces, smooth gradients (skies), and sharp edges or text. That is where damage appears before anywhere else.
  • Keep text off the photo when you can. Overlay headlines with HTML and CSS so the photo compresses cleanly and the text stays crisp.
  • AVIF and WebP beat JPEG for heroes. They are smaller at the same perceived quality, and WebP and AVIF handle gradients better than JPEG's 8×8 blocking.

The One Principle That Decides Quality

Every quality question about hero compression reduces to one idea: find the point where a smaller file is still indistinguishable from the original at the size the image is displayed, and stop there. Go smaller and you trade visible quality for bytes you may not need; stay larger and you ship weight that buys no perceptible improvement.

This is the just-noticeable-difference threshold, and it depends on three things:

FactorEffect on the quality-vs-size point
Display sizeThe smaller the render size, the more aggressively you can compress before anyone notices
Viewing deviceHigh-DPI retina screens reveal softness and artifacts sooner than standard displays
Image contentBusy, detailed photos hide artifacts; flat gradients and sharp text reveal them immediately

The practical consequence: a hero that looks flawless at 1,440 px wide can usually be compressed far harder than pixel-peeping at 100% zoom suggests. Set the comparison view to the actual rendered size first, every time.

Where Compression Damage Appears First

Lossy codecs do not degrade an image evenly. They break down in predictable regions, and checking those regions first tells you instantly whether a quality setting is acceptable.

RegionSymptom at too-low qualityWhy it happens
Skin tones and facesBlotchy color shifts, plastic look, lost textureFaces are where the eye is most sensitive to subtle changes
Smooth gradients (skies, sunsets)Banding—visible stair-step stripesToo few tonal steps remain to represent the gradient
Sharp edges and textRinging—light or dark halos; soft letterformsHigh-frequency detail is the first information discarded
High-frequency detail (foliage, fabric, hair)Smoothing, "painterly" loss of textureFine detail is expensive to encode and gets averaged away
Saturated reds and strong color edgesColor fringing, bleedingChroma subsampling (4:2:0) discards most color resolution

If those five regions look clean at the display size, the rest of the image will look clean too. If any of them shows damage, raise the quality and re-check.

Step-by-Step Quality Workflow

Step 1: Start from the original, uncompressed source

Open the original—the raw camera file, the full-resolution export from your design tool, or the highest-quality master you have. Never start from a JPEG or WebP that has already been compressed, because re-compressing it compounds quality loss with every pass.

Step 2: Resize to the display width

Find the largest width the hero renders at (inspect the live element at its widest breakpoint), then export at that width—or up to about 2× that width if you want sharper retina rendering. Test whether the 2× version's sharpness is worth the extra pixels before committing to it.

Resizing is largely imperceptible. Downsampled pixels are averaged from their neighbors, which is information your eye does not miss at normal viewing distance. The loss you worry about comes from the compressor, not the resizer, so resize first and let the codec work on fewer pixels.

Step 3: Export to AVIF or WebP at a high starting quality

Export the resized image to a modern format:

FormatGood for heroes?Starting qualityNotes
AVIFYes—best efficiency~60–75 (tool scale) or cq ~25–35Smallest file at equal perceived quality; can subtly smooth very fine texture; slow to encode
WebPYes—safe default~75–85Near-universal support; predictable quality; handles gradients better than JPEG
JPEGAcceptable fallback~75–85Universally supported; 8×8 blocking artifacts; no transparency
PNGOnly for lossless needsLosslessLarge for photographs; reserve for graphics requiring exact fidelity

Use a <picture> element to offer AVIF first, WebP second, and a JPEG fallback, so every browser gets the best format it supports.

Step 4: Reduce quality in small steps and compare at display size

This is the step that determines final quality. Open the original and the compressed export side by side at the actual rendered width, not zoomed in:

  1. Set the comparison view to the hero's real display dimensions.
  2. Flip between original and compressed, or use a slider.
  3. If you see no difference, lower the quality by 5–10 and repeat.
  4. The instant you notice a difference in a danger zone (skin, sky, edges), step back up one notch. That is your visually-lossless setting.

A Butteraugli difference map (exposed in Squoosh and other tools) highlights exactly where the compressed image diverges from the original, which is faster than eyeballing large images. Bright areas in the diff are where quality was lost.

Step 5: Inspect the danger zones specifically

Before accepting a quality setting, look directly at:

  • Faces and skin for blotchiness or a plastic, over-smooth appearance.
  • Skies and any gradient for banding stripes.
  • Text and thin lines for halos or softness.
  • Fine texture (hair, fabric, foliage) for smoothing that makes the image look painted rather than photographed.

If all four are clean at the display size, the setting is visually lossless for this hero.

Step 6: Deliver responsively

Serve the compressed hero with srcset and sizes so phones receive a smaller variant instead of the full desktop file. This protects quality on mobile—where the same hero otherwise downloads at desktop resolution and then gets scaled down—while keeping the desktop file sharp. Set explicit width and height (or aspect-ratio) so the browser reserves space and avoids layout shift.

Codec Quality Guidance

The single most common confusion in image compression is treating quality numbers as if they were comparable. They are not.

CodecQuality scaleVisually-lossless starting pointBehavior at low quality
JPEG0–100, higher is better~80–858×8 block artifacts; ringing near edges
WebP (lossy)0–100, higher is better~80–85Smoother than JPEG; slight softness at equal numbers
AVIFTool-dependent: 0–100 higher-is-better, or cq 0–63 lower-is-better~65–75 (tool scale) or cq ~25Subtle smoothing of fine texture before obvious artifacts appear

Because JPEG 80, WebP 80, and AVIF 80 represent different amounts of compression, never copy a number from one codec to another. Start at the visually-lossless point for each codec and adjust by eye.

A note on AVIF smoothing: AVIF is so efficient that it can remove fine texture before it produces obvious blocky artifacts. The image still "looks clean" but may have lost the micro-detail that gives photos a photographic feel. For heroes where fine texture matters (fabric, hair, landscapes), compare AVIF against WebP at equal perceived sharpness and pick the one that preserves texture.

Special Cases That Commonly Hurt Quality

Banding in skies and gradients

Banding—visible stripes across what should be a smooth sky—is the most frequent hero-quality complaint, because hero photos so often feature skies, sunsets, or soft studio backgrounds. It happens when the compressed file has too few tonal steps to represent a wide, smooth gradient.

Fixes, in order of effectiveness:

  • Raise the quality for that specific image. Gradients are the canary; if the sky bands, the whole file is under-compressed.
  • Switch to WebP or AVIF. Both handle smooth gradients better than JPEG.
  • Add subtle noise or dither to the gradient before exporting. A tiny amount of random noise breaks up the bands and is invisible at display size.
  • Reduce the tonal range in the source design. A sky that spans a narrower brightness range bands less.

Text and logos on hero photos

Sharp text and thin lines are the first thing lossy compression damages. If your hero bakes a headline into the photo, expect ringing halos around the letters and softening at any aggressive quality setting.

The clean solution is to separate the two:

  • Keep the photo text-free and overlay the headline with HTML and CSS. The photo then compresses cleanly, and the text renders perfectly crisp at any resolution with zero bytes.
  • If text must be baked in, export at a higher quality than you would for a plain photo, and disable chroma subsampling (use 4:4:4) so color resolution is preserved around letter edges. This costs bytes, which is another reason to prefer overlaying text.

Illustrations and graphics vs. photographs

Photographs compress well with lossy codecs because the eye tolerates small changes in continuous tone. Flat illustrations, screenshots, and graphics with large areas of solid color do not—they develop banding and artifacts along edges at quality settings that look fine on photos. For graphic-heavy heroes, prefer SVG (for vector art), PNG (for raster graphics needing fidelity), or lossless WebP, and reserve AVIF/WebP lossy for the photographic regions.

Retina and 2× Sources: Help or Hurt?

A 2× source has four times as many pixels as a 1× source, which means four times as much data for the codec to encode. On a high-DPI screen, those extra pixels can preserve sharpness that a 1× source loses—but only if the 2× file is large enough to carry the detail.

In practice:

  • A 2× source at moderate quality often looks sharper on retina than a 1× source at high quality, because perceived sharpness comes from having enough pixels, not from compressing fewer of them gently.
  • But a 2× file is larger, which matters for a hero that is the LCP element.
  • Test 1.5× as a compromise. It gives most of the retina sharpness for a little over twice the pixels of 1×, and for many heroes it is the sweet spot.

The right answer is empirical: export 1×, 1.5×, and 2× versions at visually-lossless quality, compare them on a real retina device at the display size, and pick the smallest one whose sharpness you cannot distinguish from the largest.

Common Mistakes That Hurt Quality—or Waste Bytes

  • Judging quality at 100% zoom. This is the most common error. It makes people either over-compress to "fix" invisible artifacts or under-compress out of misplaced caution. Always compare at the display size.
  • Compressing before resizing. A 5,000 px source compressed and then displayed at 1,440 px wastes bandwidth and shows more artifacts than necessary. Resize first.
  • Re-compressing an already-compressed file. Generation loss compounds with every pass. Always start from the original.
  • Copying a quality number between codecs. JPEG 80 and AVIF 80 are not the same compression. Set quality per codec by eye.
  • Baking text into the photo. It forces a higher quality setting for the whole file just to protect the text. Overlay text with HTML instead.
  • Ignoring the sky. Banding appears in gradients long before it appears anywhere else. If the sky is clean, the file is usually fine everywhere.
  • Assuming lossless is required. A visually-lossless hero is indistinguishable from the original at the display size and is a fraction of the bytes. Reserve true lossless for graphics where pixel fidelity matters.
  • Using PNG for photographs. PNG is lossless and enormous for continuous-tone photos. WebP or AVIF at visually-lossless quality is dramatically smaller at the same perceived quality.

How to Verify the Final Quality

  1. Open the original and the final export side by side at the hero's real display dimensions.
  2. Check the four danger zones: skin, gradients, edges and text, fine texture.
  3. Use a Butteraugli or SSIMULACRA difference map to see where the two diverge; bright regions indicate lost quality.
  4. View the comparison on both a standard and a high-DPI screen if you can.
  5. Confirm the file size is within your hero budget (commonly under ~200 KB, and closer to ~100 KB when achievable) while still passing the visual check.

If the image passes the visual check at the display size and hits your size budget, it is done—regardless of what it looks like at high zoom.

Pre-Publish Quality Checklist

  • Started from the original, uncompressed source
  • Resized to the display width (tested 1×, 1.5×, or 2×)
  • Exported to AVIF or WebP with a JPEG fallback
  • Reduced quality until no difference is visible at display size
  • Checked skin tones, gradients, edges, and fine texture
  • Confirmed no banding in skies or smooth backgrounds
  • Kept text as an HTML overlay where possible
  • Compared on a high-DPI screen if targeting retina
  • Reviewed a difference map (Butteraugli/SSIMULACRA) for hidden loss
  • Confirmed the file is within the hero size budget

Next Step

Take one current hero image and run it through this workflow. Export the original at the display width to AVIF and WebP, open them beside the original in Squoosh at the real render size, and step the quality down until you cannot tell them apart. Check the sky and any faces. Note the final file size—then compare it to the file you are shipping today.

FAQ

How do I compress a hero image without losing quality?

Resize the source to the width it will render at, export to AVIF or WebP, then lower quality in small steps until you cannot see a difference at the real display size. Check the three places damage appears first—skin tones, smooth gradients, and sharp edges or text. Most visible loss comes from compressing without resizing first, or from judging at full zoom instead of at the rendered size.

What quality setting should I use for hero images?

Quality numbers are not comparable across codecs. Rough starting ranges: JPEG 70–85, WebP 75–85, and AVIF 60–75 on a tool's 0–100 scale (or a constant-quality value around 25–35 on the lower-is-better AVIF scale). Start at the high end for a hero, reduce until you cannot see a difference at display size, and stop.

Why does my hero image have banding in the sky?

Banding appears when a smooth gradient is compressed at too low a bitrate, leaving too few tonal steps. Raise the quality for that image, use WebP or AVIF (which handle gradients better than JPEG), add a small amount of dither before exporting, or reduce the gradient's tonal range in the source design.

Should I compress the hero at 2x for retina screens?

A 2x source can look sharper on high-DPI screens, but it has four times as many pixels and a larger file at the same quality. Test 1.5x as a middle ground, and compress at the resolution you will actually serve through srcset. The goal is perceived sharpness on the visitor's device, not the largest source possible.

Is AVIF or WebP better for hero image quality?

AVIF usually produces a smaller file at the same perceived quality, which suits a large hero, but it can subtly smooth fine texture and encodes slowly. WebP is the safe default with near-universal support. Use a <picture> element offering AVIF first, then WebP, then a fallback.

Why does text on my hero look blurry or have halos?

Sharp text is the first thing lossy compression damages, producing ringing halos around letters. Keep the photo text-free and overlay the headline with HTML and CSS so the photo compresses cleanly and the text stays crisp. If text must be baked in, raise the quality or disable chroma subsampling for that image.

Should I judge hero image quality at 100% zoom?

No. Zooming shows artifacts that are invisible at the real rendered size, which leads to over- or under-compression. Always compare the original and the compressed version side by side at the actual display dimensions visitors see.

Does resizing an image reduce its quality?

Downsampling to a smaller width averages neighboring pixels and is largely imperceptible. Visible loss almost always comes from lossy compression, not resizing. Resize first, then compress, so the codec works on fewer pixels and uses its bitrate more efficiently.

Should I compress from the original file each time?

Yes. Re-compressing an already-lossy file compounds quality loss with every pass—generation loss. Always export from the original, uncompressed source, and store those originals safely so you can re-export at any quality later.

Which tool shows me the quality difference clearly?

Squoosh (squoosh.app) shows side-by-side codec comparisons and a Butteraugli difference map that highlights exactly where a compressed image differs from the original. For a quick browser-based pass, compress at LessMB (https://lessmb.com). For build pipelines, the sharp Node library and the Squoosh CLI can export and compare variants programmatically.

Sources