skip to content

When should you reach for HTML's <picture> element instead of putting srcset on a plain <img>?

level: middleimportance: must knowfreq 72%

answer

  1. two different problems, one syntax
  2. same photo or a different photo
  3. the browser chooses vs you choose
  4. hints can be ignored, directives cannot
  5. first matching source wins

basics

~20 s

Use picture when the image itself must change: a different crop per breakpoint, or an alternative file format the browser may not decode. Use srcset on a plain img when the same image only needs different pixel sizes and the browser should choose.

solid answer

~50 s

The dividing line is art direction versus resolution switching. If every candidate is the *same* picture at a different pixel size, `srcset` on a plain `<img>` is the right tool — you hand the browser equivalent candidates and it decides, factoring in device pixel ratio and its own heuristics. If the candidates are *not* interchangeable — a wide landscape crop on desktop but a tight square crop on phones, text burned into one variant and not the other, or an AVIF file some browsers cannot decode — then you must make the decision yourself, and that is what `<picture>` exists for. Inside `<picture>` you list `<source>` elements with `media` for art direction or `type` for format, the browser takes the *first* one that matches, and the trailing `<img>` is both the fallback and the element that actually renders.

go deeper

for a junior

Be ready to state the split in one line: srcset for the same image at different sizes, picture when the image itself changes. Show a small picture snippet with a source and a trailing img.

for a middle

Explain the selection mechanics: sources are evaluated in document order, the first match wins, and each source carries srcset rather than src. Say why the browser is allowed to ignore srcset but not a matching source.

for a senior

Show judgment about cost. Talk about the asset matrix that art direction creates, the duplication between media queries in markup and breakpoints in CSS, and why you would push back on art direction for images that only need to be smaller.

for a principal

Own the policy. Decide where crops are generated, how breakpoint values stay single-sourced across markup and design, and which images in a catalogue are worth per-breakpoint art direction at all versus a single well-composed asset.

## Two problems that look like one Responsive images cover two genuinely different needs, and almost every mistake in this area comes from treating them as the same problem. **Resolution switching** means: this is one photograph, and I want the browser to download a copy whose pixel dimensions suit this screen. A 400 px wide slot on a 2x phone wants roughly 800 real pixels; the same slot on a 1x laptop wants 400. Every candidate shows the identical subject, identical crop, identical framing. They are interchangeable — only the byte count and pixel count differ. **Art direction** means: the image is not the same image. A hero photo that reads beautifully as a 16:9 landscape at 1600 px becomes an unreadable smear of background when squeezed into a 375 px phone column, because the subject is now forty pixels tall. What you actually want on the phone is a *different* crop — tight on the face, maybe a different aspect ratio, sometimes a different photo altogether. A third case behaves like art direction mechanically even though it is about bytes: **format negotiation**, where you want to serve AVIF or WebP to browsers that can decode them and a JPEG or PNG to the rest. ## The rule Interchangeable candidates → `srcset` on `<img>`, and let the browser choose. Non-interchangeable candidates → `<picture>`, and *you* choose. That is the whole answer, and the reason is a specification-level design decision: the browser is explicitly allowed to ignore your `srcset` preference. It may pick a larger candidate because it is already in cache, or a smaller one on a metered connection, or a different one on a zoomed page. That freedom is safe when all candidates show the same thing and catastrophic when one of them is a square crop. `<picture>` with `media` is a *directive*, not a hint: the first `<source>` whose conditions match wins, and the browser does not second-guess it. ## What picture looks like ```html <picture> <source media="(min-width: 800px)" srcset="hero-wide.jpg"> <source media="(min-width: 500px)" srcset="hero-portrait.jpg"> <img src="hero-square.jpg" alt="Ada at the analytical engine" width="600" height="600"> </picture> ``` The browser walks the `<source>` children in document order and takes the **first** whose `media` matches the current viewport (and whose `type`, if present, it can decode). It never looks at later sources once one matches, so order is your priority list. If nothing matches, the `<img>` is used. Note what is *not* here: no `src` on `<source>`. Inside `<picture>`, `<source>` carries `srcset` (plus optional `sizes`, `media`, `type`, `width`, `height`). The `src` attribute belongs to `<source>` inside `<video>` and `<audio>`, and writing it here silently produces nothing. ## Format fallback is the same mechanism ```html <picture> <source type="image/avif" srcset="photo.avif"> <source type="image/webp" srcset="photo.webp"> <img src="photo.jpg" alt="Harbour at dawn"> </picture> ``` A browser skips any `<source>` whose `type` it cannot decode and moves to the next, so the JPEG on the `<img>` is the universal floor. Ordering runs most-modern first, because first match wins. ## The two can be combined `<picture>` does not replace `srcset` — it wraps it. Each `<source>` may carry a full `srcset`/`sizes` pair, so you pick the *crop* with `media` and still let the browser pick the *resolution* within that crop. That is the correct shape for an art-directed hero on a site that also serves high-DPI screens. ## Costs to be honest about `<picture>` multiplies your asset matrix: crops times formats times widths. Three breakpoints, two formats and three widths is eighteen files that must all be generated, cached and invalidated together. It also creates a second copy of your breakpoint values — the `media` queries live in HTML while the layout breakpoints live in the stylesheet, and nothing keeps them in sync but discipline. So `<picture>` is not the default; `srcset` on `<img>` is the default, and `<picture>` is what you escalate to when the candidates genuinely stop being interchangeable. ## The tell in an interview Candidates who answer "picture is the modern way to do responsive images" have memorised a slogan. Candidates who answer "picture when the image changes, srcset when only its size changes" have understood the model, and they will usually add the corollary unprompted: the `<img>` is not optional, because it is the element that renders.

  • Can you use srcset and picture together, or is it one or the other?
    Together, and often you should. Each `<source>` inside `<picture>` accepts its own `srcset` (and `sizes`), so `media` selects the crop and the browser still selects the resolution within that crop. `<picture>` is a wrapper that constrains which candidate set applies; it does not replace the candidate list.
  • Why is srcset described as a hint while a picture source media query is not?
    By design the browser may pick any candidate from a `srcset` — cache contents, device pixel ratio, or user settings can all override your intent, which is safe because the candidates are interchangeable. A `<source media>` match is a selection rule the browser follows, so it is the only safe way to say "on small screens this must be the square crop."
  • What is the cost of choosing picture when srcset would have done?
    You take over a decision the browser makes better than you can. Hard-coded `media` breakpoints in markup cannot react to device pixel ratio, cache state or user data-saving preferences, and they duplicate your CSS breakpoints in a second place. You also multiply the generated asset matrix for no visual gain.

saying these in an interview costs you the question

  • picture is just the newer, better way to write srcset
  • srcset changes the crop for mobile screens
  • source uses src, like video source elements
  • picture renders the image, so alt goes on picture
  • later sources override earlier ones, like CSS rules

context