srcset and sizes generator

What it's for

Serving the same 2000 px image to a 390 px phone and a desktop monitor is one of the most common causes of slow websites. The standard fix is responsive images: generate several versions of each image and let the browser download the smallest one that looks sharp on each screen.

Doing it by hand takes three tedious, error-prone steps:

1. Export the image at several widths and, to take advantage of modern formats, in several formats.
2. Work out the sizes attribute, which tells the browser how much screen space the image will take before the CSS loads.
3. Write the <picture> markup with every srcset, the fallback, width, height and the loading attributes.

This tool does all three at once.

How to use the generator

1. Drop the original image, the highest-resolution one you have. Widths larger than the original are never generated.
2. Tell us how it's displayed on your page:
   • Full width: banners and heroes spanning the whole window.
   • Inside a container: the most common case; the image fills the content width up to a maximum (for example 1200 px).
   • In a grid: product or blog cards in several columns.
   • Fixed width: avatars, logos or thumbnails with a constant size.
3. Review the recommended widths. They're calculated to cover high-density (2x) screens without generating needlessly large files. You can add or remove widths by hand.
4. Choose the formats: AVIF and WebP are on by default, and a fallback in JPG (or PNG if the image has transparency) is always added.
5. Click Generate, download the ZIP and copy the code.

How the sizes attribute is calculated

sizes is the part people most often get wrong, and the one that matters most. The browser decides which file to download before it knows your CSS, so it needs you to tell it how wide the image will be in each case. If you omit sizes, it assumes 100vw (the whole screen) and on desktop it'll download versions far larger than needed.

Some examples of what the tool generates:

With that information, the browser multiplies the width by the screen's pixel density and picks the smallest file that covers it. The guide to responsive images with srcset and sizes explains it step by step.

Which widths to generate

More variants isn't always better: each one takes space on your server and in the CDN cache. The tool follows these rules:

• Up to 2x the maximum display width. 3x screens exist, but the visual difference between 2x and 3x in photos is imperceptible and the weight almost doubles.
• 30-50% steps between variants (480, 640, 960, 1280, 1600…), enough that there's always a file close to the ideal size.
• Never above the original: upscaling adds no detail, only weight.

The generated code

You can copy three variants:

• <picture> with one <source> per modern format and a fallback <img>. It's the recommended option: each browser picks the best format it supports and, within it, the right width.
• <img srcset> in a single format (WebP), shorter, handy if you don't need AVIF.
• next/image, in case you use Next.js. There you don't need to generate variants, because the framework creates them; what matters is sizes, which the tool computes the same way.

The code always includes width and height (they prevent layout shifts and improve CLS) and loading="lazy". If you tick It's the main image (LCP), that's replaced by fetchpriority="high", which makes the browser fetch it sooner. It should only be used on the largest image visible on page load; we explain it in the guide on lazy loading and fetchpriority.

Frequently asked questions

Why aren't widths larger than my image generated?

Because upscaling an image adds no detail: it just produces a bigger, equally blurry file. If you need larger versions, start from a higher-resolution original.

Do I need both AVIF and WebP?

It's not essential, but it's ideal. AVIF is usually 20-30% lighter than WebP, and WebP serves the few browsers that don't support AVIF. The JPG fallback covers very old cases.

Where do I upload the files?

To any public folder on your site. Enter its path in the Public path field (for example /images/ or your CDN URL) and the code will use that path.

Is my image uploaded to a server?

No. The variants are generated in your browser with the same WebAssembly encoders as the rest of ImageZap.