# How to Compress Images for the Web Without Losing Quality > Reduce image file size with resizing, format choice, quality settings and modern formats, and verify the result at the size users actually see. **Quick answer:** Compress in this order: resize to the largest size the layout displays, choose the right format, set quality at that display size, then compare file size and visual quality. Most oversized images are too large in dimensions, not over-compressed. ## Key takeaways - Resizing usually reduces file size more than lowering quality. - Use AVIF or WebP for photos, PNG or lossless WebP for screenshots and text. - Evaluate quality at the display size, not at 200 percent zoom. - Set width and height to prevent layout shift, and do not lazy-load the LCP image. - Keep the original source outside the deployed assets. --- Image compression is often treated as a quality slider. In practice, the biggest wins come from three earlier decisions: the dimensions, the format, and what the image contains. This guide gives a repeatable order of operations and the checks that prevent a "smaller" image from becoming a worse experience. ## Why images are large An image file size depends on: - The number of pixels (width × height). - The amount of detail and noise. - The format and its compression method. - The quality setting. - Metadata such as EXIF and color profiles. A 4000 × 3000 photo displayed at 800 × 600 contains 25 times more pixels than the layout needs. Compressing it aggressively is less effective than resizing it first. The arithmetic is blunt. A 4000 × 3000 image with four bytes per pixel is 48 MB before compression. A good JPEG encoder brings that to roughly 3–6 MB at quality 80; a PNG of the same photo can exceed 20 MB because PNG is lossless and photographs contain too much unique detail. Detail and noise matter as much as dimensions: foliage, fabric texture and film grain consume far more bits than a smooth sky or a flat background, which is why two images with identical dimensions can differ in size by a factor of five. Metadata is usually a rounding error, not the main problem. EXIF, thumbnails and an ICC profile typically add tens of kilobytes. Removing them is still worthwhile for privacy and cleanliness, but it will not rescue a 5 MB hero image. ## Step 1: resize to the display size Find the largest size the image is displayed at, including high-density screens. If the layout shows the image at 800 CSS pixels wide, a 1600-pixel-wide source covers 2× displays. A 4000-pixel source is usually wasted bytes. Resize before compression. Then compare the resized image at the display size. A smaller image that looks correct is better than a large image compressed until it looks bad. High-density screens do not mean shipping a 4000-pixel original. They mean shipping one or two files that match the CSS layout multiplied by the device pixel ratio. A content image displayed at 800 CSS pixels needs 800 pixels at DPR 1 and 1600 at DPR 2; a 2400-pixel file is wasted on almost every phone and laptop. Use `srcset` with width descriptors and a `sizes` value so the browser chooses, rather than forcing every device to download the largest candidate. Never upscale to fill a slot. Enlarging a 600-pixel image to 1200 pixels adds bytes and blur without adding detail. If the source is too small, either display it smaller or find a better source. The size difference is not subtle. An 800 × 600 JPEG at quality 80 is commonly 60–120 KB; the same photo at 1600 × 1200 carries four times the pixels and often lands around 250–450 KB. Resizing from the larger file gets both the byte savings and the correct sharpness, because the browser downsamples from a clean source rather than from an already compressed one. ## Step 2: choose the format | Content | First choice | Fallback | | --- | --- | --- | | Photos | AVIF | WebP, JPEG | | Screenshots and text | PNG or lossless WebP | PNG | | Transparency | WebP or AVIF | PNG | | Icons and simple shapes | SVG | PNG | | Animation | AVIF or WebP | GIF | The format should match the content. A screenshot saved as a low-quality JPEG will have fuzzy text; a photo saved as PNG will be unnecessarily large. For a deeper comparison, see the WebP vs AVIF vs PNG guide. Expect roughly 25–35 percent savings when moving a photo from JPEG to WebP at comparable quality, and another 20–40 percent from WebP to AVIF on many photographic images. Those ranges are not guarantees: AVIF wins most on smooth gradients and high-resolution photos, and can lose on tiny images or synthetic graphics where its overhead dominates. Encoding cost is the trade: AVIF can take several times longer than WebP, which matters for build pipelines and for user-generated uploads. Browser support is now broad but not universal. WebP is supported by essentially all current browsers; AVIF is supported by current Chrome, Firefox and Safari, but older embedded webviews and some corporate browsers lag. That is exactly what the `picture` fallback is for. Do not send AVIF as the only source and hope. For screenshots, test lossless WebP before assuming PNG is required. Lossless WebP is often 20–30 percent smaller than PNG for interface screenshots, while preserving every pixel. A palette PNG can be smaller still for simple diagrams with few colors. SVG remains the right answer for logos and icons: it scales without extra bytes, but only if the artwork is actually vector rather than an embedded bitmap. ## Step 3: set quality at display size Lossy encoders trade detail for size. Evaluate the result at the size users see, not at 200 percent zoom. A practical workflow: 1. Encode at a moderate quality. 2. Compare the encoded image with the source at display size. 3. Lower the quality until a difference appears, then step back one level. 4. Check file size. 5. Repeat for the formats you plan to ship. For screenshots, text and line art, use lossless WebP or PNG. Lossy compression creates ringing around sharp edges and makes text harder to read. Quality numbers are not portable between codecs. JPEG quality 80, WebP quality 75 and AVIF quality 55 can produce similar visual results at very different byte counts, because each encoder defines its scale differently. Never copy a quality value from one format to another and assume it means the same thing. Start from a visual target, encode a few candidates, and compare. What to look for depends on the content. In photos, inspect smooth gradients for banding and high-contrast edges for mosquito noise; both appear when the bitrate is too low. JPEG usually applies 4:2:0 chroma subsampling, which is fine for skin tones but can smear saturated reds and thin colored lines. At quality 90 versus 75, the file often grows 1.5–2 times for a difference most viewers cannot see at display size. That is the wrong trade for a content image, though it may be right for a product photo where zoom is expected. Objective metrics help rank candidates, not decide for you. SSIM and VMAF correlate with perception on video and photos but miss text artifacts; a quick visual A/B at the real display size plus a byte budget is more reliable than chasing a single score. ## Step 4: strip what you do not need Images often carry metadata that is not needed on the web: - EXIF camera data. - Thumbnails. - Color profiles, if the image does not need them. - Copyright or location data that should not be public. Some converters remove metadata by default; others preserve it. Check the output. If a color profile is required for accurate colors, keep it and verify the result in a browser. Orientation is the trap. Phone photos often store pixels in one orientation and an EXIF `Orientation` tag that tells the viewer to rotate them. If you strip metadata without applying the rotation first, the image can arrive sideways. Most browser-based encoders apply orientation during decode, but command-line pipelines and older libraries do not. Re-encode one portrait photo and inspect it before batch-processing a folder. An ICC profile is usually one to three kilobytes, but wide-gamut profiles can be larger. If the image is destined for the web and colors look correct after conversion to sRGB, converting and dropping the original profile is safe. If the brand color must match a print reference, keep the profile and test in Safari as well as Chrome, because color management differs between browsers and operating systems. ## Step 5: serve the right format with a fallback Use the `picture` element to offer modern formats without breaking older browsers: ```html Dashboard preview ``` The `img` provides the fallback and the alt text. Set `width` and `height` to reserve space and prevent layout shift. The browser evaluates `source` elements in order and picks the first type it supports, so put AVIF first, WebP second and the JPEG fallback in `img`. It does not compare file sizes for you. If you also need responsive widths, combine the format choice with `srcset` and `sizes` on each source; otherwise a phone may download the same 1600-pixel AVIF as a desktop. The `type` attribute is what enables negotiation; without it, the browser will happily download a format it cannot decode. Do not preload every candidate. Preloading all three formats makes the browser fetch files it will never use. Preload only the LCP image, and only the format most of your traffic will select, or let the preload scanner find the `img` naturally. `fetchpriority="high"` on the fallback `img` is usually enough. ## Core Web Vitals Images affect the largest contentful paint (LCP) and cumulative layout shift (CLS): - The LCP image should be served in a modern format at the right size. - Do not lazy-load the LCP image; use `fetchpriority="high"`. - Set dimensions or an aspect ratio to prevent layout shift. - Avoid enormous images that compete with interaction work. A smaller file is not automatically better if the image is blurry or if the browser must download several sources. Measure the actual page. Use the field thresholds as guardrails: LCP should be at or below 2.5 seconds for most visits, and CLS should stay below 0.1. Product photos, hero banners and article lead images are frequently the LCP element, so their bytes and their discovery time both matter. Lazy-loading the hero pushes discovery until after layout and is one of the most common self-inflicted LCP regressions. Below-the-fold images are different: lazy-loading them is usually correct. `decoding="async"` keeps image decoding off the main thread during layout, but it is not a loading priority. It does not make a large image arrive sooner. Conversely, `loading="eager"` alone does not guarantee priority; combine it with `fetchpriority="high"` on the one image that matters. Do not set high priority on a carousel of five images; competing hints cancel each other out. CLS is simpler to prevent than to fix. Reserving space with `width` and `height`, or with a CSS `aspect-ratio`, stops the reflow when the image loads. If the image is inserted into a container with no intrinsic size, set a minimum height as a fallback. ## Verify the result After compression, check: 1. The image looks correct at display size. 2. Text and sharp edges are readable. 3. Transparency is preserved. 4. The color profile and orientation are correct. 5. The file size is lower than the source. 6. The page still passes its Core Web Vitals checks. The [image compressor](/tools/image-compressor) resizes and compresses in the browser without uploading the file. Use [PNG to WebP](/tools/png-to-webp) or [JPG to WebP](/tools/jpg-to-webp) for format changes, and [AVIF to PNG](/tools/avif-to-png) when you need a compatible source. The [WebP to PNG](/tools/webp-to-png) converter is useful when a downstream tool does not accept WebP. Verify with the browser cache disabled and network throttling on, because a locally cached 2 MB image feels identical to a 40 KB one. Check the exact rendered size in the DevTools element panel, then inspect it on a DPR 2 screen if your audience uses one. Open the result in Safari and Firefox, not only Chrome; color profiles and AVIF decoding can differ. Finally, look at a gradient and a text edge, the two places where compression artifacts appear first. ## Common mistakes - Compressing a 4000-pixel image instead of resizing it. - Using JPEG for screenshots with text. - Using PNG for large photos. - Judging quality at 200 percent zoom. - Removing the color profile and changing the colors. - Forgetting `width` and `height`, causing layout shift. - Lazy-loading the hero image and hurting LCP. - Re-compressing an already compressed JPEG and losing another generation of detail. Compression is a sequence of decisions, not a single slider. Resize, choose the format, set quality at display size, and verify the result. There are cases where the standard advice is wrong. If an image is smaller than about 10 KB, the container and metadata overhead can outweigh the gain from switching formats; leave it alone. If your CDN or image service negotiates AVIF and WebP from one upload, do not hand-generate every variant, because you will duplicate work and drift out of sync. If the page is text-only and images are decorative, optimizing a 12 KB icon will not move LCP; spend the effort on fonts and scripts instead. And if you need exact pixel values, as in medical or archival imaging, lossy compression is not a quality trade at all; use lossless formats and verify checksums rather than eyeballing a slider. ## Frequently asked questions ### Does compressing an image reduce its dimensions? Not necessarily. Compression reduces the number of bytes used to store the pixels; resizing reduces the number of pixels. Resize first when the image is larger than the layout, then compress the smaller image. ### What quality setting should I use? There is no universal value. Start around 70-80 for photos, compare at the display size, and lower it only if the visual difference is acceptable. Screenshots and text usually need lossless settings. ### Is WebP always smaller than JPEG? Not always, but it often is at comparable quality. Measure the actual files. AVIF can be smaller again, especially for photos, but encoding is slower and older browsers need a fallback. ### Why did my image become blurry after compression? Lossy compression removes detail. If the image contains text, sharp edges or line art, use PNG or lossless WebP. If it is a photo, compare at the display size and raise the quality if needed. ### Do I need to keep the original image? Yes. Keep the highest-quality source outside the deployed assets so you can re-encode for new formats, sizes or quality settings without starting from a compressed file. ## References - [web.dev - Image optimization](https://web.dev/learn/images/) - [MDN - Image file type and format guide](https://developer.mozilla.org/en-US/docs/Web/Media/Guides/Formats/Image_types) - [web.dev - Optimize LCP](https://web.dev/articles/optimize-lcp) - [Can I Use - AVIF](https://caniuse.com/avif) --- - Canonical: https://www.jsonmind.com/guides/compress-images-for-web - Locale: en - Published: 2026-11-10 - Updated: 2026-11-10 - Tools: image-compressor, png-to-webp, jpg-to-webp, avif-to-png, webp-to-png