How to Compress Images for the Web Without Losing Quality (Complete Guide)

To compress images for the web, resize each image to the largest size it is actually shown at, save it in a suitable format at the lowest quality setting that still looks right to you, remove metadata you do not need, and keep the untouched original somewhere safe. Compression without resizing usually leaves most of the waste in place.

Images are often the heaviest files on a page, so they are a common reason a page feels slow on a phone. Smaller files download sooner, which helps Largest Contentful Paint (LCP), the time until the biggest visible element has loaded. The "good" LCP threshold is 2.5 seconds or less at the 75th percentile of page loads. This guide is for site owners and developers. You will learn the difference between lossy and lossless compression, which quality numbers to start from, which commands to run and how to check the result.

Before you begin

You will need:

The original image files, ideally the largest and cleanest versions you have.
A way to run a conversion: ImageMagick, cwebp or avifenc on the command line, a Node.js build step, or a CMS or image CDN.
About 30 to 60 minutes for a first batch.

The main risk is overwriting your only copy of an image with a lower-quality one. Work on copies, write results to a different folder and keep the originals.

Lossy vs lossless compression

Compression means storing the same picture in fewer bytes. There are two kinds.

Lossless compression shrinks the file and can be reversed exactly. Decoding gives back every original pixel.
Lossy compression shrinks the file much more by discarding detail the eye is least likely to notice. The discarded detail cannot be recovered.

Format	Compression	Typically best for	Notes
JPEG	Lossy	Photographs	Works everywhere. No transparency.
PNG	Lossless	Screenshots, sharp graphics, transparency	Large for photographs.
WebP	Lossy or lossless	Photographs and graphics, with transparency	Supported by current major browsers.
AVIF	Lossy or lossless	Photographs where the smallest file matters	Often smaller than WebP or JPEG, slower to encode. Check current browser support at caniuse.com.
SVG	Text-based vector	Icons, logos, simple illustrations	Not made of pixels. Minify it and let the server compress it as text.

"Without losing quality" in practice means "without visible loss". Moderate lossy settings are often indistinguishable from the original at the size shown on a page. The goal is the point just before you can see a difference.

Compress images for the web: resize before you compress

Resizing is the biggest lever. File size tends to rise with the number of pixels, so a photograph exported 4,000 pixels wide and shown 400 pixels wide carries far more data than any visitor can see. Compression then works on pixels the browser throws away anyway.

The order matters: start from the original, resize to the target dimensions, compress once into the delivery format, and never compress the compressed result again. Re-saving a lossy file as lossy adds new losses on top of the old ones, called generation loss.

Choose target dimensions

Pick the width from how the image is displayed, not from how big the file happens to be. A CSS pixel is the unit the browser uses for layout. A 2x screen draws each CSS pixel using about four physical pixels (two across, two down), so an image shown 390 CSS pixels wide can use roughly 780 pixels of image data on a 2x phone and 1,170 on a 3x phone. Beyond that you pay for pixels the screen cannot show.

For example, a full-width hero might be exported at 800, 1200 and 1600 pixels wide, an article-column image at 480, 800 and 1200, and a card thumbnail at 200 and 400. Your layout decides. Export two or three widths and let the browser choose with srcset and sizes; see Responsive Images with srcset and sizes: Serve the Right Size. Do not enlarge small images, since scaling up adds bytes without adding detail.

Quality settings by format

Quality numbers are not comparable across tools. An 80 in one encoder is not the same visual result as an 80 in another, and AVIF numbers mean something different from JPEG numbers. Treat the table as a place to begin testing.

Format	Setting to try first	Notes
JPEG	Quality 75 to 85	Around 80 is a common starting point for photographs.
WebP (lossy)	Quality 75 to 80	Use lossless mode for flat graphics with sharp edges.
AVIF (lossy)	Quality 50 to 65	On the 0 to 100 scale of recent `avifenc` versions. Older versions use `--min` and `--max`.
PNG	Lossless	`pngquant` can reduce the palette of flat artwork. Inspect the result.

Commands that write a new file and leave the original alone:

# JPEG: at most 1600 px wide, metadata removed, quality 80, progressive (ImageMagick 7)
magick original.jpg -resize '1600x>' -strip -quality 80 -interlace Plane photo-1600.jpg

# WebP: lossy, quality 80, slowest/best compression method
cwebp -q 80 -m 6 photo-1600.jpg -o photo-1600.webp

# WebP: lossless, for logos and flat graphics
cwebp -lossless logo.png -o logo.webp

# AVIF: quality 60, speed 6 (libavif 1.0 or later)
avifenc -q 60 -s 6 photo-1600.jpg photo-1600.avif

In ImageMagick, '1600x>' means "width 1600, only shrink if larger", and -strip removes metadata and embedded colour profiles, so make sure the image is already in the sRGB colour space most web images use. -interlace Plane writes a progressive JPEG, which paints a rough version first and sharpens as it loads. On ImageMagick 6 the command is convert instead of magick.

Metadata is extra information stored in the file, such as camera model and sometimes GPS location (a block called EXIF). Removing it saves a little space and avoids publishing location details by accident.

Batch workflows and build-step automation

For a folder of images, wrap the commands above in a shell loop over originals/*.jpg. If images are added regularly, a build step keeps results consistent. This Node.js example uses the sharp library (install with npm install --save-dev sharp) to make WebP files at several widths:

// optimize-images.mjs
import { readdir } from "node:fs/promises";
import path from "node:path";
import sharp from "sharp";

const widths = [480, 800, 1200];

for (const file of await readdir("images/originals")) {
  if (!/\.(jpe?g|png)$/i.test(file)) continue;
  const source = path.join("images/originals", file);
  const { width: original } = await sharp(source).metadata();
  for (const width of widths.filter((w) => w <= original)) { // never enlarge
    await sharp(source).rotate().resize({ width }).webp({ quality: 80 })
      .toFile(`public/img/${path.parse(file).name}-${width}.webp`);
  }
}

The argument-free .rotate() applies the orientation stored in the file, so portrait photos are not turned sideways when metadata is dropped. The public/img folder must exist, and sharp also offers an .avif() method. Run the script from an npm script before your site build; static site generators and image CDNs offer similar features. For serving several formats with a fallback, see Use WebP and AVIF Images to Improve Website Speed.

Check the result visually

Never trust a number alone. Open the original and the compressed file side by side at 100 percent zoom and at the size they appear on the page. Check on a real phone if you can. Look at smooth gradients and skies (visible bands), text and sharp edges (specks around letters), faces and skin (a waxy look) and flat colour areas (slight shifts).

A practical method: encode at your starting quality, then try 10 points lower. If you cannot tell the difference at normal viewing size, keep the lower value; if you can, step back up.

What to do with the originals

Keep them. A lossy file cannot be turned back into the original, and you will need the master when your layout changes or a new format becomes useful.

Store originals outside the folder your web server serves, so visitors do not download them.
Back them up like any business file. For large collections use a storage service or Git LFS.

Measure the result

Record sizes before and after. In Chrome DevTools, open the Network tab, filter by "Img", sort by Size and compare the transferred bytes before and after, reloading with the cache disabled for a fair test. Then run Lighthouse and read its image-related audits, such as those about properly sized images and modern formats. Audit names change between versions. For the metric most affected by hero images, see Fix Largest Contentful Paint (LCP) on Mobile. Lab results come from one simulated load, so real visitors may see different numbers; see Field Data vs Lab Data: Why Lighthouse and Real Users Disagree.

Step-by-step instructions

Step 1: List your images and back up the originals

Make a table of each image, its page and the largest size it is displayed at, heaviest first. Copy the originals to a place your web server does not serve, and do not work in that folder.

What success looks like: you know the 10 to 20 heaviest images, and a backup exists.

Step 2: Decide dimensions, format and starting quality

Use the display width plus allowance for dense screens. Use JPEG or lossy WebP for photographs, PNG or lossless WebP for sharp graphics and SVG for icons.

What success looks like: each image type has target widths, a format and a quality.

Step 3: Compress a test batch and check by eye

Run the commands on three to five representative images, writing to a new folder. Compare each with its original and re-encode at a different quality if needed.

What success looks like: each file is noticeably smaller, and you cannot see a difference at the displayed size.

Step 4: Process the rest and publish

Run the full batch or add the script to your build. Update the HTML to point at the new files, with width, height and meaningful alt text. See Image SEO: Alt Text, File Names and Formats That Help Search.

What success looks like: live pages load the new files and no image is broken.

Step 5: Measure and guard against regressions

Repeat the DevTools and Lighthouse checks and note the before and after sizes. Add a size check so oversized images are caught before publishing; see Lighthouse CI and Performance Budgets: Catch Regressions Early.

What success looks like: a recorded reduction in image bytes and no new visual complaints.

Final verification checklist

Originals are backed up and not served by the website.
Every image is resized to its displayed size plus allowance for dense screens, not larger.
Photographs use JPEG, lossy WebP or AVIF, and sharp graphics use PNG, lossless WebP or SVG.
A visual check at displayed size and on a phone shows no banding, blockiness or colour shifts.
HTML includes width, height and descriptive alt text.
The first, above-the-fold image is not lazily loaded; images further down are. See Lazy Loading Images for SEO: Defer Images Without Hiding Them.
Before and after file sizes are recorded.

Common mistakes to avoid

Compressing without resizing. A huge image at low quality can still outweigh a right-sized image at moderate quality.
Re-compressing a compressed file or overwriting originals. Go back to the original and keep masters separately.
Using PNG for photographs. The file is typically much larger than a JPEG or WebP of the same picture.
Using one quality number for everything. Photographs and flat graphics need different settings.
Enlarging small images. It adds bytes and no detail.
Lazy loading the hero image. It delays the element LCP usually measures.

Frequently asked questions

What is the best way to compress images for the web?

Resize to the displayed size first, then save in an efficient format such as JPEG, WebP or AVIF at the lowest quality that still looks right to you. Keep the originals and compress each image once. For many files, use a script or build step.

Does compressing images reduce quality?

Lossless compression does not change a single pixel. Lossy compression discards detail, but at moderate settings the loss is often hard to see at the size an image appears on a page. Test by comparing with the original at normal viewing size.

What JPEG quality should I use for the web?

A value between 75 and 85 is a common starting point for photographs, and many people begin near 80. The right number depends on the picture and the encoder, so try a lower value and step back up if you notice artifacts.

Should I use WebP or AVIF instead of JPEG?

Both can give smaller files than JPEG at similar visual quality, and WebP is supported by current major browsers. Check current AVIF support at caniuse.com. A <picture> element with a JPEG fallback lets you use newer formats safely.

Can I compress a JPEG that is already compressed?

You can, but each lossy save adds new loss. Use a modest setting and check the result, or better, produce each web version from the original.

Will compressed images improve my search rankings?

Smaller images can make pages load faster, and page experience is one input among many for search. No one can promise a ranking change from compression alone, so treat it as a way to improve loading for visitors.

Using Crawvix

After you publish compressed images, Crawvix's Image Doctor can help you find what is left. It lists the images written into the HTML of the pages of a full scan of a verified website (up to 2,000), checks up to 200 of them for status, type and file size, and reports missing or generic alt text, broken images, large files, missing width and height, a lazily loaded first image, older formats and generic file names. Each finding comes with evidence and what to do, and there is a CSV export. It only reads a website and never changes it, so you still do the compressing yourself.

Official references

Next step: Run Image Doctor to see which images on your verified website are large, in older formats or missing dimensions, or scan the whole site with Crawvix. This guide provides technical information, not a guarantee of rankings, traffic or indexing.