Updated: June 18, 2026
Your compressed image usually looks blurry because the export removed too much fine detail, resized the image with a soft algorithm, blurred color edges through chroma subsampling, or compressed an already-compressed file again. Start by checking the image at 100% zoom, then match the problem to its cause: soft or mushy edges suggest a low quality setting or a bad resize algorithm; fuzzy red or blue text points to chroma subsampling; blocky or banded flat areas indicate aggressive or repeated lossy compression. Each cause has a different fix, and you rarely need all four at once.
Key Takeaways
- Quality settings in the mid-70s or lower often produce visible artifacts on detailed photos, especially after resizing or repeated saves. Start around 80–85 for JPEG web photos and inspect at 100% zoom.
- Chroma subsampling (4:2:0) blurs colored edges first — red text, logos, UI screenshots. Use 4:4:4 or PNG/lossless WebP for graphics with text.
- Resampling matters as much as the codec. Use Lanczos or bicubic for downscaling photos; bilinear and nearest-neighbor produce soft results.
- Compress once from a lossless master. Each re-save of a lossy file compounds the quality loss.
- Modern formats often preserve more detail. WebP and AVIF can produce better visual quality than JPEG at similar file sizes, depending on content and encoder.
Quick Diagnosis: Match the Artifact to the Fix
Use this table to identify the cause from what you see, then jump to the matching section.
| What you see | Likely cause | Quick fix | Best format |
|---|---|---|---|
| Soft or mushy edges across the whole image | Quality setting too low | Raise quality to 80–85, re-export from master | JPEG, WebP, AVIF |
| Fuzzy color fringing around red/blue text or logos | 4:2:0 chroma subsampling | Export with 4:4:4 or use lossless format | PNG, WebP lossless |
| Image looks soft before you compress it | Bad resampling algorithm during resize | Re-resize with Lanczos or bicubic | Any |
| Visible 8x8 blocks or banding in skies/walls | Aggressive or repeated lossy compression | Re-export from lossless master at higher quality | JPEG, WebP, AVIF |
| Everything looks fine at small sizes but blurry when zoomed | CSS scaling — image is smaller than its displayed size | Serve an image at native or 2× resolution | Any |
The Most Common Reasons Compressed Images Look Blurry
1. Quality setting is too low
Many export tools expose a 0–100 quality control for JPEG, WebP, and AVIF, but the same number does not mean the same visual quality across formats — each encoder uses the scale differently. Below the mid-70s range, most encoders start aggressively quantizing the data that encodes fine detail (the high-frequency DCT coefficients), producing the classic mosquito noise around edges and 8x8 blocking inside flat areas (Wikipedia: Compression artifact).
Many practical image-optimization guides use 80–85 as a starting range for JPEG web photos — the point where additional quality often stops being visible at normal viewing distances. Start there, inspect at 100% zoom, and adjust based on your specific image and encoder.
| Quality range | Typical use | What you often see |
|---|---|---|
| 95–100 | Print, archival masters | Indistinguishable from source; large files |
| 80–85 | Web photos, blog hero images | Usually no visible loss at normal viewing distance |
| 70–79 | Thumbnails, low-stakes feeds | Slight softness on close inspection |
| Below 70 | Avoid for content images | Visible blocking, mushy edges, mosquito noise |
2. Chroma subsampling is smudging your colors
Human eyes resolve brightness much better than color, so JPEG and many other lossy encoders store color at a lower resolution than luminance — a technique called chroma subsampling. The default for most JPEG encoders is 4:2:0, which means the two color channels are stored at half the width and height of the luminance channel. This is generally fine for skin tones and skies, but it hurts saturated edges (RED Digital Cinema: Chroma Subsampling).
You will recognize this artifact:
- Red text on a white background looks fringed or smeared.
- Colored UI buttons in a screenshot get a soft halo.
- Brand logos lose their crisp edge.
Fix: Export with 4:4:4 subsampling so every pixel retains its own color information. If your export tool does not expose chroma subsampling settings, use PNG or lossless WebP for text-heavy graphics instead of lossy JPEG.
3. The resize step used the wrong algorithm
This is the cause people miss most often, because it happens before the compressor runs. If you resize a camera photo from 4000 px wide down to 1200 px using nearest neighbor or bilinear interpolation, the output is already soft before a single byte is compressed. Lanczos (also called Lanczos3) reconstructs edges more accurately during downscaling and is the preferred algorithm for photo reduction in tools like Pillow, ImageMagick, Sharp, and libvips.
| Algorithm | Best for | Sharpness on downscale |
|---|---|---|
| Nearest neighbor | Pixel art only | Hard aliasing; poor for photos |
| Bilinear | Real-time or preview use | Noticeably soft |
| Bicubic | General purpose | Good balance, slight softening |
| Lanczos (Lanczos3) | Photo downscale | Sharpest; mild ringing only on extreme edges |
For substantial downscaling, a light unsharp mask applied after resizing helps recover micro-contrast. Start with a low radius (around 0.3 px) and a modest amount, and judge the result by eye at 100% zoom rather than following a fixed formula — the right values depend on image content and the amount of downscale (Cambridge in Colour: Image Sharpening).
4. The image has been compressed more than once
Every lossy save re-quantizes the image data and re-applies chroma subsampling, compounding the errors from previous saves. A typical scenario: shoot in RAW, export to JPEG for editing, run through a CMS that auto-resizes on upload, then share on social media — each step is another lossy pass (Photo StackExchange: repeated subsampling).
The rule is simple: keep a lossless master (PSD, TIFF, PNG, or RAW) and compress once into the format the page actually serves.
A Workflow That Keeps Images Sharp
- Start from the highest-quality source you have. Camera RAW, PSD, TIFF, or original PNG — never a previously exported JPEG.
- Resize to the pixel dimensions your layout needs, using Lanczos. If your hero image displays at 1200 px CSS width and you serve a 2× retina version, target 2400 px.
- Apply a light unsharp mask after resizing to recover edge contrast. Keep the radius low (around 0.3 px) and judge the amount by eye at 100% zoom.
- Pick the right format (web.dev: choose the right image format):
- AVIF for photos where broad browser support is acceptable.
- WebP as the broadly supported modern default.
- JPEG as a fallback for older environments.
- PNG or WebP lossless for screenshots, logos, and anything with text.
- Start with quality 80–85 for lossy photo formats. Lower only after visually inspecting at 100% zoom.
- Use 4:4:4 chroma for images with crisp colored edges — logos, UI captures, infographics.
- Compress once and ship. Do not run an already-optimized file through another optimizer.
After exporting from your master file, you can run the result through LessMB, then compare it with your original at 100% zoom before publishing.
Recommended Settings by Image Type
| Image type | Format | Quality starting point | Chroma | Notes |
|---|---|---|---|---|
| Web photo / hero image | WebP or AVIF | 80–85 | 4:2:0 acceptable | Inspect at 100%; use Lanczos for any resize |
| Screenshot (with UI text) | PNG or WebP lossless | N/A (lossless) | N/A | Lossy compression visibly blurs text |
| Logo / icon / text graphic | PNG or WebP lossless | N/A (lossless) | N/A | Avoid JPEG entirely |
| Thumbnail | WebP or JPEG | 75–80 | 4:2:0 | Small display size hides more compression |
| Infographic | PNG or WebP lossless | N/A (lossless) | N/A | Mix of text and detail; lossless is safer |
What Not to Do
- Do not download an image from social media and then re-compress it — you are starting from an already-lossy source.
- Do not open an exported JPEG in an image editor and re-save it as JPEG again; always work from the lossless master.
- Do not use CSS to stretch a small image to a larger display size; serve the image at the right resolution instead.
- Do not run an already-optimized file through a second optimizer.
How to Verify the Fix
Open the original and the compressed copy at 100% zoom — not "fit to screen," which hides most quality problems. Check in order:
- Edges of high-contrast features (text, window frames, eyelashes). Still soft? Quality is too low or the resize used a soft algorithm.
- Saturated colored borders. Fringed or smeared? Chroma subsampling.
- Flat regions (sky, walls, backgrounds). Banded or blocky? Aggressive or repeated lossy compression.
- Natural size vs. displayed size. Open DevTools and compare the image's natural pixel dimensions with its rendered size. A 600 px image stretched to 1200 px looks blurry regardless of compression quality.
Pre-publish checklist:
- Inspected at 100% zoom on both desktop and mobile
- Natural dimensions match or exceed the largest rendered size (including 2× retina)
- Exported once, from the lossless master
- Format matches image type (lossless for text/logos, lossy for photos)
- No CSS scaling applied to cover an undersized image
When Compression Is Not the Real Cause
Two situations where what looks like compression blur is actually something else:
- Camera or motion blur in the source. Compression cannot create sharpness that was never captured. Open the original at 100% — if it is already soft, no export setting will help. Recapture or accept the result.
- CSS scaling. A 600 px image stretched to 1200 px in the browser looks blurry regardless of compression quality. Inspect the rendered size versus the natural size in browser DevTools (MDN: Responsive images).
Further Reading
- Compression artifact — Wikipedia
- Choose the right image format — web.dev
- Image Sharpening — Cambridge in Colour
- Chroma Subsampling — RED Digital Cinema
- Responsive images — MDN
- Is WebP really better than JPEG? — siipo.la
FAQ
Why does my image look blurry only after I compress it?
Compression removes high-frequency detail to reduce file size. The most common causes are a quality setting that is too low, 4:2:0 chroma subsampling smudging colored edges, or a resize step that used a soft algorithm like bilinear. Identify which artifact you see — soft edges, color fringing, or blocky flat areas — then apply the matching fix from the diagnosis table above.
What JPEG quality setting avoids visible blur?
Starting around 80–85 is a widely used guideline for JPEG web photos. Always inspect the result at 100% zoom, because the right setting depends on image content, encoder, and viewing size.
Does WebP or AVIF look sharper than JPEG at the same file size?
Modern formats like WebP and AVIF often preserve more detail than JPEG at similar file sizes, but the difference depends on image content and the encoder. Switching to a more efficient format can be a better option than pushing JPEG quality lower, which risks visible blocking and mosquito noise.
Why do red text and colored logos go fuzzy after compression?
Most JPEG encoders default to 4:2:0 chroma subsampling, which stores color channels at lower resolution than luminance. Saturated edges — red on white, blue on yellow — are affected first. Re-export with 4:4:4 subsampling if your tool supports it, or use PNG or lossless WebP for graphics with text.
Can I un-blur an already compressed image?
Not fully. Lossy compression permanently discards data. A mild unsharp mask can reduce the visible softness, but the right fix is to re-export from the original lossless master with better settings.
Why does compressing the same image twice make it worse?
Each lossy save re-quantizes the image data and re-applies chroma subsampling, so errors compound. Always keep a lossless master and compress once into the format you actually serve.
Why does my image look blurry after uploading it to a website or CMS?
Many platforms — WordPress, Instagram, Facebook, Slack — automatically re-compress images on upload, sometimes at low quality settings or with aggressive resizing. This is a second lossy pass on top of any compression you already applied. Upload the highest-quality version your platform accepts and let the platform handle the single compression step.
Should I resize before or after compression?
Resize first, to the exact pixel dimensions your layout needs, using a high-quality algorithm like Lanczos. Then compress the resized file once. Resizing after compression adds an extra lossy step and may re-apply subsampling.
Is PNG better than JPEG for screenshots and text graphics?
Yes, for most cases. PNG is lossless, so text, interface elements, and line art stay pixel-perfect. Use JPEG or lossy WebP only for photographic screenshots where lossless file size would be prohibitive.