Image compression: the complete guide to lossy vs lossless

Every digital image you see online has been compressed. The photo on the news article you just read, the product image you zoomed in on, the avatar in someone's comment — all compressed. Compression is what makes it economically and technically feasible to serve billions of images across the web every day. Understanding how it works helps you make better decisions about file formats, quality settings, and when compression artefacts are acceptable versus damaging.

What is image compression?

An uncompressed image stores every pixel as a fixed number of bits — typically 24 bits (8 bits per colour channel for red, green, and blue). A 1920×1080 photograph at 24 bits per pixel contains roughly 6.2 million pixels, which works out to approximately 186 million bits, or about 22 MB. That's the raw, uncompressed data that lives in memory when an image is open on your screen.

Image compression is the process of reducing that 22 MB down to something practical for storage and transmission — typically 200 KB to 2 MB for a web photograph — by encoding the pixel data more cleverly. There are two fundamentally different approaches: lossy compression, which achieves smaller sizes by permanently discarding some image data, and lossless compression, which reduces file size without discarding any information at all.

Understanding the difference between these two approaches — and knowing which formats use which — is the foundation of making good decisions about image quality and file size for any project.

Lossy compression explained

Lossy compression works by exploiting weaknesses and biases in human visual perception. The idea is that the eye and brain do not perceive all visual information equally — we are far more sensitive to changes in brightness than to changes in colour, we are more sensitive to broad gradients than to fine high-frequency detail, and we are better at detecting changes in large uniform areas than at detecting subtle texture variations in complex scenes.

JPG — the most widely used lossy format — uses a technique called DCT (Discrete Cosine Transform). The image is divided into 8×8 pixel blocks. Each block is transformed from pixel values into a mathematical representation of its frequency content — essentially, how much the block contains of large-scale gradients versus fine detail. High-frequency components (fine detail) are then quantised more aggressively than low-frequency components (broad gradients), because the human eye is less sensitive to high-frequency variations. The quality setting controls how aggressively this quantisation is applied.

Here is what a 5 MB RAW photograph becomes at various JPG quality settings:

• Quality 100 (maximum): approximately 5 MB — nearly the full data, minimal compression
• Quality 90: approximately 1.8 MB — excellent quality, barely distinguishable from 100
• Quality 85: approximately 1.2 MB — recommended for high-quality web use
• Quality 75: approximately 600 KB — very good quality, minor artefacts only visible at 100% zoom
• Quality 60: approximately 300 KB — noticeable artefacts, especially on smooth gradients and edges
• Quality 50: approximately 150–200 KB — visible blocking, smearing, and colour banding

The key characteristic of lossy compression is that it is irreversible. Once you save a JPG at quality 80, the data that was discarded is gone forever. If you later save that same file again at quality 80, you're compressing an already-degraded image — the quality loss compounds, and the result is worse than the original quality-80 save. This is why you should always keep the original high-quality source file and only export the compressed version for use.

Lossless compression explained

Lossless compression reduces file size without discarding any image data whatsoever. The output is mathematically identical to the input — decode a losslessly compressed image a thousand times, and you get the exact same pixel values every single time. There are no artefacts, no quality degradation, no trade-offs in visual fidelity.

Lossless algorithms work by finding and exploiting redundancies in the data itself. Several techniques are commonly used:

• Run-length encoding (RLE): Replaces repeated sequences with a count and a single value. A row of 500 white pixels becomes "500 × white" rather than 500 separate values — a huge saving for simple graphics.
• LZW (Lempel–Ziv–Welch): Builds a dictionary of repeated data patterns and replaces them with shorter codes. Used in GIF and TIFF.
• DEFLATE: Combines LZ77 compression with Huffman coding. Used in PNG and ZIP files. Extremely efficient for images with large areas of identical or similar colour.
• Prediction coding: Predicts each pixel's value based on neighbouring pixels, then encodes only the difference (the "residual"). Used in PNG and lossless WebP.

The trade-off is that lossless compression has a ceiling. Natural photographs contain enormous amounts of apparent randomness — variations in colour, texture, and detail at every scale — that don't compress well under lossless algorithms. A photographic PNG is often 3–5× larger than the equivalent quality-85 JPG. This is why PNG is not the right choice for photographs on the web, and why JPG exists at all.

Lossless compression is ideal for images that do have large areas of identical or predictable data: logos, icons, illustrations, screenshots, UI mockups, and images containing text. These compress extremely well losslessly and would look terrible with lossy compression because the sharp edges and flat colours are exactly the features JPG's 8×8 block structure handles worst.

Which formats use which type?

Different image formats are tied to specific compression approaches — some support only one type, others offer both:

The rise of WebP and AVIF as dual-mode formats is significant: they eliminate the historical trade-off between "lossy for photos" and "lossless for graphics." A single format can now handle both cases with better compression than the legacy formats it replaces, which simplifies image pipelines considerably.

The quality setting in JPG compression

Most image editors and compression tools expose a quality slider for JPG and WebP, typically on a scale of 1–100 (or sometimes 0–100). This number controls how aggressively the DCT coefficients are quantised — essentially, how much fine detail is discarded in the name of a smaller file.

The relationship between quality setting and file size is not linear. Moving from quality 100 to quality 90 can cut file size in half with almost no visible impact. Moving from quality 70 to quality 60 produces a much smaller incremental size saving but may introduce clearly visible artefacts. The relationship is roughly logarithmic: each step down the quality scale produces diminishing returns in file size savings but accelerating quality damage.

A practical breakdown for web use:

• Quality 90–95: Near-lossless appearance. Still substantially smaller than quality 100. Use when image quality is paramount and file size is secondary — photography portfolios, print-quality proofs.
• Quality 80–85: The standard recommendation for web images. Files are 60–70% smaller than quality 100 with differences that are essentially imperceptible at normal display sizes on standard screens. This is the sweet spot for most use cases.
• Quality 70–79: Noticeably smaller files. Artefacts are visible on close inspection at 100% zoom but typically invisible at normal web display sizes. Acceptable for thumbnails, image previews, and low-priority background images.
• Quality 60–69: Aggressive compression. Blocking artefacts become visible at normal display sizes, especially on smooth colour gradients, skin tones, blue skies, and areas with high contrast edges. Generally avoid for anything the viewer is meant to engage with.
• Below quality 60: Heavy artefacts. Obvious 8×8 pixel blocking, colour smearing, and loss of fine detail. Only appropriate when file size is extremely constrained and quality is genuinely secondary — icon thumbnails, low-bandwidth previews for progressive loading.

Chroma subsampling — the hidden compression most people miss

Beyond the quality slider, JPG (and some WebP and HEIC encodings) apply a second, largely hidden form of compression called chroma subsampling. This technique exploits a fundamental property of human vision: our eyes are much more sensitive to variations in brightness (luminance) than to variations in colour (chrominance).

JPG separates image data into one luminance channel (Y) and two colour channels (Cb and Cr). Chroma subsampling reduces the resolution of the colour channels independently of the luminance channel. Three subsampling ratios are commonly used:

• 4:4:4 (no subsampling): Full colour resolution is preserved. The colour channels are stored at the same resolution as the luminance channel. File sizes are largest, colour accuracy is highest. Used when colour fidelity is critical.
• 4:2:2 (horizontal subsampling): Colour channels are stored at half the horizontal resolution. Barely visible in most images, but can affect images with fine horizontal colour transitions — for example, a red text character on a green background rendered at small sizes.
• 4:2:0 (full subsampling): Colour channels are stored at half resolution in both horizontal and vertical directions — one quarter of full resolution. This is the default for most consumer JPEG encoders and many web compression tools. It produces the smallest files but can cause visible colour smearing around sharp colour transitions, fine red or blue details, and text with colour.

For most photographs, 4:2:0 subsampling is completely invisible in practice. Where it matters is for images with text, logos, or sharp colour boundaries at small sizes. If you're compressing an image that contains coloured text or fine colour detail, switching to 4:4:4 or 4:2:2 subsampling will improve colour accuracy at the cost of a slightly larger file.

Compression artefacts — what to look for

Artefacts are the visual defects introduced by lossy compression. Knowing what to look for helps you calibrate your quality settings more confidently.

JPG blocking: The most recognisable JPG artefact. Because JPG compresses in 8×8 pixel blocks, aggressive compression makes those block boundaries visible as a grid of subtle rectangles, particularly in smooth areas like blue skies, skin, and gradients. Increasing quality to 75+ typically eliminates visible blocking at normal screen sizes.

Ringing (or "mosquito noise"): Appears as a bright or dark halo or fringe around sharp edges — most visible around text, logo outlines, and high-contrast transitions. Caused by the DCT transformation over-representing high-frequency edge content. Particularly problematic for screenshots containing text compressed as JPG rather than PNG.

Colour banding: Appears in gradients as a stepped, posterised effect instead of a smooth transition. Can be caused by both lossy compression and by saving gradients with too few colours (common with GIF or low-colour PNG).

Colour smearing: Caused primarily by 4:2:0 chroma subsampling — fine colour details bleed into surrounding areas, making sharp red, blue, or cyan details look softer or shifted.

WebP artefacts at similar quality settings tend to look softer and less blocky than JPG artefacts — more like blur than rectangular blocking. AVIF artefacts at heavy compression are even more natural-looking, degrading as smooth smearing rather than geometric patterns. This is part of why both newer formats are preferred over JPG at aggressive compression settings.

Practical compression recommendations

Cutting through the theory, here are the practical settings that work for the most common web image use cases in 2026:

• Photographs for blog posts and articles: WebP at quality 80–85. Target under 150 KB per image. This gives excellent visual quality with substantial bandwidth savings.
• Hero images and banner photos: WebP at quality 80–85, resized to a maximum of 1920 px wide. Target under 300 KB. Apply lazy loading to hero images below the fold.
• Product images (e-commerce): WebP at quality 85–90. Slightly higher quality is worth the extra file size when the image is the primary decision factor for purchase. Consider AVIF with WebP fallback for further savings at the same quality.
• Thumbnails and card images: WebP at quality 75–80. These are displayed small, so slightly more aggressive compression is acceptable. Target under 50 KB.
• Logos, icons, illustrations with flat colour: PNG (lossless) or SVG. Never JPG. The blocking and ringing artefacts from lossy compression on flat-colour graphics are very obvious.
• Screenshots containing text: PNG. The lossless encoding preserves text sharpness. WebP lossless is a smaller alternative if PNG is too large.
• Backgrounds and decorative images: WebP at quality 70–75. These receive less visual scrutiny. Push compression harder here to save bandwidth.

How to compress images without visible quality loss

Getting good compression results is as much about workflow as about settings. Here are the practices that produce consistently clean results:

1. Always start from the original source file. Never compress an already-compressed image if you can avoid it. Each lossy compression step compounds quality loss. If you have to re-export, start from the highest-quality version you have.
2. Resize to display dimensions before compressing. Compressing a 4000 px image down to 200 KB is wasteful — you're encoding millions of pixels that will never be displayed. Resize to 1200–1400 px wide first, then compress. The file size difference is enormous.
3. Convert to WebP for better results at any given file size. At quality 80, WebP consistently produces smaller files than JPG at equivalent or better quality. If you're currently exporting JPGs, switching to WebP alone often reduces file sizes by 30–35% with no quality change.
4. Evaluate the output visually at 100% zoom. A quality number tells you the encoder setting, not the actual output quality, which varies by image content. Look at the output at full size before committing to a setting.
5. Keep originals in a separate, uncompressed archive. Once you've set up a compression workflow, keep the full-resolution original files completely separate from your compressed web exports.

Compression and Core Web Vitals

Image compression has a direct, measurable impact on Google's Core Web Vitals metrics, which are used as search ranking signals. The most affected metric is Largest Contentful Paint (LCP), which measures how quickly the largest visible element on the page — usually a hero image or banner — loads and becomes visible to the user.

Google's threshold for a "good" LCP score is under 2.5 seconds. A 3 MB unoptimised JPG hero image on a typical mobile connection (averaging around 10–15 Mbps in practice) will take 1.5–3 seconds just for the image alone, without accounting for DNS, TLS handshake, HTML parsing, and CSS rendering. A properly compressed WebP version of the same image at 150–200 KB loads in under 0.15 seconds — a 10–20× difference.

Practical file size targets for Core Web Vitals:

• Hero / LCP images: Target under 200 KB. This is the single highest-impact optimisation for most websites' LCP scores.
• Inline blog and article images: Target under 100 KB.
• Thumbnails and card images: Target under 50 KB.
• Icons and small UI imagery: Target under 20 KB; use SVG where possible.

LCP is also affected by whether the browser discovers the image early. Ensure hero images are referenced directly in the HTML (not loaded via JavaScript or CSS background-image) and add a <link rel="preload"> tag in the document head to prompt the browser to start fetching the image as early as possible in the loading sequence.