Responsive image & srcset generator

How to generate responsive image HTML

1. Enter the source image's actual width and height. Use the image dimension checker if you do not know them.
2. Choose export widths and a filename pattern containing {width}. Use the same image composition for every candidate.
3. Set the display width cap and gutters to match your intended page. Select the appropriate loading role and replace the sample alt text.
4. Review the export table, create those image files with your editor or image service, then copy the generated HTML.
5. Test the markup in your own page at different widths and densities. Confirm the image URLs return the intended files.

The tool does not contact URLs you enter. A generated path such as /images/photo-640.webp is a naming instruction, not an existing asset. Renaming a JPEG to .webp does not convert its format: export the right file type using an image editor.

What srcset and sizes do

The srcset attribute lists available files and their intrinsic widths, such as 640w. The sizes attribute describes the expected CSS display width for the relevant viewport. Together, they let the browser consider layout width and display density when selecting an image. The filename itself does not prove the pixel width: the descriptor must match the real exported file.

This generator uses width descriptors throughout. It does not mix w and density-based x descriptors. For a fuller explanation of these attributes, see MDN's responsive images guide.

The generated markup uses one format and one composition. Separate mobile crops or alternate format sources require an appropriate picture setup, not merely additional widths in this list. For a crop change, plan the new composition with the crop loss calculator first.

Example: an 800-pixel content image with mobile gutters

Suppose the image fills the viewport minus 16 CSS pixels on each side, up to a maximum width of 800 CSS pixels. At a 390-pixel viewport its slot is 358 CSS pixels. At a viewport of 832 pixels or more, its slot reaches the 800-pixel maximum.

At DPR 2, the mobile target is 358 × 2 = 716 raster pixels. From widths of 320, 480, 640, 960, 1280 and 1600, the planning estimate picks 960w: the smallest candidate meeting 716. This is a conservative planning rule, not a promise about a browser's download. Network policies and cached resources can affect actual selection.

At a 1440-pixel viewport and DPR 2, the capped layout needs 800 × 2 = 1600 pixels. At DPR 3, the target becomes 2400 pixels. A 1600-pixel source cannot meet that target without upscaling; this tool retains the available source and warns about the shortfall instead of inventing extra detail.

Choose useful image export widths

Start from the layout widths your images actually occupy. A small card and a full-width banner do not need identical export sets. Test representative narrow and wide viewports at the densities important to your audience, then choose a manageable set of widths that covers those targets.

The default widths are an editable starting point, not universal device breakpoints. The generator sorts them, removes duplicates and excludes candidates larger than your original. If every candidate exceeds the source, reduce the requested widths or choose a larger original. It does not silently add new candidates.

Export height is calculated proportionally and rounded to the nearest pixel. For example, a 1600 × 900 source produces 640 × 360 at a 640-pixel width. Unusual aspect ratios may introduce a one-pixel rounding difference. Review the exported images to ensure they share the same composition and do not contain accidental padding or cropping.

More candidates mean more files to maintain. Compare quality and transferred bytes in practice rather than assuming a larger list is always better. The viewport & DPR calculator can help you distinguish CSS layout size from raster dimensions.

Loading settings, layout stability and SEO

The normal role emits eager loading without a high-priority hint. The below-the-fold role emits lazy loading. The main hero role emits eager loading with high fetch priority. Choose according to where the image actually appears; marking every image as high priority removes the intended distinction.

Do not delay your likely Largest Contentful Paint image with lazy loading. See web.dev's LCP optimization guidance. Test improvements with your own measurements: markup alone cannot guarantee a specific performance score.

The width and height attributes give the browser the source proportions, while the generated CSS defines the responsive display width and automatic height. Keep these proportions consistent with the image to avoid unexpected movement or distortion. This layout assumes a viewport-based content image; a nested card, sidebar or grid needs its own matching CSS and sizes rules.

Useful alt text describes the image's purpose in context. Do not repeat a list of keywords. Use empty alt text only when the image is genuinely decorative. An image inside a link may need an accessible name that conveys the link's action. Keep surrounding copy relevant and use descriptive filenames where practical; neither filenames nor srcset are ranking guarantees.

Before you publish: responsive image checklist

• Every candidate URL exists and serves the intended image format.
• The numeric w descriptor equals that file's actual width.
• All candidates share the same composition and near-identical aspect ratio.
• The CSS display width matches the generated sizes assumptions.
• The main visible image is not unnecessarily lazy-loaded.
• Alt text reflects the real image, or is intentionally empty for decoration.
• Network and layout tests include a fresh load at multiple viewport widths.

Inspect the image's selected resource in browser developer tools. A browser can reuse a larger image it has already downloaded, so making the window smaller does not always trigger a smaller request. Use a fresh page load and check the transferred resource rather than judging only by appearance.

Related web image tools