Image Compressor topic guide

How to tell if an image is over-compressed

Direct answer

Open the output file at its real display size and look for four symptoms: 8 by 8 pixel block patterns in flat areas, halos or ringing around sharp edges, visible colour bands in smooth gradients, and smearing of small text or fine detail. Each symptom maps to a known compression behaviour, and each has a different fix — raise the quality, switch to a lossless format, or resize the source down before re-encoding. The Pillow handbook, the MDN image format guide, the Chrome for Developers Lighthouse audits and the web.dev image optimization guides are the canonical references.

Try the Image Compressor

What this workflow handles

There are four visual symptoms, and each tells you a different thing about how the file was compressed. 8 by 8 block patterns in flat areas are a sign the JPEG quality was set too low — the JPEG encoder works on 8 by 8 pixel blocks and at low quality the boundaries between blocks become visible. Ringing or halos around sharp edges are a separate artefact from the same encoder — high-frequency detail is being truncated during the discrete cosine transform. Colour banding in smooth gradients (sky, soft skin, product backgrounds) is a sign the colour depth or chroma subsampling was too aggressive. Smearing of small text or thin lines is a sign a lossy format was used on content that needs lossless encoding — text, line art, UI screenshots and logos. The MDN image format guide lists lossless vs lossy as the fundamental distinction between PNG and JPEG; the Pillow handbook describes the JPEG quality scale and the WebP lossless mode; Chrome for Developers' Efficiently encode images Lighthouse audit flags any file where a more efficient encoder could save roughly 4 KiB or more; and web.dev's image optimization guide treats over-compression as a quality regression to be avoided rather than a target.

Use the image compressor to re-encode a single image in its original format at the same pixel dimensions, then compare the byte counts in the result panel before keeping the output.

How to use it

  1. Open the compressed output file at its actual display size — a full-screen preview, the live web page, or the real social feed slot. Do not judge from a thumbnail or from a design tool zoomed above the display size.
  2. Look at a flat area first — sky, plain background, uniform wall. Visible 8 by 8 pixel grid patterns in flat colour mean the JPEG quality was too low and the file is over-compressed.
  3. Look at the edges of any sharp objects in the image — text, leaves, product outlines, UI elements. Ringing or halos around the edges mean high-frequency detail was dropped by the lossy encoder.
  4. Look at any smooth gradient in the image — sky, soft skin, product background. Visible colour bands instead of a smooth transition mean the colour depth or chroma subsampling was too aggressive.
  5. If any symptom is visible, re-encode the original source at a higher quality (Pillow quality 80 to 85 for JPEG or WebP) or switch to a lossless format (PNG for graphics with sharp edges, WebP lossless for photographs that need maximum fidelity).
  6. Re-check the new output at the actual display size. If the symptoms are gone, the new file is good; if they remain, the source itself may already be over-compressed and the fix is to find a higher-quality original.

Common mistakes

  • Judging compression quality from the file size instead of the image. A smaller file is not automatically an over-compressed file. The right comparison is the actual visual quality at the actual display size, not the byte count on disk. A 200 KB JPEG at quality 85 can look identical to a 500 KB version at quality 95; a 50 KB version at quality 60 may show block artefacts on the same image. The Chrome for Developers Efficiently encode images audit flags files where a more efficient encoder could save bytes, but never recommends lowering the quality past the visible-artefact threshold.
  • Re-encoding an already-compressed file at a higher quality. Re-encoding the compressed output at a higher quality produces a larger file that is still missing the detail the previous encode discarded. The discarded pixels cannot be recovered. The Pillow handbook and web.dev image optimization guide both treat the original source as the only place to re-encode from — never re-encode from an already-compressed intermediate.
  • Saving a screenshot or UI graphic as JPEG because the byte count looked better. JPEG is the wrong format for graphics with sharp edges, text or flat colour — the 8 by 8 block compression smears the edges and makes small text fuzzy. PNG (lossless) or WebP lossless is the right choice; the MDN image format guide describes this as the fundamental PNG vs JPEG trade-off. Pick the format by content type, not by file size on a single sample.
  • Trusting the encoder's quality number instead of the output. Quality 80 on Pillow's 0 to 100 scale and quality 80 on another tool's scale can mean different things; some scales top out below 100, some use 1 to 100. The Pillow handbook is the canonical reference for Pillow's own JPEG quality parameter. The right check is always the actual output at the actual display size, not the number on the slider.

Check the output

After running the workflow, verify these four things on the actual file before you upload it anywhere.

  • Block patterns in flat areas. Look at a flat colour region — clear sky, plain background, uniform wall. If you can see an 8 by 8 pixel grid pattern, the JPEG encoder ran at too low a quality and the file is over-compressed. The Pillow handbook and MDN image format guide both describe the 8 by 8 block boundary as the artefact that appears when JPEG quality drops below the useful range.
  • Ringing around sharp edges. Look at the edges of text, leaves, product outlines and UI elements. A halo, ghost outline or oscillation next to a sharp edge is ringing from the lossy encoder truncating high-frequency detail. The Pillow handbook notes that this becomes more visible as the quality setting decreases.
  • Colour banding in gradients. Look at smooth gradients — sky, soft skin, product backgrounds. Visible colour steps instead of a smooth transition mean the colour depth or chroma subsampling was too aggressive. Higher quality or a less aggressive subsampling ratio (4:4:4 instead of 4:2:0) usually removes the bands.
  • Smearing of small text or fine detail. Look at small text, thin lines, hair and fabric texture. If text looks fuzzy, lines look thick, or fine detail is blurred, a lossy format was used on content that needed lossless. Re-encode the source as PNG or WebP lossless instead — the MDN image format guide treats lossless as the right choice for graphics with sharp edges and transparency.

Frequently asked questions

How do I know if my JPEG is over-compressed?

Open the file at its actual display size and look at a flat area (a clear sky, a plain background, a uniform wall). If you can see an 8 by 8 pixel grid pattern in the flat area, the JPEG quality was set too low. JPEG works on 8 by 8 pixel blocks and at low quality the boundaries between blocks become visible — that is the over-compression signal the Pillow handbook and MDN's image format guide both describe.

What do JPEG compression artefacts look like?

Four common symptoms: 8 by 8 block patterns in flat colour areas, halos or ringing around sharp edges (the encoder dropped high-frequency detail), colour banding in smooth gradients (the colour depth or chroma subsampling was too aggressive), and smearing of small text or thin lines (a lossy format was used on content that needs lossless). Each symptom has a different fix; the Pillow handbook and MDN image format guide cover the encoder behaviours behind each.

At what quality does JPEG look bad?

There is no single threshold that fits every image, but the Pillow handbook's JPEG documentation and the existing Pillow-based compressors on the web settle on quality 75 to 85 on the 0 to 100 scale as the balanced range for photographs. Below quality 60 the 8 by 8 block artefacts become visible at normal viewing distance; above quality 90 the file grows much larger for almost no visible gain. Always check the actual file at the actual display size rather than trusting a number.

Can a PNG be over-compressed?

PNG itself is lossless and cannot be over-compressed in the same way — PNG preserves every pixel exactly, so there are no block artefacts or colour bands. The trap with PNG is different: a PNG can be much larger than the same image as JPEG or WebP for content where lossy compression would be invisible (photographs, soft gradients). The MDN image format guide describes this as the trade-off between lossless fidelity and lossy byte saving. Use PNG for graphics with sharp edges or transparency; use JPEG or WebP for photographs.

How do I fix an over-compressed image?

Re-encode the source file at a higher quality setting, or switch to a lossless or modern format. For a JPEG, re-save the original at Pillow quality 80 or above with the optimize flag on. For a graphic with sharp edges that was wrongly saved as JPEG, switch to PNG (lossless) or WebP lossless. For a photograph where the byte budget still matters, switch to WebP or AVIF at quality 80 to 85. Re-encoding an already-compressed JPEG cannot restore the pixels the previous encode already discarded.

Does re-encoding fix over-compression?

Only if you re-encode from the original source or from a higher-quality intermediate. The pixels a lossy encode already discarded are gone and cannot be recovered from the output file. Re-encoding the compressed output at a higher quality setting produces a larger file that is still missing the discarded detail. The Pillow handbook and web.dev image optimization guide both treat the original source as the only place to re-encode from.

Sources

Explore the image compressor topic cluster

Each guide answers a different image-decision question. Pick the one that matches your situation, then use the linked tool to produce the output you need.

Related guides

  • How to optimize images for the web

    Optimizing an image for the web is a four-step decision chain: pick the format that matches the content, resize to the actual display size, re-encode at a balanced quality, and serve the result with a modern-format fallback. A practical guide backed by web.dev, MDN, Chrome for Developers Lighthouse audits, and the Pillow documentation.

  • JPEG vs PNG vs WebP: how to choose the right image format

    JPEG, PNG and WebP are not interchangeable. The right choice depends on what is in the image, whether it needs transparency, the file-size budget, and where the image will be displayed. A practical decision guide backed by MDN, Google Developers, web.dev, the WHATWG HTML Living Standard and the Pillow documentation.

  • Resize vs Compress: which one actually shrinks your image

    Resizing changes the pixel dimensions of an image; compression keeps the dimensions and re-encodes the file at a smaller byte count. Pick resize when the source is larger than the display size, and compression when the dimensions are right but the bytes are still too high. Backed by Chrome for Developers' two Lighthouse audits and the Pillow documentation.

  • JPEG vs PNG: which format should you actually use

    JPEG is lossy and intended for photos; PNG is lossless and carries an alpha channel, so it is the right format for graphics, screenshots and anything that needs transparency. Pick by content type, not by file size. Backed by MDN, WHATWG and the Pillow documentation.

  • Why is my image still large after compression

    Your image may still be large after compression because the source was already optimized, the format is inefficient for the content type, the dimensions are too large for the destination, or the quality setting is too high. A troubleshooting guide with actionable checks from MDN, web.dev and Chrome for Developers.

All image compressor guides