Image Compressor topic guide

Responsive images: serve the right size for every device

Direct answer

Responsive images is the pattern of letting one HTML element serve different pixel-sized files to different devices, so a phone does not download a 2000-pixel-wide desktop photo when it will only display a 400-pixel slot. The HTML side has two main tools: the srcset and sizes attributes on <img>, and the <picture> element with multiple <source> children. The image side has to produce the multiple sizes in the first place, which is what the Image Compressor and the resizers on this site are for. MDN, web.dev and the WHATWG HTML Living Standard are the canonical references for the markup; Chrome for Developers' Properly size images Lighthouse audit is the first-party check that the byte savings are real.

Try the Image Compressor

What this workflow handles

There are three jobs that have to be done together. First, decide which display widths the image actually needs - a mobile thumbnail, a tablet card, a desktop hero - and generate one file per slot. Second, write the srcset and sizes attributes that tell the browser which file to pick, or use a <picture> element if you also need to switch formats (WebP, AVIF) or crop the image differently per breakpoint (art direction). Third, always set width and height attributes on the <img> so the browser can reserve layout space before the file loads and avoid the layout shift that hurts Largest Contentful Paint. web.dev's Use responsive images article and MDN's Responsive images guide walk the markup in detail; the WHATWG HTML Living Standard describes the exact parsing rules a browser follows when it picks a source.

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. Decide which display widths the image actually needs - a mobile thumbnail, a tablet card, a desktop hero - and write them down as concrete pixel widths including the 2x retina slot.
  2. Generate one image file per slot at the exact pixel width you wrote down. Use the Image Compressor for the encode and the resizers (Social Media Image Resizer, product resizers) when the slot is a known platform target.
  3. Write the srcset and sizes attributes on the <img> element. srcset lists each file with its intrinsic width (for example 'photo-640.jpg 640w, photo-1280.jpg 1280w'), and sizes describes the rendered display width at each breakpoint.
  4. If you also want to serve a modern format (WebP, AVIF) with a JPEG or PNG fallback, wrap the <img> in a <picture> element with one <source type='image/webp'> per slot and a final <img> fallback.
  5. Set width and height attributes on the <img> element so the browser reserves layout space before the file loads, and add loading='lazy' to any image that is not in the first viewport.

Frequently asked questions

What is a responsive image?

A responsive image is one HTML element that the browser can swap to a different pixel-sized file depending on the device, viewport width or pixel density. The srcset attribute lists the available files and their intrinsic widths, the sizes attribute describes the rendered display width for each breakpoint, and the browser picks the closest match. MDN's Responsive images guide is the canonical reference for the markup.

What is the difference between srcset and the <picture> element?

srcset is an attribute on <img> that lets the browser pick between different files of the same image based on viewport width and pixel density. The <picture> element is a wrapper that can do everything srcset does, plus art direction (a different crop or aspect ratio at different breakpoints) and format negotiation (AVIF for modern browsers, WebP as fallback, JPEG as last resort). web.dev recommends <picture> for format negotiation and srcset for size negotiation. They are not mutually exclusive: a <picture> can contain an <img> with srcset.

How many image sizes should I generate?

There is no fixed answer - it depends on how many breakpoints the layout has and how much device variation the audience shows. web.dev's guide suggests a small ladder of common widths (for example 640, 960, 1280 and 1920 pixels) and the browser will pick the closest one. Generating every possible width wastes encode time; generating too few breaks the savings. A resizer that takes a single source and outputs a named ladder (image-640.jpg, image-960.jpg, image-1280.jpg, image-1920.jpg) is the practical shape of the file set.

Do I really need a 2x retina version?

On a high-density display (most modern phones, many laptops), one CSS pixel is backed by more than one device pixel, so a 400 CSS-pixel image needs roughly 800 actual pixels to look sharp. The srcset attribute handles this with the density descriptor: 'image-400.jpg 1x, image-800.jpg 2x' tells the browser to fetch the 800-pixel file on a 2x display and the 400-pixel file on a 1x display. MDN's Responsive images guide describes density descriptors as one of two resolution hints, the other being width descriptors.

Should I lazy-load responsive images?

Yes for any image below the fold. The HTML loading='lazy' attribute tells the browser to defer fetching until the image is close to the viewport, and Chrome for Developers' Lazy loading images Lighthouse audit flags images that should use it. Do not lazy-load the first hero image - it should be eager so it renders immediately, and do not lazy-load above-the-fold images on a slow connection where they would race the initial paint.

Do width and height attributes matter?

Yes - setting width and height on the <img> element lets the browser reserve the right amount of layout space before the image loads, which prevents the layout shift that hurts Cumulative Layout Shift and Largest Contentful Paint. The WHATWG HTML Living Standard describes width and height as the mechanism browsers use to compute the aspect ratio for layout before the image bytes arrive. Always set both, even when the actual file served is a different size from the attribute values.

How does responsive images affect SEO?

Indirectly, by improving the page experience signals Google uses. Google Search Central's image best practices call out fast-loading pages and stable layout as positive signals, and Core Web Vitals (which depend on image bytes and on layout stability) feed into the page experience system Google uses. Smaller image payloads also make the page easier for Google's crawler to fetch and index. The direct ranking levers for an individual image are descriptive file names, alt text and the surrounding page context, all of which are unchanged by the responsive pattern.

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.

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

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

  • 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 alt text and SEO: how to write alt text Google Images can use

    Alt text is the value of the alt attribute on an <img> element. Google Images uses alt text together with the file name and the surrounding page text to understand what an image shows. A practical guide grounded in Google Search Central, MDN and the WHATWG HTML Living Standard.

All image compressor guides