Upload one image — get every responsive size, the exact HTML snippet, and a ZIP of all files.
Everything renders in your browser — your image never leaves your device.srcset markup for you — the exact fix that warning asks for.Select image
or drop it here · use your largest original · rendered on your device
Comma-separated. Anything wider than your original is skipped — never upscaled.
A WebP set is always rendered too, for the <picture> snippet.
JPEG / WebP only.
Files become hero-320w.jpg etc. Leave blank to use your file's name.
Must match your real layout — wrong sizes makes browsers pick wrong files.
Used in the snippet. Leave blank for decorative images (we'll set alt="").
Rendering…
Rendering happens on your device — just do not close this tab.
Everything happened inside your browser — your image was never uploaded anywhere, so there is nothing to delete.
Responsive images are simple in theory and fiddly in practice. The theory: give the browser several widths of the same image, describe your layout, and let it download the best-fitting file. The practice: resize the file five times, name everything consistently, hand-write a srcset string without typos, get the sizes attribute right, and add a WebP fallback for good measure. This srcset generator does the whole job in your browser — upload once, download the variants (or one ZIP), paste the snippet.
A normal <img src="photo.jpg"> gives the browser exactly one file, so every visitor — a phone on 4G and a 27-inch monitor on fibre — downloads the same bytes. A responsive image lists candidates instead:
<img src="photo-800.jpg"
srcset="photo-400.jpg 400w, photo-800.jpg 800w, photo-1600.jpg 1600w"
sizes="(max-width: 640px) 100vw, 800px"
width="1600" height="1067" alt="…" loading="lazy">The 400w descriptors are w descriptors: they state each file's real width in pixels. The sizes attribute tells the browser how wide the image will render in your layout (“full viewport under 640px, otherwise 800px”). From those two facts plus the device's pixel density, the browser picks the smallest file that still looks sharp. No JavaScript, no server logic — the browser does it natively.
You'll also see srcset="photo.jpg 1x, photo@2x.jpg 2x" — those are x descriptors, which target screen density directly and need no sizes. They're fine for fixed-size UI graphics (logos, icons). For anything whose rendered width changes with the viewport — heroes, content images, cards — w descriptors + sizes are the flexible standard, and that's what this tool generates.
srcset solves resolution switching (same image, different sizes). The <picture> element solves two more problems: format switching (serve WebP to browsers that support it, JPEG/PNG to the rest) and art direction (a different crop on mobile). This tool's second snippet is the format-switching pattern — a WebP <source> with your chosen format as the fallback <img> — which is the highest-value, lowest-risk use of <picture>.
Lighthouse flags this when it finds images served significantly larger than their rendered size — the classic being a 4000px original displayed at 400px on mobile. The fix it wants is exactly this workflow: generate widths close to the rendered sizes, wire them with srcset/sizes, prefer WebP, and include width/height so the layout doesn't shift (that last one also helps your CLS score). Upload the ZIP contents next to your HTML, paste the snippet, and re-run PageSpeed to see the warning clear.
There is no universal set — it depends on your layout — but these starting points cover most sites:
sizes="100vw"The tool defaults to 320–1920, which spans all of these. Type your own list if your design needs different breakpoints — anything wider than your source is skipped, because upscaling only inflates file size without adding detail.
The most common srcset mistake isn't the files — it's a sizes attribute that doesn't match the real CSS layout. If your image actually renders at 50% viewport but sizes says 100vw, the browser downloads double the pixels it needs on every page view. Pick the preset closest to your layout, or choose Custom and write the real value. When in doubt, open devtools, measure the rendered image width at a few breakpoints, and encode exactly that.
WebP files are typically 25–35% smaller than equivalent JPEGs, which is why the <picture> snippet leads with a WebP source. But a lone .webp in an <img> still breaks on truly ancient browsers — the fallback <img> inside <picture> covers them with zero extra work. (AVIF would be smaller still, but browsers can't reliably encode AVIF client-side, so this tool sticks to what it can produce honestly: JPEG, WebP, PNG.)
Bloggers & WordPress users: generate the set once, upload the files, paste the markup in a Custom HTML block — no plugin needed. Frontend developers: prototype responsive markup without touching sharp, ImageMagick, or a build plugin. Static sites & portfolios: hand-rolled HTML gets proper responsive images in a minute. Core Web Vitals chasers: pair the right sizes with loading="eager" + fetchpriority="high" on your LCP hero and watch the scores move.
One upload, every width, paste-ready markup, honest file sizes shown per variant. Make your images responsive the way the spec intended — and stop shipping 4MB heroes to phones.
Drop in the biggest, best-quality version. It's rendered locally — never uploaded.
320–1920 by default; JPEG, WebP or PNG; quality slider; sizes preset for your layout.
Paste the srcset or picture snippet, download variants or one ZIP, upload beside your HTML.
Yes. EzySize’s Responsive Srcset Generator tool is free to use without creating an account. Advertising may appear on this page; the tool remains free to use. Use the controls above and check the result against your requirements.
It takes one source image and produces several widths (for example 320, 640, 960, 1280 and 1920 pixels) plus the HTML markup — the srcset and sizes attributes — so the browser can download the best-fitting file for each visitor's screen instead of everyone downloading the largest original.
Upload your image here, pick your widths and format, and click Generate. You'll get every resized variant to download (individually or as a ZIP) plus two copy-paste snippets: a plain <img> with srcset, and a <picture> version that serves WebP with a fallback for older browsers.
The sizes attribute tells the browser how wide the image will render in your layout at different viewport widths — for example "(max-width: 640px) 100vw, 800px". Without it, the browser assumes the image is full viewport width and may download a larger file than needed. This tool includes a sizes preset you should adjust to match your real layout.
The <picture> element wraps multiple <source> elements so you can serve different formats or crops per device. The most common use is format switching: a WebP source for modern browsers with a JPEG/PNG <img> fallback inside, which is exactly what this tool's second snippet generates.
A w descriptor (like "800w") states the image file's width in pixels and must be paired with a sizes attribute so the browser can choose. An x descriptor ("2x") targets device pixel ratio directly and needs no sizes. This tool generates w descriptors, the flexible standard for responsive layouts.
That warning appears when you serve images much larger than their rendered size. Generating the right widths and wiring them up with srcset/sizes is exactly the fix PageSpeed wants — along with modern formats and correct width/height attributes, which the generated snippet includes.
Never. Widths larger than your original are skipped automatically, because upscaling only makes bigger files without adding sharpness. If your source is small, upload a larger original to get more variants.
For a full-width hero, 800, 1200, 1600 and 2400 pixels with sizes="100vw" is a common setup. For in-content images, 400, 800 and 1200 with a sizes value matching your column width. The tool defaults to 320–1920, which covers most layouts — adjust to your design.
Yes — both snippets include the image's intrinsic width and height attributes, which lets the browser reserve the correct aspect-ratio space before the file loads. Keep the same aspect ratio across variants, which this tool does automatically.
Yes. The <picture> snippet serves a WebP srcset to browsers that support it and falls back to your chosen format (JPEG or PNG) inside the <img> tag for anything older.
Yes — paste the markup into a Custom HTML block, or upload the variant files to your media library (or theme folder) and adjust the file paths in the snippet to match. WordPress also generates its own responsive sizes on upload; this tool is for themes, page builders, or static HTML where you control the markup.
Yes — free, no sign-up, and everything renders in your browser, so your images are never uploaded anywhere.