Variable Image Encoding: How to Optimize Responsive Images

Optimize responsive images by matching the delivered file to the image’s rendered slot and the viewer’s pixel density, then choosing a format and compression level that preserve the details that matter. Use srcset and sizes when the composition stays the same; use <picture> when you need format fallback, a different crop, or media-based source selection. There is no one best format or quality setting for every image.

1. Understand the two parts of responsive image optimization

A browser needs to know both which image content to display and which file size is appropriate. These are related but separate choices:

• Resolution switching: The image composition is the same, but the browser can choose among files with different intrinsic widths. Use srcset with w descriptors and a sizes value that describes the rendered slot.
• Art direction: The image changes composition or crop at a breakpoint, such as a tighter portrait crop on a narrow screen. Use <picture> with media conditions.
• Format selection: The browser may use a more suitable format when supported, with a fallback for the intended audience. Use ordered <source> elements inside <picture>.

Sending an image much larger than its rendered dimensions wastes transfer. Sending one too small can look soft, particularly on a high-density display. Responsive candidates let the browser select from the files you provide; it may choose a nearby candidate rather than an exact match.

2. Build a responsive image with srcset and sizes

Use width descriptors when you have files containing the same image at different intrinsic widths. The sizes attribute describes the expected CSS slot width under your layout conditions. The browser combines that slot estimate with device pixel ratio (DPR) to select a candidate.

<img
  src="/images/product-800.jpg"
  srcset="
    /images/product-400.jpg 400w,
    /images/product-800.jpg 800w,
    /images/product-1200.jpg 1200w,
    /images/product-1600.jpg 1600w
  "
  sizes="(max-width: 600px) calc(100vw - 2rem),
         (max-width: 1000px) calc(50vw - 2rem),
         480px"
  width="800"
  height="600"
  alt="A ceramic planter on a wooden table"
>

This example assumes the layout gives the image nearly the full content width on small screens, half the viewport width on medium screens, and a maximum slot of 480 CSS pixels on wide screens. Replace those estimates with the real layout measurements. The width and height attributes describe the image’s intrinsic aspect ratio and help the browser reserve space before it loads.

How to choose candidate widths

1. Measure the actual rendered slot at relevant layout breakpoints.
2. Choose a modest set of real source widths that covers those slots and the DPRs important to your audience. For example, a 480 CSS-pixel slot at DPR 2 may benefit from a candidate near 960 pixels wide.
3. Generate each candidate from the same composition without unintentionally changing its crop or aspect ratio.
4. Include candidates that cover common slot sizes, but avoid generating an excessive ladder of nearly identical files without a delivery need.
5. Check the file the browser actually selected at representative viewport widths and DPRs; the browser has only the candidates you supplied and may choose a larger or smaller neighbor.

The candidate widths in the example are illustrative, not a universal recipe. Base them on your layout, source dimensions, acceptable quality, and image pipeline.

Write sizes from the layout, not from habit

Each comma-separated sizes entry has an optional media condition followed by a slot-size length. The browser uses the first matching condition; the final entry is the default. Lengths such as 100vw, 50vw, 480px, and calc() can describe the expected width. A value of 100vw is only correct when the image really occupies the viewport width; it is often wrong for a centered page, a grid, or an image with gutters.

sizes is an estimate for source selection, not a CSS sizing rule. CSS still controls the rendered layout, for example:

img {
  display: block;
  width: 100%;
  height: auto;
}

Keep the slot estimate aligned with the CSS. If the estimate says the image is wider than its real slot, browsers may download larger candidates than needed; if it understates the slot, the selected image may look soft.

3. Use density descriptors for fixed-size images

When the image has a fixed CSS display size and you only need variants for pixel density, use x descriptors. Do not mix density descriptors and width descriptors in one candidate set. sizes applies to width-descriptor selection, not this density-based pattern.

<img
  src="/images/avatar-96.jpg"
  srcset="/images/avatar-96.jpg 1x, /images/avatar-192.jpg 2x"
  width="96"
  height="96"
  alt="Profile photo of Sam Lee"
>

Use this for genuinely fixed-size images such as an avatar. For fluid content images whose slot changes with the layout, width descriptors are generally the appropriate model.

4. Use picture for format fallback and art direction

The browser considers <source> elements in order and selects the first source whose media condition matches and whose declared type it supports. Keep an <img> inside <picture>: it provides the fallback and carries the shared alternative text and dimensions.

Offer modern formats with a fallback

<picture>
  <source
    type="image/avif"
    srcset="/images/landscape-800.avif 800w,
            /images/landscape-1200.avif 1200w"
    sizes="(max-width: 700px) 100vw, 800px"
  >
  <source
    type="image/webp"
    srcset="/images/landscape-800.webp 800w,
            /images/landscape-1200.webp 1200w"
    sizes="(max-width: 700px) 100vw, 800px"
  >
  <img
    src="/images/landscape-800.jpg"
    srcset="/images/landscape-800.jpg 800w,
            /images/landscape-1200.jpg 1200w"
    sizes="(max-width: 700px) 100vw, 800px"
    width="1200"
    height="800"
    alt="A mountain lake beneath a cloudy sky"
  >
</picture>

Here AVIF and WebP are offered before JPEG. Keep only the fallbacks that make sense for your target browser audience. Keep the corresponding dimensions and composition consistent across formats; the browser’s format choice should not accidentally change the intended crop.

Change the crop for a narrow screen

<picture>
  <source
    media="(max-width: 600px)"
    srcset="/images/team-portrait-480.jpg 480w,
            /images/team-portrait-720.jpg 720w"
    sizes="100vw"
  >
  <img
    src="/images/team-wide-1200.jpg"
    srcset="/images/team-wide-800.jpg 800w,
            /images/team-wide-1200.jpg 1200w"
    sizes="(max-width: 1000px) 100vw, 800px"
    width="1200"
    height="675"
    alt="The team gathered in its workshop"
  >
</picture>

The narrow-screen source represents a deliberately different crop. If you combine art direction with format selection, order the sources so each media and type combination expresses the intended choice, then verify the selected file in the browser. If the composition remains identical, use resolution switching instead of maintaining separate art-directed crops.

5. Choose a format for the image and audience

Format	Good fit	Trade-off to check
AVIF	Modern delivery candidate for still or animated imagery; supports transparency and higher bit depth.	Check support for your target browser audience and provide a fallback when needed. Compare visual output for the specific image.
WebP	Lossy or lossless images, transparency, and animation; broadly supported in modern browsers.	Compare file size and appearance against alternatives for your content.
JPEG	Photographs where a broadly compatible lossy fallback is useful.	Lossy encoding can damage fine detail and edges; compare at the intended display size.
PNG	Lossless reproduction or transparency when those properties matter.	For some images, WebP or AVIF may be smaller if their output remains visually suitable.
SVG	Scalable icons, interface graphics, and diagrams that are naturally vector artwork.	It is not a general replacement for raster photography.
JPEG XL	Images where its capabilities fit and the intended audience supports it.	Support is not universal; do not use it as a universal delivery default without a fallback.

WebP and AVIF can reduce bytes compared with older formats, but there is no format that wins for every image at acceptable visual quality. Browser support, transparency, animation, sharp edges, photographic detail, and the cost of producing and maintaining variants all matter. Check current compatibility for your audience before making a format your only source. See MDN’s [image format guide](https://developer.mozilla.org/en-US/docs/Web/Media/Guides/Formats/Image_types) and [picture reference](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/picture).

6. Tune compression by looking at the rendered image

Lossy compression often works well for complex photographs, but can create visible artifacts around sharp edges, line art, and text. A quality number is encoder-specific and should not be treated as a standard across formats or tools. Do not choose a quality level from file size alone.

1. Encode a representative source in candidate formats and quality levels using your chosen image tooling.
2. Compare byte size, then inspect the files at their actual rendered dimensions, including the details users need to see.
3. Check edges, gradients, small text, transparency boundaries, and any high-contrast detail likely to reveal artifacts.
4. Repeat on varied images from your site. A setting that works for one photograph may fail on a screenshot, logo, or illustration.
5. Record the chosen pipeline settings so regenerated variants remain consistent and reproducible.

Optional compression tools named in Chrome for Developers’ image delivery guidance include Squoosh, ImageOptim, and Imagemin. For a large library, an image CDN or optimization service can automate transformations and delivery; neither is required to use responsive HTML. See [Chrome’s image delivery guidance](https://developer.chrome.com/docs/performance/insights/image-delivery) and [web.dev’s image performance guide](https://web.dev/learn/performance/image-performance?hl=en).

7. Validate the real selection in a browser

1. Measure the image’s actual CSS slot at relevant breakpoints, including grid columns and page gutters.
2. Generate candidate widths that cover those slots and the pixel densities you care about.
3. Encode suitable formats and inspect visual quality at target display dimensions.
4. Add accurate sizes; add ordered <picture> sources only when format support or art direction calls for them.
5. At representative viewport widths and DPRs, inspect the requested image and selected source in browser developer tools. MDN points to Firefox Network Monitor and Chrome’s Network panel for this kind of inspection.
6. Check for layout shifts while images load. Provide accurate width and height attributes and ensure CSS preserves the intended aspect ratio.

For the broader HTML rules, see [MDN’s responsive images guide](https://developer.mozilla.org/en-US/docs/Web/HTML/Guides/Responsive_images). For the image element’s fallback and alternative text behavior, see the [MDN picture reference](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/picture).

8. Common problems and fixes

Symptom	Likely cause	Fix
The browser downloads an unnecessarily large file.	sizes overstates the slot, or the candidate set has no appropriately sized file.	Measure the rendered width under the actual layout conditions, correct sizes, and add a candidate near the needed width if the source allows.
The image looks blurry on a high-density display.	The selected candidate is too small for the slot and DPR, or the source was already soft.	Inspect the selected request and DPR; provide a sufficiently large candidate and verify the original source.
A mobile layout shows the desktop crop.	Only resolution switching was implemented, or the art-direction media condition does not match.	Use a matching <source media> with the intended crop and verify the viewport boundary.
A modern format is not used.	The browser does not support the declared type, a media condition is false, or an earlier supported source matches.	Check source order, MIME type, media conditions, and the browser’s selected request; retain an appropriate fallback.
The picture displays the wrong dimensions or layout shifts.	Fallback dimensions or CSS aspect ratio do not represent the displayed composition.	Set accurate width and height on the nested <img>; keep art-directed variants compatible with the reserved layout or manage their aspect ratios deliberately.
Edges, text, or transparency look damaged.	Lossy compression is unsuitable for the image or quality is too aggressive.	Compare lossless or alternative format output and inspect the important detail at final display size.
One image has many nearly identical variants.	Candidate widths were generated without reference to actual slots and DPRs.	Use layout measurements and observed demand to simplify the ladder while preserving useful coverage.
A deployment shows stale images after replacing files.	A cache or CDN still holds the old URL content.	Use versioned or fingerprinted asset URLs and follow the cache invalidation behavior of your delivery system.

9. Performance, reliability, and cost

Responsive images reduce unnecessary transfer when the browser can select a candidate that fits the rendered slot and display density. The result depends on accurate layout hints, useful source variants, and image content; no fixed savings figure applies across sites. Appropriate dimensions can also avoid decoding and handling a source far larger than the rendered image requires.

Reliability depends on serving every referenced candidate correctly: verify file paths, content types, caching behavior, and fallback files in the deployed environment. A missing AVIF or WebP candidate can leave the browser using a fallback if one is correctly supplied, but a broken fallback leaves no usable image. Fingerprinted URLs can help coordinate immutable caching with updated image content.

Costs include storage and delivery for multiple variants, image processing, and any optional CDN or optimization service. More variants can improve matching but increase generation, storage, and maintenance work. Start with widths justified by real slots and DPR needs; add variants when inspection shows a meaningful gap. An image CDN can automate transformation for a large library, but it is optional. Compare operational complexity along with bytes and visual quality.

10. Capture screenshots of responsive results

To review how an image appears across viewport sizes, you can capture pages at representative widths and compare the selected composition and layout. ScreenshotNeo is a website screenshot API and MCP server for developers. Its API accepts a URL in one GET request and returns an image or PDF; the product can capture at custom viewports and 12 device presets. See the ScreenshotNeo API documentation for its request options.

Or skip the browser setup

For a quick capture of a page containing your responsive image, send one request:

curl -G "https://api.screenshotneo.com/v1/shot" \
  -d access_key=YOUR_API_KEY \
  --data-urlencode url=https://example.com \
  -o responsive-review.webp

ScreenshotNeo removes cookie banners, newsletter popups, and chat widgets before the shot; bot checks, blank pages, and failed loads are never billed; its MCP server lets AI agents take screenshots; and 1,000 screenshots a month are free with no card, with paid plans starting at $5 for 3,000. Only clean shots are billed, and response headers report the page verdict and billing status. Review the API documentation for authentication and options, then sign up for 1,000 free screenshots a month with no card.

FAQ

Does srcset make an image responsive by itself?

It provides candidate files. For width-descriptor candidates, give the browser a realistic sizes estimate too, and use CSS to make the image fit the layout.

Should every image use picture?

No. Use it when you need format choice, media-based source selection, or art direction. A plain img with srcset and sizes is sufficient for many resolution-switching cases.

Can I use AVIF or WebP without a fallback?

That depends on your browser audience and support requirements. When older or unsupported browsers matter, offer an appropriate fallback and verify the selected source.

Should I convert every image to one modern format?

No. Choose based on image characteristics, acceptable appearance, browser support, and the operational cost of maintaining variants.

Sources

• MDN: Using responsive images in HTML
• MDN: Image file type and format guide
• MDN: The picture element
• Chrome for Developers: Improve image delivery
• web.dev: Image performance