How to Compress Images for Web Without Visible Quality Loss

To compress images for the web without visible quality loss, work in this order. First, resize each image to the largest size it will actually be displayed at, including the extra pixels that high-density screens need. Next, choose a format that suits the content. Then find the lowest quality setting where you can't see a difference, and go up one step for safety. Remove metadata you don't need, and check the result by eye at real display size.

The order matters more than any single setting. Oversized dimensions are often the biggest source of wasted bytes, because pixel count affects file size more than any quality setting. Quality settings and format choice fine-tune the file, but only after the dimensions are right.

This guide goes through each step and explains why it works. That way you can adapt the process to photos, screenshots, product shots, or anything else your site uses.

Why the order of operations matters

File size depends on how many pixels you store and how efficiently each pixel is encoded. Resizing changes the first factor, and format and quality change the second. Fixing the pixel count first gives the biggest reduction, and it also changes how the later settings behave. If you tune quality on an oversized file, the browser's downscaling hides artifacts. After you resize, those artifacts can show up, so set quality only after resizing.

There is a second reason to stick to a fixed order: generational loss. Each time you open a lossy file (JPEG or lossy WebP) and save it again, the encoder throws away a bit more detail. Compressing, then resizing, then compressing again stacks those losses. Always export from your original, full-quality master straight to the final file in one pass, and keep the master somewhere safe.

Step 1: Resize to the largest displayed size, including high-density screens

Web layouts are measured in CSS pixels, which are abstract units. A screen's device pixel ratio (DPR) says how many physical pixels it uses for each CSS pixel in each direction. Many monitors are 1x, but scaled displays are often 1.25 or 1.5. Most phones are 2 to 3, often a fractional value, and many laptops are 1.5 to 2. You can check any device's value with the browser property window.devicePixelRatio.

The formula is simple:

Target pixel width = largest displayed width in CSS pixels × DPR you want to support

A DPR of 2 is a sensible ceiling for most photos. Going to 3x more than doubles the pixel count compared with 2x (9 times the pixels of 1x instead of 4 times), and on a phone-sized screen the extra detail in a photograph is hard to see. For sharp-edged graphics with small text, it can be worth testing 3x.

Worked example: a blog hero image

1. Measure the layout. Inspect the image in your browser's developer tools at your widest supported layout. Say it renders at 1200 CSS pixels wide.
2. Apply the DPR. 1200 × 2 = 2400 pixels wide.
3. Keep the aspect ratio. Your camera original is 6000 × 4000 (3:2). At 2400 wide, the height is 2400 × (4000 ÷ 6000) = 1600. The target is 2400 × 1600.
4. Compare pixel counts. The original has 6000 × 4000 = 24,000,000 pixels. The resized version has 2400 × 1600 = 3,840,000. That's 3.84 ÷ 24 = 0.16, or 16 percent of the original pixels. You've removed 84 percent of the pixels before touching any quality setting.

Never upscale. If the original is smaller than the target, use it at its native size, because enlarging adds pixels without adding detail. Some editors offer light sharpening after a big downscale. A little can bring back crispness, but too much creates halos around edges.

Typical display widths and target pixel widths

These are common ranges, not standards. Your theme's actual widths are what count, so measure them.

For full-width banners, many sites set a cap (for example, the 2x size of a common laptop width) rather than serving 3840-pixel files to everyone. Screens wider than the cap get a slightly softer image, which is usually an acceptable trade.

Step 2: Choose the right format for the content

Choose the format based on what's in the image, not on habit:

• Photographs and complex scenes compress best with lossy formats: JPEG, lossy WebP, or AVIF. WebP and AVIF usually produce smaller files than JPEG at similar visual quality. Check current browser support for your audience before relying on AVIF alone.
• Screenshots, diagrams, and flat-color graphics often look cleaner and can be smaller as PNG or lossless WebP. JPEG tends to create fuzzy "mosquito noise" around text and sharp lines.
• Logos and icons made of shapes are usually best as SVG, a vector format that stays sharp at any size.
• Transparency rules out JPEG. Use PNG, WebP, or AVIF.

For a fuller comparison of trade-offs, see JPG vs PNG vs WebP: Which Image Format Should You Use?

Step 3: Set quality, and why there is no universal number

Advice like "always use quality 80" is common, but it doesn't hold up, for three reasons.

The scale isn't standardized. A JPEG "quality" value is an input to the encoder's quantization tables, which control how much detail is discarded. It isn't a percentage of the original quality. Different programs map the number differently, so 80 in one tool doesn't match 80 in another. WebP's scale doesn't line up with JPEG's either. AVIF tools vary: many use 0–100, but some use a 0–63 quantizer where lower means better quality, so check which scale your tool uses.

Content changes the outcome. Busy textures like foliage, gravel, or fabric hide artifacts well, so they tolerate low settings. Smooth gradients such as clear skies, studio backdrops, and skin show blockiness and banding (visible steps in what should be a smooth fade) much sooner.

Display density changes the outcome. A file exported at 2x and shown on a 2x screen packs each image pixel into a smaller physical area, which hides artifacts. The same file on a 1x screen, or a 1x export, shows them more clearly.

A repeatable way to find the right setting

1. Pick three or four representative images from one category, such as product photos or article headers, and include at least one with smooth gradients.
2. Resize them to the target dimensions from Step 1.
3. Export each at a high setting, then at progressively lower settings in steps of about 5.
4. Compare each version against the high-quality export at real display size (see the section on judging quality below).
5. Note the lowest setting where you can't see a difference on any of the test images, then go up one step for a safety margin.
6. Use that setting as the default for that category and spot-check new images now and then.

JPEG options: progressive and chroma subsampling

Progressive encoding stores the image in passes, so the browser shows a coarse version first and then sharpens it. The file is often about the same size or slightly smaller. Chroma subsampling stores color at lower resolution than brightness. It saves space with little visible effect on photos, but it can blur sharp red or blue edges and colored text. If those look smeared in a JPEG, turn subsampling off for that image.

WebP quality: lossy vs. lossless mode

In lossy mode, WebP's quality value works roughly like JPEG's: lower numbers give smaller files and more artifacts. Because the scale is different, run the test above separately for WebP instead of reusing your JPEG number.

In lossless mode, the same value means something else. It controls how hard the encoder works to shrink the file, which affects file size and encoding time, but the pixels stay identical at every setting.

Lossy WebP also always uses 4:2:0 chroma subsampling (color stored at half resolution in both directions), so the JPEG fix of turning subsampling off isn't available. For colored text or sharp saturated edges, use lossless WebP or PNG. Alternatively, use the encoder's sharp YUV option if it has one, such as -sharp_yuv in Google's cwebp command-line tool, which converts color more carefully and reduces smearing.

How to strip metadata, and what to keep

Image files often carry data that's never displayed. Examples include EXIF camera data (model, lens, exposure, date), GPS coordinates, embedded preview thumbnails, and editing history stored as XMP. On large photos this is a small share of the file, but on thumbnails and icons it can be a noticeable fraction. GPS data is also a privacy concern, since it can reveal where a photo was taken.

There are a few practical ways to remove it:

• Export dialogs. Many image editors have a metadata setting in their export or "save for web" dialog, often with choices such as none, copyright only, or all. Pick the most minimal option you're comfortable with.
• Web optimizers. Many image optimization tools and services strip metadata by default. Check their settings if you need to keep anything.
• Command line, for batches. The free tool exiftool removes all metadata with exiftool -all= photo.jpg, and it accepts folders as well as single files. By default it keeps a backup of each original with "_original" added to the name.

Before you strip everything, check three things:

• Orientation. Some cameras save the pixels sideways and record the correct rotation in an EXIF tag. If you strip that tag without rotating the actual pixels, the image may appear sideways. Rotate the pixels, sometimes called "applying orientation," first.
• Color profile. If an image uses a wide-gamut profile, removing the embedded profile can make colors look dull or shifted. Convert the image to sRGB, the default color space of the web, before stripping.
• Copyright and credit fields. Some publishers keep these on purpose. Remove them only if you've decided you don't need them.

Serve the right size to each screen with responsive images (srcset)

One file can't be the right size for both a phone screen and a 2x desktop monitor. Responsive images solve this by giving the browser a menu of sizes.

You export the same image at several widths, for example 480, 800, 1200, 1600, and 2400 pixels. In the page markup, the srcset attribute lists those files with their pixel widths. A sizes attribute tells the browser how wide the image will be displayed in different layouts. The browser combines that with the screen's DPR and downloads only the candidate it needs. A phone might fetch the 800-pixel file while a 2x desktop fetches the 2400-pixel one. Browsers have some freedom in this choice, so treat it as a hint rather than a guarantee.

A related element, picture, lets you offer the same image in several formats, such as AVIF, then WebP, with JPEG as a fallback. The browser uses the first one it supports. Many content management systems and image services generate these variants automatically, so check what yours produces before building them by hand. The MDN reference for the img element documents these attributes in detail.

Whatever approach you use, set width and height attributes on images. That lets the browser reserve the right space before the file arrives, which stops text from jumping around as images load.

Lazy loading: don't download what nobody sees yet

Compression makes each image smaller, while lazy loading delays images until they're needed. Adding loading="lazy" to an image tells the browser it can wait to fetch it until the reader scrolls near it. On long pages with many images, this cuts the amount of data downloaded up front.

Don't lazy-load images that are visible as soon as the page opens, especially the main hero or product image. Delaying those makes the most important content appear later.

Lazy loading doesn't reduce file sizes. A 3 MB image that loads lazily is still a 3 MB download once the reader scrolls to it, so it works alongside the earlier steps, not in place of them.

How to judge visible quality

"No visible loss" is a judgment, so make it consistently:

• View at real display size. Look at the image the way readers will, in the page layout, ideally on both a high-density screen and a 1x monitor. Then zoom to 200 percent to find where artifacts appear first, so you know where to look.
• Flip, don't compare side by side. Switching between two versions in the same spot, in two browser tabs or an image viewer, makes small changes much easier to see.
• Check the weak spots. Look for banding in skies and gradients, blocky patches in shadows, halos or ringing around text and hard edges, smeared fine textures like hair or grass (lossy WebP and AVIF can smooth these), and color bleeding at saturated edges.
• Control the viewing conditions. A dim phone screen hides flaws, so check at normal brightness.

Some tools also report objective similarity scores, such as SSIM (structural similarity), and some encoders can aim for a target score automatically. These are useful for processing large batches consistently, but confirm on a few samples that the target looks right to your eyes.

Quick reference checklist

• Keep an untouched master copy, and export every final file directly from it in one pass.
• Measure each image's largest displayed width in CSS pixels in your actual layout.
• Multiply by 2 (or 3 for sharp graphics, if testing shows it helps) to get the target width, and never upscale.
• Photos: JPEG, WebP, or AVIF. Screenshots and flat graphics: PNG or lossless WebP. Logos and icons: SVG.
• Find a quality setting per image category and per format by testing samples, then add one step of margin.
• For colored text in lossy WebP, try sharp YUV or switch to lossless.
• Apply orientation and convert to sRGB, then strip EXIF, GPS, thumbnails, and editing history.
• Provide several widths through srcset and sizes, and set width and height on every image.
• Lazy-load images below the first screen, not the hero image.
• Judge quality at real display size by flipping between versions, and check gradients, edges, and textures.
• Spot-check new uploads now and then, especially if your CMS recompresses images on its own.

Frequently Asked Questions

What file size should an image on a website be?

No single file size is right for every image, because it depends on the pixel dimensions, the content, and the format. Size the image to its display width first, then use the lowest quality setting that still looks the same as the original. Some teams also set a total image budget per page, which helps catch oversized files during review.

Does compressing an image reduce its resolution?

Not by itself. Compression changes how the pixels are encoded, and resizing changes how many pixels there are. A JPEG saved at a lower quality setting keeps the same width and height but has less fine detail. Lossless compression keeps every pixel exactly the same.

Is lossless compression enough for website photos?

Lossless optimization, such as recompressing a PNG more efficiently or removing metadata, makes files smaller without changing the pixels, but for photographs the savings are modest. The big reductions on photos come from resizing and from lossy formats like JPEG, WebP, or AVIF. Lossless is the better choice for screenshots, diagrams, and graphics with sharp edges.

Should I upload full-size photos and let my CMS resize them?

Many content management systems create resized copies automatically, but what they do depends on the platform and its settings. Check whether the full-size original is still linked anywhere, whether metadata such as GPS location gets removed, and what quality the generated copies use. Resizing before you upload gives you control over the result and keeps large originals off the server.

Will my images lose quality if my website platform compresses them again?

If you upload a lossy JPEG or WebP and the platform re-encodes it, each pass throws away a bit more detail, so heavily compressed uploads can end up looking worse. To avoid this, upload at a moderately high quality and let the platform do the final compression, or turn off its recompression if you already optimize images yourself. Compare the published image with your export to see what the platform did.