Responsive Image srcset Builder

Enter your base filename, breakpoint widths, and sizes value. The builder outputs a production-ready <img> tag with all srcset candidates. Upload a source image to also export every resized file as a zip, ready to deploy.

Output:
Descriptors:
Filename only, no path. Output pattern: path/base-width.ext.
Folder prefix prepended to every candidate URL. Include the trailing slash.
Width presets
Separate values with commas, spaces, or new lines. Duplicate and invalid entries are removed automatically.
Define how much viewport width the image occupies at each breakpoint. Note: 100vw includes the scrollbar (~15px on Windows) and may cause a slightly oversized download on some devices.
Intrinsic px width. Prevents CLS.
Intrinsic px height. Prevents CLS.
Required when using a CDN with CORS headers and fetchpriority="high". Must match on both the preload tag and the img.
Generated <img> markup —

Add at least two valid widths to generate srcset output.

Candidate List

Width Candidate String Est. Size Copy
No candidate widths parsed yet.

Export Resized Images

Upload a source image to generate all candidate sizes as real files. The zip includes every resized variant named base-width.ext, the original converted to your selected format as base.ext, and markup.txt with the generated <img> tag. Uploading a JPG and selecting WebP returns WebP files.

Lower values reduce file size. Higher values preserve detail. 85 is a good default.

Drop an image here or click to browse

Supports JPG, PNG, WebP, GIF

How srcset and sizes Actually Work

Responsive images are one of the most impactful performance wins available in modern front-end work, but they are also one of the easiest places to ship subtle mistakes. The goal is clear: send smaller image files to smaller screens and crisper files to high-density displays. The practical challenge is syntax, precision, and the relationship between your candidate widths, your sizes attribute, and each device's pixel ratio.

The browser does not simply pick the smallest file. It evaluates each candidate from your srcset against the rendered size of the image on the page. That rendered size comes from your sizes attribute. If sizes says the image is 100vw on phones and 70vw on tablets, the browser calculates an expected display width and chooses the most appropriate candidate, accounting for device pixel ratio. On a 3x display a 393px visual slot requires approximately 1179px of image resolution for crisp rendering.

Output Modes: img vs. picture

This builder supports two output modes. The img tag mode emits a single <img> element with a srcset and sizes — the fastest path to production for most cases. The picture tag mode wraps the output in a <picture> element with separate <source> blocks for AVIF and WebP, followed by a fallback <img>. This gives browsers a progressive format ladder: AVIF for the best compression, WebP as a wide-support fallback, and your chosen format as the final safety net for older clients.

Width vs. Density Descriptors

Width descriptors (320w, 768w, etc.) combined with a sizes attribute are the correct choice for most layout-responsive images. The browser uses both pieces of information to make an optimal download decision based on viewport size and DPR.

Density descriptors (1x, 2x, 3x) are appropriate for fixed-size images such as logos, icons, and UI elements where the rendered size does not change with viewport width. In density mode the sizes attribute is not required and is hidden automatically.

Presets and Why Sizes Must Match Layout

The built-in width presets give you a validated starting point for six common image contexts: full-bleed hero images, card grids, sidebars, article body images, product detail shots, and thumbnails. Each preset populates both the candidate widths and the sizes attribute simultaneously. The sizes values are calibrated so that every candidate set passes the DPR Coverage panel for all five reference device profiles.

A common mistake is applying hero-sized candidate widths to a product grid image without updating sizes. The browser then evaluates the image as if it fills the full viewport, selects unnecessarily large files, and wastes bandwidth. The DPR Coverage panel makes this visible: if you see an Undersized or Oversized status, your sizes value does not match your actual layout.

DPR Coverage Analysis

The DPR Coverage panel evaluates your candidate widths against five real device profiles spanning a range of viewport widths and pixel densities, from an iPhone SE at 375px and 2x to a desktop monitor at 1920px and 1x. For each profile it parses your sizes expression, calculates the rendered display width, multiplies by DPR to get the required pixel count, and then identifies which candidate the browser would select.

A status of Good means the selected candidate is within a 1.3x overhead ratio of the needed pixels. Undersized means no candidate is large enough to serve that device crisply. Oversized means the selected candidate is significantly larger than needed, wasting bandwidth. Adjust candidate widths or refine your sizes expression until all five profiles show Good.

Estimated File Sizes

When you upload a source image, the builder runs a background resize operation for each candidate width using the browser's Canvas API. The resulting file sizes appear in the Candidate List table and update live as each width completes. This gives you a concrete sense of the payload difference between candidates before you export anything.

The quality slider controls the compression level for WebP, JPG, and AVIF exports. PNG is always lossless and ignores the quality setting. Lowering quality reduces file size with a visual tradeoff; 85 percent is a reliable default for photographic content.

Exporting Resized Images

Upload a source image and the Export section becomes active. The builder resizes every candidate width using Canvas, re-encodes to your chosen format, and packages the results into a zip file alongside the generated markup as markup.txt. An original-size file is also included, converted to your target format but at the source image's native resolution, for archival or future use.

AVIF export is supported in Chromium-based browsers (Chrome and Edge 121 or later). On Firefox and Safari the AVIF option is disabled with an explanatory note. All other formats work across all modern browsers.

LCP and fetchpriority

If you set loading="lazy" without a fetchpriority value, the tool displays a warning. Lazy loading defers the fetch until the image is near the viewport, which is correct for below-the-fold content but harmful for hero images that contribute to Largest Contentful Paint. For above-the-fold images, use loading="eager" and fetchpriority="high" to signal the browser to prioritize the download.

Settings Persistence

All form values, mode selections, descriptor type, and quality are saved automatically to localStorage as you work. Returning to the tool restores your last session exactly, including the selected output mode and descriptor type. Nothing is sent to a server.

Frequently Asked Questions