Free Responsive Image Set Generator — srcset + sizes + WebP
Shipping one image size to every device is a 2010 habit. Modern responsive HTML uses srcset and sizes to let the browser pick the smallest sufficient variant for the current viewport — cutting mobile data use by 60–80%. PikDraw's Responsive Image Set Generator builds the full variant pack and a ready-to-paste HTML snippet from a single master image, in your browser, free.
What is the Responsive Image Set Generator — srcset + sizes + WebP?
Responsive Image Set is a client-side tool that takes one source image and produces a set of downscaled variants at standard breakpoints (320, 640, 768, 1024, 1280, 1920 px), exports them as WebP or JPEG, and bundles them into a ZIP alongside a copy-paste HTML <img srcset='…' sizes='…'> snippet with lazy-loading and async decoding pre-configured.
Key features
- Standard breakpoints: 320, 640, 768, 1024, 1280, 1920 px
- Toggle individual sizes on / off
- WebP or JPEG output at quality 85
- Auto-generated srcset + sizes HTML snippet
- Lazy-loading and async decoding baked in
- README with usage instructions in the ZIP
- 100% client-side — no upload
- Free, no signup, no watermark
How it works
The master image is decoded into an off-screen Canvas. For each selected breakpoint, the tool draws the image scaled down (or skips if the source is smaller) using high-quality bicubic resampling, re-encodes via canvas.toBlob() at quality 85, and adds the result to a JSZip archive named imagename-{width}w.{ext}. A srcset string is built from the generated filenames, combined with a sensible sizes default, and written to snippet.html in the archive.
Why use this tool
Build-time tools (sharp, next/image) require a build pipeline; CDN tools (Cloudinary, imgix) cost money. PikDraw's generator is a one-off, no-install solution that produces the same output — variant images plus the HTML snippet — for free, with no upload concerns. Perfect for small static sites, CMS posts, and ad-hoc landing pages.
Common use cases
- Replace single-size hero images with responsive variants
- Optimise CMS-hosted blog images for mobile readers
- Generate a CDN-ready image pack for static sites (Astro, Eleventy, Hugo)
- Migrate legacy WordPress galleries to responsive HTML
- Cut mobile bandwidth on image-heavy e-commerce sites
- Improve Core Web Vitals LCP on mobile
- Standardise responsive output across a design system
How to use this tool
- Upload your master image — Drop a single high-resolution JPG, PNG or WebP. Ideally 1920 px wide or wider — the tool only downscales, it doesn't upsample.
- Pick breakpoints — Defaults: 320, 640, 768, 1024, 1280, 1920. Toggle off the sizes you don't need. Match these to your design's CSS breakpoints for best results.
- Choose a format — WebP (recommended) for 25–35% better compression than JPEG. JPEG for maximum legacy compatibility.
- Generate — The tool renders one image per selected width, packages them into a ZIP, and adds a ready-to-paste HTML snippet using srcset + sizes + lazy-loading + async decoding.
- Drop into your site — Host the images on your CDN, paste the snippet into your template, and adjust the sizes attribute to match how the image is rendered in your layout.
Who should use this
Front-end developers, static-site engineers, bloggers self-hosting images, CMS administrators, and marketers who don't want to wire up a build pipeline just to ship responsive images.
How to get started
Upload your widest image, keep all default breakpoints, choose WebP, click Generate. Drop the resulting images on your CDN and paste snippet.html into your template.
Best practices
- Use the largest source image you have — the tool only downscales
- Match breakpoints to your CSS breakpoints
- WebP for modern sites; JPEG fallback via <picture> if you need IE / old Safari
- Always pair srcset with sizes — without sizes, srcset is ignored
- Update the sizes attribute to match the image's rendered width
- Set loading='lazy' on below-the-fold images (default in the snippet)
- Re-export when your design changes breakpoints
Pro tips
- Match breakpoints to your CSS — there's no point shipping a 768 px image if your design jumps from 640 to 1024.
- Always pair srcset with sizes — without sizes, browsers ignore srcset.
- loading='lazy' should be on every below-the-fold image.
- decoding='async' avoids blocking the main thread on image decode.
- Use WebP unless your audience includes very old browsers (IE11 / Safari < 14).
Expert insights
💡 Pro Tip: Wider source wins
Always start from your widest available image. The tool downscales but never upscales — a 2400 px master gives better results across all breakpoints.
💡 Pro Tip: Match your breakpoints
There's no point in a 768 px variant if your design's gap is 640 → 1024. Toggle off sizes you don't need.
💡 Pro Tip: Set sizes carefully
Sizes is the second half of srcset. Without it, browsers fall back to picking the largest variant. Match the rendered width of your image.
Limitations to be aware of
- Caps every variant at source resolution (no upscaling)
- WebP / JPEG only (no AVIF in browser canvas)
- Single quality (85%) — re-run with the compress tool for finer control
- Doesn't generate <picture> with art direction
- One source image per run
- Snippet uses a default sizes attribute — adjust for your layout
Frequently asked questions
- Why generate multiple sizes?
- Modern displays vary from 320 px wide (entry phones) to 4K monitors. Serving the same 1920 px JPEG to every visitor wastes 5× the bandwidth on mobile. The srcset + sizes attributes let the browser pick the right size for the current viewport and DPR, cutting mobile data use without sacrificing desktop quality.
- What is the difference between srcset and sizes?
- srcset declares the image variants and their intrinsic widths (image-640w.webp 640w, image-1280w.webp 1280w). sizes declares the rendered width at each viewport (max-width: 768px → 100vw, otherwise 80vw). The browser combines both to pick the smallest variant that's large enough at the current viewport × DPR.
- What sizes attribute should I use?
- Match how the image is rendered in your layout. Full-width hero: sizes='100vw'. Article body: sizes='(max-width: 768px) 100vw, 720px'. Card thumbnail: sizes='(max-width: 768px) 50vw, 320px'. The tool generates a reasonable default — adjust to your CSS.
- Should I use <picture> instead of srcset?
- Use <picture> when you need art direction (different crops per viewport) or multiple formats (WebP with JPEG fallback). For pure size variants of the same image, srcset is simpler and recommended. The included snippet uses srcset; wrap in <picture> if you also want a format fallback.
- Why doesn't 1920 px upscale my smaller images?
- Because upscaling invents pixels — the larger file gains no real detail. The tool caps every variant at the source image's actual width. To generate variants larger than the source, upscale the source first with our upscale tool.
- What about retina displays?
- srcset's width descriptors (320w, 640w …) work for retina automatically — the browser computes effective width × DPR (2× or 3×) and picks accordingly. A retina iPhone 12 at 390 px CSS width × 3 DPR = 1170 px, so it picks the 1280 variant. No extra work required.
- Is the original modified?
- No. The tool only reads your upload — every variant is a fresh re-encode at smaller dimensions. Your master file stays untouched on disk.
- Are my images uploaded?
- No. All resizing, re-encoding and ZIP packaging happen in your browser. Safe for client work and unreleased product photos.