Responsive images explained: one photo, many sizes
A phone should not download the image made for a large monitor. How the browser picks the right size and format, and why the build does it.
The short answer
A photo that fills a large monitor is several times larger than a phone screen can even display. Without responsive images, the phone downloads the whole thing and shrinks it, wasting bandwidth and time on the device where both matter most. Responsive images fix this with standard HTML: the page offers several sizes of the same picture and states how wide the image will display, and the browser chooses the smallest candidate that will look sharp on that screen, accounting for pixel density. Formats work the same way: modern formats are offered with fallbacks, and each browser takes the best it supports. All of it is generated at build time from one original.
The pieces, in plain terms
| Piece | What it says to the browser |
|---|---|
| A list of candidates | ”This image exists at these widths” |
| A sizes description | ”On small screens it fills the width; on large screens it takes a third of the layout” |
| Format alternatives | ”Here is a modern format; if you cannot use it, here is a standard one” |
| Width and height | ”Reserve this much space before the image arrives”, so nothing jumps |
| Loading priority | ”Fetch the hero image first; the footer logos can wait until they scroll into view” |
Why the build does it
- One original per image, high quality, uploaded once.
- The build generates the set of widths and the modern and fallback formats, and caches them so it only happens once per image.
- The template writes the markup: candidates, sizes, formats, dimensions, priority, from the layout’s own knowledge of how wide the image will be.
- The network serves each generated file with long cache lifetimes.
- An editor changing the image repeats the process automatically; nobody resizes anything by hand.
What it changes in numbers you care about
The largest element on most pages is an image, and its arrival time is a core speed measurement that search engines use. Serving a phone-sized image to a phone typically cuts that element’s bytes by a large factor and its arrival time with it. Bandwidth costs fall in proportion, because images are most of what a site serves. And layout shift disappears when dimensions are reserved. Three measurable improvements from one mechanical practice.
What this means for you
Responsive images are standard, mechanical and, on a modern static site, automatic: one original in, the right size and format out for every device, with space reserved so nothing jumps. Ask whether your site does this. If it does not, it is one of the largest speed and cost improvements available, and once the build does it, nobody has to think about it again.
Frequently asked questions
Why not just upload a medium-sized image and use it everywhere?
Because there is no size that is right for both a phone and a large high-density monitor. Too small looks blurry on the monitor; large enough for the monitor is several times more bytes than the phone needs. Responsive images end that compromise: each device gets its own size from one original.
Does this affect how the page looks?
Only in that images look sharp on every screen and arrive faster. The layout is the same. The difference is invisible to the eye and visible in the bytes downloaded, the speed measurements and the bandwidth bill.
Who has to do the work?
The build. A modern static framework takes one original per image, generates the sizes and formats, writes the markup that describes them and sets width and height so the layout does not shift. Editors and authors upload one image and reference it once.
Sources
- MDN: Responsive images (accessed 2026-09-11)