Responsive Images Explained: srcset, sizes and the <picture> Element

A responsive layout can fit a phone perfectly and still make that phone download a 3,000-pixel-wide photograph. CSS controls how large an image appears, but it does not automatically change the file the browser downloads. That is where responsive images in HTML become useful.

The srcset and sizes attributes let you offer several versions of the same image. The browser then selects an appropriate candidate for the image's rendered width and the device's pixel density. The <picture> element goes further: it can provide a different crop for a narrow screen or offer AVIF and WebP with a JPEG fallback.

Used well, these features help pages load faster without making images look soft. This guide shows when to use each one and how to build a reliable workflow.

Responsive Images in HTML: The Quick Answer

Responsive images solve two related problems: displaying an image properly and downloading a suitable file.

The key distinction is simple: CSS says how the image should fit the page; responsive image HTML helps the browser decide which file to fetch.

Why One Image File Is Not Enough

Imagine a product photograph that fills an 1,200-pixel desktop content area but appears in a 360-pixel mobile layout. Sending the full desktop asset to every visitor wastes data. Sending only the small file makes the desktop version look blurry, especially on a high-density display.

Responsive images address four common needs.

Resolution switching

You provide the same composition at several pixel widths—perhaps 480, 800, 1,200 and 1,600 pixels. The browser selects a candidate that can cover the image's layout size at the device's density.

Display-density switching

A logo or avatar may always occupy a fixed 200 × 200 CSS-pixel box. A standard-density screen can use a 200-pixel file, while a 2x screen can use a 400-pixel version for extra sharpness.

Art direction

A wide banner may make sense on desktop but reduce the main subject to a tiny dot on mobile. Art direction swaps the composition itself—for example, a wide scene on desktop and a close crop on a phone.

Format selection

You may want to serve AVIF where supported, WebP as another efficient option and JPEG as a broad fallback. The picture element can describe that preference in HTML.

Before writing the markup, create source files that genuinely fit these jobs. Use the ImgTask image resizer to produce exact pixel dimensions, and keep the aspect ratio enabled unless a deliberate crop is required. Resizing a 6,000-pixel original to sensible variants removes needless pixels before compression begins.

How the HTML srcset Attribute Works

srcset is a comma-separated list of image URLs and descriptors. Each descriptor tells the browser what a candidate represents. For fluid layouts, width descriptors are usually the most practical choice.

<img
  src="article-800.webp"
  srcset="
    article-480.webp 480w,
    article-800.webp 800w,
    article-1200.webp 1200w,
    article-1600.webp 1600w
  "
  sizes="(max-width: 700px) calc(100vw - 32px), 800px"
  width="1600"
  height="900"
  alt="Designer reviewing a responsive website on a laptop and phone"
>

Here, 480w means that the first file has an intrinsic width of 480 pixels. It is not a breakpoint, a CSS rule or an instruction to display the image at 480 pixels. Every w value must match the file's real pixel width.

The browser combines the candidate list with the sizes value, viewport, zoom and device pixel density. It—not the author—makes the final selection. That flexibility is intentional: a browser may also account for information such as cached resources or network conditions, so do not assume it will always choose the exact file you expect.

Keep src even when srcset exists. It supplies a default and supports clients that do not use the responsive attributes. Google also recommends a fallback URL in src for responsive images.

Width descriptors versus density descriptors

Width descriptors end in w and describe each file's intrinsic pixel width. They work well when the rendered image width changes with the layout.

Density descriptors end in x and suit an image with a stable CSS size:

<img
  src="avatar-200.jpg"
  srcset="avatar-200.jpg 1x, avatar-400.jpg 2x"
  width="200"
  height="200"
  alt="Portrait of the article author"
>

In this example, the image occupies 200 × 200 CSS pixels. A higher-density display can choose the 400-pixel file. Do not mix w and x descriptors in one srcset; choose the model that matches the use case.

What the sizes Attribute Really Means

sizes is often the most misunderstood part of responsive images HTML. It does not describe file size, intrinsic image dimensions or the width of the user's screen. It tells the browser how wide the image's layout slot is expected to be in CSS pixels under different conditions.

Consider this value:

sizes="(max-width: 700px) calc(100vw - 32px), 800px"

It says:

• At a viewport of 700 pixels or narrower, the image occupies the viewport width minus 32 pixels of combined page padding.

• Otherwise, the image occupies an 800-pixel slot.

The browser evaluates the conditions from left to right and uses the first match. The final unconditional length is the default. The MDN responsive images guide provides the same mental model: srcset supplies candidates, while sizes describes the slot used to choose among them.

Match sizes to the real CSS layout

Suppose a card grid has one column on phones, two on tablets and three on wider screens. A starting point could be:

sizes="
  (max-width: 600px) calc(100vw - 32px),
  (max-width: 1000px) calc(50vw - 32px),
  calc(33vw - 32px)
"

The exact calculations depend on the container's maximum width, padding and gaps. Measure the rendered layout rather than copying generic values. If a desktop article column never exceeds 800 pixels, writing sizes="100vw" tells the browser that the image may span the entire viewport. On a 1,920-pixel screen, that hint can encourage an unnecessarily large download.

When srcset uses w candidates, provide a useful sizes value. Otherwise, the browser lacks the layout information it needs early in page loading. In common cases the effective fallback is based on the viewport, which can be much wider than the actual column.

When to Use the <picture> Element

Use <picture> when changing only the resolution is not enough. It is a container for zero or more <source> elements followed by an <img>. The displayed element is still the <img>; the sources give the browser alternatives.

The browser examines each source's media, type and srcset information in order. If none is usable, it uses the <img src>. The alt, loading behavior, CSS class and other presentation attributes belong on <img>, not on <source>.

Use <picture> for art direction

This example supplies a close mobile crop and a wide desktop composition:

<picture>
  <source
    media="(max-width: 700px)"
    srcset="
      hero-mobile-640.webp 640w,
      hero-mobile-960.webp 960w
    "
    sizes="100vw"
  >
  <img
    src="hero-desktop-1600.webp"
    srcset="
      hero-desktop-1200.webp 1200w,
      hero-desktop-1600.webp 1600w,
      hero-desktop-2400.webp 2400w
    "
    sizes="100vw"
    width="2400"
    height="1000"
    alt="Ceramic artist shaping a bowl beside a sunlit studio window"
  >
</picture>

The mobile files should be separately cropped assets, not merely renamed copies. Keep the important subject clear in each composition. If the crops use different aspect ratios, define the component's responsive layout carefully with CSS so content does not jump when the source changes.

Do not use media conditions just to micromanage which resolution loads. Plain srcset and sizes allow the browser to make that decision more intelligently. Reserve media on <source> for a meaningful design change.

Use <picture> for modern format fallback

The picture element can also offer multiple encodings of the same visual:

<picture>
  <source
    type="image/avif"
    srcset="photo-640.avif 640w, photo-1280.avif 1280w"
    sizes="(max-width: 700px) 100vw, 800px"
  >
  <source
    type="image/webp"
    srcset="photo-640.webp 640w, photo-1280.webp 1280w"
    sizes="(max-width: 700px) 100vw, 800px"
  >
  <img
    src="photo-1280.jpg"
    srcset="photo-640.jpg 640w, photo-1280.jpg 1280w"
    sizes="(max-width: 700px) 100vw, 800px"
    width="1280"
    height="853"
    alt="Fresh vegetables arranged on a wooden kitchen table"
    loading="lazy"
  >
</picture>

Put preferred formats first and include the correct MIME type. A browser that cannot use AVIF skips that source and considers WebP, then JPEG. To prepare the assets, you can use ImgTask's JPG to AVIF converter, JPG to WebP converter or PNG to WebP converter. For help choosing among them, read JPG vs PNG vs WebP vs AVIF.

Format selection multiplies the number of files, so use it where the savings justify the maintenance.

A Practical Responsive Image Workflow

Reliable markup begins with the layout, not with a random list of breakpoints.

1. Measure the image's rendered widths

Inspect the component at representative phone, tablet and desktop widths. Note the largest slot at each layout state. Include container padding and grid gaps. For a capped article column, you may discover that the image grows fluidly on mobile but never exceeds 800 CSS pixels on desktop.

2. Choose a small set of useful candidates

Create enough variants to avoid large jumps without producing dozens of nearly identical files. A general content image might need 480, 800, 1,200 and 1,600-pixel versions. A small card may need only 320, 640 and 960. The original must be at least as large as the biggest useful output; upscaling cannot restore detail that was never captured.

Use the online image resizer to set exact widths. Keep aspect ratio on, or crop first when the slot requires a different composition.

3. Choose the format and compress every variant

Resize first, then encode and compress. That order prevents you from spending bytes on pixels the layout never displays. Run each final candidate through the ImgTask image compressor, preview the result and stop before edges, text or fine textures visibly degrade. The guide to optimizing images for a website covers the wider workflow, while reducing image file size without losing quality explains practical compression tradeoffs.

4. Write srcset from the actual files

Confirm every candidate's pixel width and use that number as its w descriptor. A file named photo-800.webp is not necessarily 800 pixels wide—verify it. Incorrect descriptors can lead the browser to make a poor choice.

5. Translate the CSS into sizes

Describe the slot rather than the source. Match the order of layout changes and finish with a default length. Revisit sizes whenever the component's max width, grid columns or page padding changes.

6. Preserve layout and accessibility

Add width and height using the image's intrinsic aspect ratio. Browsers can then reserve space before the image arrives, reducing layout movement. MDN recommends explicit dimensions for avoiding layout shift.

Write alt text that communicates the image's purpose in context. Use alt="" for a purely decorative image so assistive technology can ignore it. Responsive markup does not change the normal accessibility rules.

7. Set loading behavior deliberately

Use loading="lazy" for images well below the initial viewport. Do not lazily load the main above-the-fold hero or another likely Largest Contentful Paint image; delaying it can hurt perceived performance. Responsive selection and lazy loading solve different problems and can be used independently.

How to Optimize Images for Mobile Without Sacrificing Quality

Mobile optimization is not simply making an image look narrower with CSS. A strong implementation combines several decisions:

• Offer lower-width candidates so small layouts avoid desktop-scale files.

• Keep enough resolution for high-density screens; a 360-CSS-pixel slot may reasonably need a candidate near 720 physical pixels.

• Use an art-directed crop when the wide version hides the subject.

• Compress each candidate rather than assuming resizing alone makes it efficient.

• Describe the true slot width in sizes, including page padding.

• Avoid excessive candidates whose dimensions and file weights are almost identical.

Tiny labels inside an infographic may remain unreadable regardless of sharpness. A mobile crop, simpler graphic or accessible HTML text may work better.

Testing and Debugging Responsive Images

Do not stop after the markup validates. Confirm what the browser actually loads.

1. Open the page in browser developer tools and select the Network panel.

2. Disable the cache while testing; a previously downloaded large candidate may otherwise be reused.

3. Change the emulated viewport and device pixel ratio, then reload.

4. Filter the network list to images and inspect the chosen URL and transferred bytes.

5. Compare the image's rendered size with its intrinsic dimensions.

6. In the console, inspect the selected source:

document.querySelector("img.responsive").currentSrc

If the browser chooses a file that seems too large, first check sizes. A value of 100vw on a narrow content column is a frequent cause. Next, verify the candidate descriptors and the device pixel ratio. Remember that the browser chooses the source, and an already cached candidate can affect a test.

Common Responsive Image Mistakes

Relying on CSS alone

max-width: 100% prevents overflow, but the original asset may still be downloaded. Add srcset when the same image occupies meaningfully different widths.

Treating w values as breakpoints

800w describes the file, not the viewport. Put layout conditions in sizes or, for art direction, in a <source media> attribute.

Writing an inaccurate sizes value

If the image lives in an 800-pixel column, do not announce it as full-viewport on large screens. Keep the HTML hint aligned with the CSS.

Omitting the <img> fallback

A <picture> must end with an <img>. That element supplies the fallback, accessible text and the box in which the selected source is displayed.

Putting alt on <source>

Alternative text belongs on <img>. The sources are alternate files for the same image purpose, not separate content elements.

Using <picture> for every image

If only the resolution changes, <img srcset sizes> is simpler. Use <picture> for art direction or format selection.

Lazy-loading the primary hero

Lazy loading is useful below the fold, but the first major visual should usually begin loading promptly.

Frequently Asked Questions

What is the difference between srcset and sizes?

srcset lists the available image files and their intrinsic widths or density factors. sizes describes how wide the image will appear in the layout. With width descriptors, the browser uses both pieces of information to select a candidate.

What is the difference between <picture> and srcset?

Use srcset for different resolutions of the same composition. Use <picture> when you need different crops, compositions or file formats. A source inside <picture> can also contain its own srcset and sizes.

What responsive image sizes should I create?

Base them on the component's real rendered widths. Common starting candidates such as 480, 800, 1,200 and 1,600 pixels work for many content images, but a thumbnail grid may need smaller files and a full-width hero may need larger ones. Avoid upscaling beyond the useful detail in the original.

Does the browser always choose the smallest image?

No. It aims for an appropriate image given the slot, device density and other browser information. The smallest file might not have enough pixels to look sharp, while the largest may waste bandwidth.

Are responsive images good for SEO?

They can improve user experience and reduce unnecessary transfer size. Keep a crawlable src, descriptive alt text and accessible surrounding content. Google's image guidance explicitly supports both srcset and <picture> while recommending the fallback src.

Can I combine AVIF, WebP and responsive widths?

Yes. Add AVIF and WebP <source> elements, each with width candidates and accurate sizes, followed by a JPEG or other fallback <img>. Test whether the extra asset pipeline provides worthwhile savings for your site.

Build Responsive Images From the Layout Outward

The best responsive image markup is not a collection of fashionable breakpoints. It is an honest description of the component: which files exist, how wide the image will render, and whether the composition or format should change.

Start with <img srcset sizes> for resolution switching. Add <picture> only when art direction or format fallback solves a real problem. Then verify the selected resource in developer tools instead of guessing.

For the asset preparation, resize each image to useful pixel widths, convert to an efficient web format where appropriate, and compress the finished variants. The result is a page that stays sharp on large displays while avoiding oversized downloads on mobile.