resiz[ly]A PictureEditor.com tool
The queue runs on your machine. Nothing leaves it.

Generate srcset images

A width list, the pixel ratios you actually serve, and one format. Drop the sources and the markup is printed beside the plan, so the widths in your HTML and the widths on disk are the same list.

1The queue

A folder, a selection or a paste. Sub-folders are kept.

0

files queued

Drop a folder. Or 200 files.One file is faster at resizepicture.com.Sub-folders are kept, so a folder name can go in a filename.

/a paste works too

2The rules

Ordered, and every rule a file matches writes a file. That is how one photo becomes three.

Responsive set
Responsive set320 640 960 1280 1920 / 1x / webp q78

Separated by spaces or commas. Widths above a source are dropped, not invented.

Pixel ratios

Empty means every file in the queue.

3What will be written

Every file, named and measured, before anything runs.

Drop a folder and this fills in: one row per file that will be written, with its name, its size and an estimate of its bytes, plus every collision and every dropped width. Nothing runs until it is on screen.

4The run

Nothing to run yet.

That is the ledger, mid-run. One line per file as it is written, newest at the bottom, and the real byte count rather than the estimate.

What a set expands into

One control, several rules. Five widths and two pixel ratios is ten rules, and they are ordinary rules once they are expanded — the plan, the collision check and the ledger treat them exactly like anything you wrote by hand. The one thing the expansion does that a hand-written rule cannot is drop a width larger than the source instead of enlarging into it.

photo-01-320.webp    320×213    18 KB
  photo-01-640.webp    640×427    41 KB
  photo-01-960.webp    960×640    79 KB
  photo-01-1280.webp  1280×854   128 KB
  photo-01-1920.webp  1920×1281  271 KB

With pixel ratios on, the naming changes to {name}-{w}@{dpr}x.{ext} and each width is written once per ratio. The w descriptor in the markup is the real pixel width of the file, not the CSS width it was asked for, which is the part that is easy to get wrong by hand.

The markup

<img
  src="photo-01-1920.webp"
  srcset="photo-01-320.webp 320w, photo-01-640.webp 640w,
          photo-01-960.webp 960w, photo-01-1280.webp 1280w,
          photo-01-1920.webp 1920w"
  sizes="(max-width: 640px) 100vw, (max-width: 1024px) 50vw, 1920px"
  width="1920" height="1281" alt="">

The sizes attribute printed beside the plan is a starting point, not an answer. It describes a picture that is full width on a phone, half width on a tablet and fixed on a desktop; if your layout is not that, the attribute is the thing to change, because it is what the browser reads before it has laid anything out.

Choosing the widths

The default list — 320, 640, 960, 1280, 1920 — is a reasonable spread for a full-bleed image and too many files for a thumbnail. Two things are worth knowing:

  • Browsers pick the smallest candidate that is at least as wide as they need. Gaps larger than about 400px start to waste bytes on the device that lands in the middle of one.
  • A 3x variant of a 1920 is 5760 pixels wide. It exists for a phone that will show it at 1920 CSS pixels, and it is several hundred kilobytes for a difference most people cannot see. 1x and 2x cover almost everything.
Where the image sitsA sensible listRatios
Full-bleed hero640, 960, 1280, 19201x, 2x
Half-width article image480, 768, 10241x, 2x
Catalogue grid tile240, 360, 4801x, 2x
Avatar or icon48, 961x, 2x, 3x

This will not tell you which widths your layout needs

The lists above are conventions, not measurements. The right set depends on your breakpoints and on how much of the viewport the image occupies at each one, and nothing on this page can see either. Pick from your own CSS, then come back and write the list.

The seven naming tokens, and what happens when two sources want the same output name, are on the naming reference.