How to reduce image size without losing visible quality

Images are often the heaviest part of a web page, and a single unoptimized photo can outweigh all of a page's HTML, CSS and JavaScript put together. The good news is that most of that weight is invisible: pixels nobody sees and detail the eye can't detect. Removing it makes pages faster, especially on phones and mobile connections, without making them look any worse.

Reducing image size comes down to four things: the right dimensions, the right format, sensible compression, and the right loading behavior.

Find your heaviest images first

Open your browser's developer tools, go to the Network tab, filter by "Img", reload the page and sort by size. The biggest files are where you'll save the most. Rudra's website speed checker runs Lighthouse on the page and lists the audits that didn't pass, which include image audits (such as oversized or poorly compressed images) when they apply. On full-site crawls, Rudra also flags images without width and height attributes and pages that load more than ten images without lazy loading.

How to reduce image size, step by step

1. Resize to the size it's displayed at

This is usually the biggest win. A 4000-pixel-wide photo shown in an 800-pixel column carries around 25 times more pixels than it needs. Find the largest size the image is actually displayed at (inspect it in developer tools), and export it at that width, or up to twice that width for sharpness on high-density screens. Shrinking an image with CSS doesn't reduce the download; the full file is still sent.

2. Choose the right format

• JPEG: photographs and complex images, when you need maximum compatibility.
• PNG: images that need lossless quality or transparency with sharp edges, such as screenshots of interfaces or diagrams with few colors. PNG is a poor choice for photos.
• WebP: supported by all current major browsers, and typically smaller than JPEG or PNG at similar visual quality. Handles transparency and animation too.
• AVIF: often smaller again than WebP at the same visual quality, and supported by all current major browsers, though it's slower to encode.
• SVG: logos, icons and simple illustrations. It's vector-based, so it stays sharp at any size and is often tiny.
• Video instead of GIF: an animated GIF is usually many times larger than the same clip as an MP4 or WebM video. Use <video autoplay muted loop playsinline>.

3. Compress, and check with your eyes

Lossy formats (JPEG, WebP, AVIF) let you trade file size against quality. For photos, a quality setting in the 70–85 range is a common starting point that often looks the same as the original, but the right value depends on the image, so compare the result at actual size. Also strip metadata such as camera details and GPS location, which adds weight and can reveal more than you intend. Useful tools:

• Squoosh (in the browser): compare formats and quality levels side by side, one image at a time.
• ImageOptim (macOS) or similar desktop tools: drag in a folder for lossless and lossy optimization.
• Command line: cwebp -q 80 photo.jpg -o photo.webp converts to WebP; magick photo.jpg -resize 1600x -quality 80 photo-1600.jpg resizes and recompresses with ImageMagick.
• In a build pipeline: libraries such as sharp (Node.js) can resize and convert every image automatically at build or upload time.

4. Serve different sizes to different screens

A phone shouldn't download the image sized for a large desktop monitor. With srcset and sizes, the browser picks the smallest file that will look sharp:

<img src="hero-800.jpg" srcset="hero-400.jpg 400w, hero-800.jpg 800w, hero-1600.jpg 1600w" sizes="(min-width: 1024px) 800px, 100vw" width="1600" height="900" alt="Hikers crossing a ridge at sunrise">

srcset lists the files and their widths; sizes tells the browser how wide the image will be displayed (800 pixels on large screens, the full viewport width otherwise). To offer modern formats with a fallback, wrap the image in <picture> with a <source type="image/avif" srcset="..."> and a <source type="image/webp" srcset="..."> before the <img>; browsers use the first format they support.

5. Lazy-load images below the fold, but not the hero

Add loading="lazy" to images further down the page, and the browser will only fetch them as the visitor scrolls near them. Don't lazy-load the main image at the top of the page: it's often the Largest Contentful Paint element, and delaying it makes the page feel slower. For that image, consider fetchpriority="high" so the browser fetches it early.

6. Always set width and height

Width and height attributes let the browser reserve the right space before the image arrives, so text doesn't jump when it loads, which is a common cause of layout shift (CLS). Set them to the image's intrinsic size, and keep images fluid with img { max-width: 100%; height: auto; } in your CSS.

7. Automate it

Manual optimization doesn't survive the next upload. Let your platform do it: WordPress generates several sizes of each uploaded image and adds srcset automatically, and optimization plugins can add compression and WebP or AVIF conversion; the Next.js <Image> component resizes, converts and lazy-loads by default; and image CDNs transform images on the fly from URL parameters. Pair this with long cache lifetimes for image files so returning visitors don't download them again.

Common mistakes

• Lazy-loading the hero image, which delays the most important content.
• Uploading full-resolution camera or phone photos and letting CSS shrink them.
• Saving photographs as PNG.
• Putting important images in CSS backgrounds, where the browser discovers them late and they can't have alt text.
• Re-compressing an already compressed JPEG again and again, which adds visible artifacts each time.
• Forgetting width and height, and causing layout shift.
• Over-compressing product photos until the detail customers want to see is gone.

What tools can and can't judge

Automated audits are good at spotting images that are larger than their display size, missing modern formats or missing dimensions, and they estimate how much you could save. They can't tell you whether a compressed image still looks good enough for its purpose. A blog illustration can take heavy compression; a product photo or a portfolio piece may not. Make the final call by eye.