Image Compressor topic guide

Why does my image look blurry on my website

Direct answer

An image looks blurry on a website when the file the browser receives does not match the slot it fills. The common causes are: serving a smaller image than the slot needs so the browser upscales it, not shipping a 2x retina file for high-DPI displays, using a lossy format on graphics with text or fine detail, or letting CSS scale a small image up to fill a hero slot. Each cause has a different fix — resize to the actual display size, ship both 1x and 2x versions, switch to a lossless format, or replace the source — and the first step is identifying which cause is at work in the actual page.

Try the Image Compressor

What this workflow handles

Sharpness on screen is a function of pixels, not file size. A 4000 by 3000 JPEG served in a 1920 by 1080 hero slot looks crisp because the browser has more pixels than it needs and downsamples; the same JPEG served in a 6000 by 4000 slot looks soft because the browser is upscaling and inventing pixels. web.dev's responsive images guide ties the served width to the rendered display width via srcset and sizes, and Chrome for Developers' Properly size images Lighthouse audit flags the inverse — intrinsic dimensions much larger than the rendered slot. The device-pixel ratio is the second axis: a 1920 pixel wide slot on a 2x retina display needs a 3840 pixel wide file to look sharp, which is what web.dev means by shipping a 2x image. The third axis is the format and quality: a JPEG at quality 60 shows block artefacts that read as fuzziness around text and edges, and any lossy format smears fine detail in graphics. MDN's image format guide and the Pillow JPEG handbook are the references for the encoder behaviour.

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 live page in a real browser at the actual display size (desktop, mobile, retina, non-retina) and inspect the blurry image. Note the rendered width and height in the browser's developer tools.
  2. Compare the rendered slot to the intrinsic dimensions of the served file. If the served file is smaller than the slot, the browser is upscaling — the cause is undersize at serve time.
  3. Check whether the served file has a 2x retina variant. Open the page on a 2x or 3x device-pixel-ratio display, or use the browser's device toolbar; a soft result on retina is the missing-2x symptom.
  4. Check the format. A JPEG used for a logo, a screenshot, a UI mockup, or any content with text or sharp edges will read as fuzzy because JPEG drops high-frequency detail. Switch to PNG (lossless) or WebP lossless for that content type.
  5. Check the source itself. If the original image was small and was upscaled before being saved, no amount of re-saving will recover the missing detail. Find a higher-resolution original, or replace the image with one that was captured or exported at the right size.
  6. Fix the root cause (resize to the slot, add a 2x variant, switch format, replace the source), then reload the page in a real browser and verify the result at the actual display size. The check is visual at the actual pixel density, not a file size number.

Common mistakes

  • Re-saving a small image at a larger pixel count and expecting it to become sharp. Re-saving does not invent pixels. Upscaling a small image produces a larger file that is no sharper than the original, just bigger in bytes. The Pillow handbook notes that resampling filters smooth the new pixels but do not recover detail that was not in the source. Find a higher-resolution original or replace the image instead.
  • Shipping one image file and expecting it to look sharp on every device. A 1x file shipped without a 2x variant will look soft on a 2x or 3x display because the browser is rendering one source pixel across multiple device pixels. web.dev's responsive images guide recommends shipping both a 1x and a 2x variant via srcset so the browser can pick the right file for the device-pixel ratio. A single file is not enough on a mixed-device audience.
  • Saving a logo, screenshot or UI mockup as JPEG because the byte count looked smaller. JPEG is the wrong format for graphics with sharp edges, text or flat colour — the 8 by 8 block compression smears edges and makes small text fuzzy. PNG (lossless) or WebP lossless keeps every pixel exactly as it was and is the correct format for this content; the MDN image format guide describes this trade-off directly. Pick the format by content type, not by file size on a single sample.
  • Letting CSS scale the image with width: 100% and height: auto instead of shipping the right pixel dimensions. CSS can scale an image up visually, but it does not add pixels — it stretches the existing pixels across a larger box, and the result reads as soft. Chrome for Developers' Properly size images Lighthouse audit flags exactly this case. The fix is to serve a file at the actual rendered size (plus the 2x variant), not to rely on CSS to scale the source up.

Check the output

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

  • Intrinsic vs rendered dimensions. Open the live page in a browser and read the <img> element's naturalWidth / naturalHeight in the developer tools panel; compare those to the rendered width and height of the element. If the intrinsic dimensions are smaller than the rendered slot, the browser is upscaling the file and the image will look soft. The fix is to serve a file at least as large as the rendered slot (plus the 2x retina variant for high-DPI displays).
  • 2x retina variant. Open the page on a 2x or 3x device-pixel-ratio display (or use the browser's device toolbar set to a retina profile) and look at the same image. If it is sharp on a 1x display and soft on a 2x display, the page is missing a 2x variant in srcset. web.dev's responsive images guide covers the srcset / sizes pattern; the fix is to ship a 2x image alongside the 1x and let the browser pick.
  • Format vs content type. Open the file and look at any text, sharp edges, or thin lines. If the image is a logo, screenshot, UI mockup or graphic with text and is saved as JPEG, the 8 by 8 block compression smears the edges and reads as fuzziness. Save the source as PNG (lossless) or WebP lossless instead — the MDN image format guide describes this as the right choice for graphics with sharp edges.
  • Source resolution. Open the source image you uploaded to the website. If its pixel dimensions are far smaller than the rendered slot on the live page, the source was undersize to begin with and re-saving it at a larger pixel count cannot recover the missing detail. The fix is to find a higher-resolution original or replace the image with one captured or exported at the right size.

Frequently asked questions

Why does my image look blurry on my website?

Four common causes: the served image is smaller than the display slot (browser scaling), no 2x retina version is being served for high-DPI displays, the source was upscaled before being saved, or a lossy format was used on content with text or fine detail. Open the served file at the actual display size and compare its pixel dimensions to the rendered slot in the page; a mismatch means the browser is doing the scaling, and that is the most common cause of a blurry website image.

What makes an image look pixelated or fuzzy online?

Pixelation is the visible square blocks that appear when a small image is stretched to a larger slot — the browser has to invent intermediate pixels and they read as a checkerboard. Fuzziness is the loss of crisp edges when a JPEG or other lossy format is pushed past its useful quality range, or when an encoder drops high-frequency detail. The Pillow handbook describes the JPEG quality scale and the threshold where block artefacts become visible.

Why does my image look blurry on mobile but fine on desktop?

Two likely causes. First, the file may not have a 2x variant in srcset, so on a 2x or 3x device-pixel-ratio display the browser is rendering a 1x file at the device's higher physical resolution and the result is soft. Second, mobile browsers may serve the page in a narrower column than desktop, and a file sized for the desktop slot can end up displayed at a size where the encoder's lost detail becomes visible. web.dev's responsive images guide and the WHATWG HTML Living Standard cover both cases.

Does saving as higher resolution fix a blurry image?

Only if the source is genuinely higher resolution than the file you are currently serving. Re-saving the same small image at a larger pixel count cannot invent the pixels that were never captured — the upscaled file is no sharper than the original, just bigger in bytes. The Pillow handbook describes the resize filters and notes that upscaling does not recover detail that was not in the source. Find a higher-resolution original or replace the image rather than re-saving the small one at a larger size.

Does Retina / 2x display make images blurry?

Not by itself — it makes any image not shipped at 2x look blurry. A 2x display has twice the physical pixels per CSS pixel, so a 500 CSS pixel wide slot needs a 1000 physical pixel wide file to render one source pixel per device pixel. web.dev's responsive images guide recommends shipping a 2x variant via srcset so the browser can pick the right file for the device. Without a 2x variant, every image on a retina display will look soft.

Can a JPEG look blurry even at high quality?

Yes. JPEG is lossy by design and discards high-frequency detail during encoding, so fine edges, text and texture are never pixel-identical to the source no matter how high the quality setting. For graphics with text, sharp edges or transparency, PNG (lossless) or WebP lossless is the right choice; the MDN image format guide describes this as the fundamental trade-off between lossless fidelity and lossy byte saving. JPEG is the right format for photographs where the loss is invisible at quality 80 and above.

How do I fix a blurry image on my website?

Find the cause first. If the served file is smaller than the rendered slot, resize the source up to the slot size (including the 2x retina slot) with a Beita Image resizer, then re-encode at a balanced quality with the Image Compressor. If the source itself is small, find a higher-resolution original — you cannot sharpen a low-resolution image by re-saving. If the format is wrong for the content, switch a JPEG logo or UI screenshot to PNG (lossless) or WebP lossless. After each fix, reload the page in a real browser at the actual display size and check the result against the same slot in the design.

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 tell if an image is over-compressed

    An over-compressed image shows visible JPEG block artefacts, ringing around edges, colour banding in gradients and smearing of sharp text. A practical checklist for spotting each symptom at the actual display size, plus when to re-encode at higher quality or switch format. Backed by MDN, web.dev, Pillow and Chrome for Developers.

  • Responsive images: serve the right size for every device

    Responsive images let one HTML element serve different pixel-sized files to different devices, so a phone does not download a 2000-pixel-wide desktop photo. The pattern uses the srcset and sizes attributes on <img>, or the <picture> element with multiple <source> children. Backed by MDN, web.dev and the WHATWG HTML Living Standard.

  • 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.

  • Image file size vs dimensions: why pixels do not equal bytes

    A 500 by 500 image can be larger in bytes than a 2000 by 2000 image. File size depends on pixel dimensions, compression format, quality setting, colour depth and image complexity — not dimensions alone. A practical explanation with sources from MDN, web.dev and Pillow.

  • 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.

  • 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.

All image compressor guides