Image Compression Best Practices:
Reduce File Size Without Losing Quality

Compression Basics

Image compression is the process of reducing file size while maintaining acceptable visual quality. There are two main approaches: lossy and lossless compression, each with different trade-offs.

At a technical level, uncompressed raster images store one color value per pixel. A modest 1920×1080 photograph in 24-bit color requires roughly 6 MB of raw data before any encoding. Compression algorithms exploit two facts about images: neighboring pixels often share similar colors (spatial redundancy), and the human visual system is more sensitive to brightness differences than to color differences (perceptual redundancy). By discarding or compactly representing repeated patterns, codecs can cut that 6 MB file down to a few hundred kilobytes with little or no visible quality loss.

Images are often the single largest contributor to page weight on modern websites. According to HTTP Archive data, images account for more than 50% of the average page's total transfer size. Even a single over-sized hero image can add multiple seconds to the time-to-interactive on a mobile connection. Understanding how compression works — and making informed choices — is therefore one of the highest-leverage optimizations a developer or designer can make.

Lossy vs Lossless Compression

Lossy compression works by discarding information the human eye is least likely to notice. JPEG, for instance, converts image data into the frequency domain using the Discrete Cosine Transform, then aggressively rounds the high-frequency components (fine detail, sharp edges) that humans are less sensitive to. The lower the quality setting, the more rounding occurs, and the more pronounced the block artifacts become. The key insight is that there is a diminishing-returns curve: moving from quality 95 to quality 85 may cut file size by 60% while the visible difference is almost imperceptible; moving from 85 to 75 cuts another 30% with a small but still acceptable quality loss; but dropping from 70 to 50 often produces ugly blocky artifacts while only saving an additional 15–20% of file size.

Lossless compression works differently: it finds and encodes patterns without throwing anything away. PNG uses DEFLATE compression (a combination of LZ77 and Huffman coding) to identify repeating byte sequences. This is why a flat-color logo compresses dramatically — large areas of identical pixels collapse into a tiny description of the pattern — while a detailed photograph barely shrinks at all. WebP in lossless mode uses a more advanced prediction coding scheme that typically beats PNG by 20–30%.

The right choice depends on what is in the image, not just how you prefer to work. A rule of thumb: use lossy compression for anything that looks like a photograph (continuous-tone images with gradients, skin tones, sky, foliage) and lossless for anything that looks like it was drawn or designed (flat colors, hard edges, text rendered onto a background). If an image mixes both — for example a product photo on a transparent background — WebP or AVIF let you keep transparency while still applying lossy encoding to the photographic portion.

JPEG Optimization Strategies

The quality slider is the most visible control in any JPEG encoder, but understanding the diminishing-returns curve makes it much easier to use. Between quality 85 and quality 100 you are spending a lot of bytes to preserve details that are invisible on most screens. Between quality 75 and quality 85 the trade-off is nearly perfect — you get a file that is roughly half the size of the quality-95 version while the image looks indistinguishable to the naked eye on a calibrated monitor. Below quality 60 the encoder starts throwing away low-frequency information that is clearly visible, and the familiar "JPEG blocks" appear around high-contrast edges. The sweet spot for most web images is quality 78–85 depending on the subject matter.

Chroma subsampling is a frequently overlooked optimization. JPEG internally converts RGB pixel data to a luminance-plus-chrominance color space (YCbCr) and then optionally stores color at half or quarter the resolution of brightness. Because human vision is far better at detecting brightness differences than color differences, this produces minimal visible change while cutting color data in half. Most encoders default to 4:2:0 subsampling, which is ideal for natural photographs. For images containing fine colored text or sharp colored lines (such as screenshots with colored UI chrome), 4:4:4 (no subsampling) preserves edge quality at the cost of a moderately larger file.

WebP & AVIF: Modern Compression

WebP was developed by Google as a successor to both JPEG and PNG. Its lossy mode is based on the VP8 video codec's intra-frame coding, which outperforms JPEG's DCT approach particularly for images with smooth gradients and fine textures. Its lossless mode uses a novel palette-based prediction coding that beats PNG by an average of 26% according to Google's original research. For web images that do not require HDR or very high bit-depth, WebP is the safest modern choice: it is supported in every major browser released since 2020, and the conversion toolchain is mature.

AVIF is derived from the AV1 video codec and represents the current state of the art in still-image compression. At the same perceived quality, AVIF files are typically 40–55% smaller than WebP and 60–70% smaller than JPEG. AVIF's encoder is computationally expensive, which can make it slow to generate at build time, but the resulting files load dramatically faster for end users. AVIF also natively supports wide color gamuts (P3, Rec. 2020) and HDR content, making it the right choice for photography sites or any context where image fidelity is paramount. Browser support passed 70% in 2024 and continues to grow, making it a worthwhile addition to a progressive-enhancement strategy.

<picture>
  <source srcset="image.avif" type="image/avif">
  <source srcset="image.webp" type="image/webp">
  <img src="image.jpg" alt="Description" loading="lazy">
</picture>

Resize to the Display Size Before Compressing

One of the most common and costly mistakes developers make is uploading a 4000×3000 pixel photograph and then using CSS to display it at 800×600. The browser downloads every single one of those 12 million pixels and then immediately discards three-quarters of them during rendering. You have paid the download cost for 12 MP but only displayed 1.8 MP. The fix is straightforward: resize the image on the server or in your build pipeline to match the largest size it will ever be displayed, before running any compression pass.

When sizing for the web, account for device pixel ratios. A CSS width of 400px on a 2× retina display actually renders at 800 physical pixels. The practical implication is that you should provide images at roughly 2× the CSS size for high-DPI displays, but not necessarily 3× or 4×. Beyond 2× the improvement in perceived sharpness is negligible because display pixels are already small enough that the eye cannot resolve individual dots. For a hero image with a max CSS width of 1200px, preparing a 2400px-wide version covers virtually every device without wasting bandwidth on larger sizes.

Resizing before compressing also dramatically improves the compression ratio. A compressor working on a downscaled image has fewer pixels to encode and can dedicate more of its bit budget to representing those pixels accurately. The result is both a smaller file and better visible quality at the target display size compared to serving an over-sized image that the browser scales down.

Practical Compression Strategies

Metadata stripping deserves particular attention because it is both easy to do and often ignored. A JPEG straight out of a modern smartphone can carry 30–80 KB of EXIF metadata: GPS coordinates accurate to a few meters, the device make and model, the lens aperture, shutter speed, ISO, a thumbnail of the original image, embedded ICC color profiles, and sometimes proprietary camera manufacturer data. None of this information is rendered by browsers, yet every byte of it must be downloaded. Stripping metadata before publishing is also a privacy best practice — location data embedded in an image can reveal where a photo was taken, which may not be information you want to share publicly.

One piece of metadata worth keeping is an embedded color profile (ICC profile) when you need accurate color on calibrated displays. The sRGB profile is tiny (about 2 KB) and ensures the image renders consistently across different devices and browsers. For general web use, if you know the image is already in sRGB you can strip the profile and save those bytes. For photography sites or any context where color accuracy matters, keep the profile embedded.

Choosing the right format is often the single biggest optimization available. Many developers default to JPEG for all photographs and PNG for everything else, but the optimal choice depends on the specific image content. A screenshot of a website should almost always be PNG or lossless WebP because it contains sharp text and solid-color UI elements that would produce ugly artifacts with lossy JPEG compression. A product photograph on a white background should be JPEG or lossy WebP. A product photo on a transparent background should be lossless WebP or PNG. Animated content should use animated WebP instead of GIF, which can be 10–20× larger for the same visual content.

Responsive Images and srcset

Serving a single image size to every device wastes bandwidth. A visitor on a 320px-wide phone does not need a 2400px hero image; they only need a 640px one (at 2× pixel density). The HTML srcset attribute and the sizes attribute together let the browser select the most appropriate image from a set of candidates you specify, without any JavaScript required. This mechanism can cut mobile image download sizes by 70–80% compared to serving the desktop-optimized version to all devices.

<picture>
  <source
    type="image/avif"
    srcset="hero-640.avif 640w,
            hero-1280.avif 1280w,
            hero-2400.avif 2400w"
    sizes="100vw"
  />
  <source
    type="image/webp"
    srcset="hero-640.webp 640w,
            hero-1280.webp 1280w,
            hero-2400.webp 2400w"
    sizes="100vw"
  />
  <img
    src="hero-1280.jpg"
    srcset="hero-640.jpg 640w,
            hero-1280.jpg 1280w,
            hero-2400.jpg 2400w"
    sizes="100vw"
    alt="Hero image"
    loading="lazy"
    width="2400"
    height="1350"
  />
</picture>

The sizes attribute does not have to be a simple viewport width. For images that are constrained inside a content column, you might write sizes="(max-width: 768px) 100vw, 740px", which tells the browser: "on screens narrower than 768px this image takes the full width; otherwise it is 740 pixels wide." Armed with that information and the srcset list of available widths, the browser can pick the smallest candidate that will look sharp.

Lazy loading is a complementary technique. Adding loading="lazy" to any img element that is not in the initial viewport tells the browser to defer downloading it until the user scrolls near. On image-heavy pages like product listings or photo galleries, lazy loading can reduce the initial page load by hundreds of kilobytes. Always include explicit width and height attributes on images even when using lazy loading, so the browser can reserve the correct space before the image downloads and avoid layout shift.

A Practical Step-by-Step Workflow

A repeatable workflow turns image optimization from a chore you do inconsistently into a reliable part of your production process. Here is a workflow that covers the most important optimizations in the right order.

Common mistakes to avoid: re-compressing an already-compressed JPEG (each pass through a lossy encoder accumulates artifacts — always compress from the original high-quality source); serving PNG for photographs (a PNG of a natural photo is typically 5–10× larger than the equivalent JPEG); using GIF for animation (animated WebP is dramatically smaller); and neglecting to test on a real mobile device on a throttled connection, which is where the gains are most visible.

Automation & Tools

Integrating compression into your build pipeline ensures that no un-optimized image ever reaches production. Tools like sharp (a Node.js library) and libvips provide high-performance image resizing and format conversion at build time, while CDN-based image transformation services such as Cloudinary and Imgix can perform on-the-fly resizing and format negotiation so you only store the original master file and let the CDN serve the right variant for each request. For teams without an existing build pipeline, a dedicated browser-based tool that handles compression locally — without uploading originals to a third-party server — provides the fastest path to optimized output.

Performance Impact & Metrics

Google's Core Web Vitals framework directly links image optimization to search ranking. The Largest Contentful Paint (LCP) metric measures how long it takes for the largest visible element — almost always a hero image — to fully load. A score below 2.5 seconds is considered "good," while anything above 4 seconds is flagged as "poor" and will negatively affect your search visibility. Industry data consistently shows that optimizing images to be served in modern formats with correct sizing is the most impactful single change you can make to improve LCP.

Perceptual quality metrics like SSIM (Structural Similarity Index) and VMAF can be used to objectively compare compressed images to their originals without relying on side-by-side visual comparison. An SSIM score above 0.95 is generally considered visually lossless. These metrics are especially useful when you need to automate quality validation — for example, as a CI/CD step that rejects any image where the compressed output drops below an SSIM threshold.

Conclusion