srcset & sizes Generator

Enter your image base URL, the widths you want generated, and the sizes attribute — and get copy-paste-ready <img srcset> markup. Check the picture option to also emit a <picture> element with separate <source> tags for AVIF and WebP, so browsers load the most efficient format they support. Width descriptors (320w, 640w…) tell the browser actual pixel dimensions; the sizes attribute tells it the rendered CSS width at each breakpoint.

How to use the srcset & sizes Generator

Fill in the fields and the markup updates automatically:

  • Base URL/path — the path to your original image file, e.g. /img/hero.jpg. The tool splits this at the last dot to build per-width filenames like /img/hero-320.jpg.
  • Widths — comma-separated pixel widths you have generated (or will generate) on your server/CDN. Each becomes a 320w width descriptor in the srcset.
  • sizes — a CSS media query list that tells the browser how wide the image will be rendered at each viewport size. The browser uses this together with srcset to pick the optimal source. Example: (max-width:600px) 100vw, 50vw means "full width on small screens, half-width otherwise".
  • picture checkbox — wraps the <img> in a <picture> with <source> tags for AVIF (best compression) and WebP (broad support), falling back to the original JPEG/PNG for older browsers.

Copy the output and paste it into your template. The loading="lazy" and decoding="async" attributes are safe defaults for below-the-fold images; remove them from your LCP (Largest Contentful Paint) hero image.

Width descriptors, sizes, and format negotiation

Responsive images solve a download-size problem: a 1920 px image sent to a 375 px mobile screen wastes 5–20× the bytes needed. The HTML spec provides two mechanisms to fix this. The srcset attribute lists candidate images with width descriptors (w units) that represent the intrinsic pixel width of each candidate file. The sizes attribute describes the rendered CSS width of the image at each viewport size. The browser multiplies the rendered CSS width by the device pixel ratio, then picks the smallest candidate in srcset that is at least that wide. This means a 2× Retina phone at 375 px CSS width will pick the 960 w candidate — it needs 750 device pixels, and 960 w is the smallest one that covers it.

The <picture> element adds format negotiation on top of resolution switching. Each <source type="image/avif"> or <source type="image/webp"> is only used if the browser supports that MIME type. AVIF typically saves 50% over JPEG at the same quality; WebP saves ~30%. The fallback <img> inside <picture> handles browsers that support neither (IE11, older Safari). All three sets of files need to exist on your server — this tool generates the markup, not the image files themselves.

For your LCP image (the largest visible image on page load, usually a hero), remove loading="lazy" and instead add fetchpriority="high". Lazy loading delays the request, which increases LCP and hurts Core Web Vitals. For all other images, lazy loading reduces initial page weight and is a safe default.

Common use cases

  • Hero images — generate markup for the banner photo that dominates most pages; correct srcset is one of the highest-impact LCP improvements available.
  • Product galleries — e-commerce thumbnails appear at different widths in grid vs list vs detail views; srcset handles all three without duplicate markup.
  • Blog post images — content images typically span 100% of a column; the generated markup handles both single-column mobile and multi-column desktop layouts.
  • CDN integration — image CDNs (Imgix, Cloudinary, Bunny, Fastly) generate resized variants on demand via URL parameters; the srcset widths map directly to those parameters.
  • Static site generators — copy the pattern into a Nunjucks/Liquid macro or a Next.js Image component to standardise responsive image handling across a project.

Frequently asked questions

What's the difference between w descriptors and x descriptors in srcset?
Width descriptors (320w, 640w) require a sizes attribute and let the browser pick the best image for any combination of viewport size and DPR. Density descriptors (1x, 2x) are simpler but only handle DPR — they don't account for the rendered CSS width of the element. Use w descriptors with sizes for everything except fixed-size images (avatars, icons) where x descriptors are appropriate.

Do I need to create all these image files myself?
Not necessarily. Image CDNs (Cloudinary, Imgix, Bunny.net) generate resized versions on-the-fly via URL parameters. Build tools like sharp, vite-imagetools, and @astrojs/image can generate the variants at build time. This tool generates the HTML markup; the image files must already exist at the specified URLs.

Should I use AVIF for everything?
AVIF gives the best compression but encoding is slow (use server-side pre-encoding, not on-the-fly for large sites) and Safari added support only in Safari 16. The picture element's source ordering handles this gracefully: AVIF first, WebP second, original last. Each browser picks the first source it supports.

What sizes value should I use?
Describe how wide the image appears at each breakpoint in CSS units. For a full-width image: "100vw". For a sidebar image that's 33% on desktop and full-width on mobile: "(max-width:768px) 100vw, 33vw". For an image that's always 400px regardless of viewport: "400px". The browser uses this to calculate the ideal pixel width before fetching.

Why shouldn't I add loading="lazy" to my LCP image?
Lazy loading tells the browser to defer the request until the image is near the viewport. For images already in the viewport on load (hero images), this delays the fetch and directly increases your Largest Contentful Paint time — a Core Web Vitals metric. Use loading="lazy" only for below-the-fold images.