When should I use width descriptors versus density descriptors?

Use width descriptors (640w, 1024w) when the image renders at different sizes on different screens — a hero or a content image in a fluid layout. You pair them with a sizes attribute so the browser knows the rendered width. Use density descriptors (1x, 2x, 3x) when the image is always displayed at a fixed CSS size, like an avatar or an icon; the browser then just picks the file that matches the device pixel ratio, and no sizes attribute is needed.

How does the sizes attribute work, and why does it matter?

sizes tells the browser how wide the image will render at each breakpoint, before any CSS has loaded, so it can choose the right srcset candidate up front. A rule like "(min-width: 768px) 50vw, 100vw" means "half the viewport on tablets and up, full width otherwise." Getting it right avoids downloading a file that is far larger than needed. The tool builds it from declarative rules where the last rule (with no min-width) is the fallback.

Does the tool resize my images or create the AVIF/WebP files?

No — it generates the markup that references them. For the filename-suffix convention it writes URLs like hero-640w.jpg and hero.avif that you produce with a build step or image pipeline. When you select a CDN (Cloudinary, imgix, or the Next.js optimizer), the URLs instead point at the CDN with the right transform parameters, and the CDN resizes and re-encodes on the fly, so you do not pre-generate files.

What is the lazy + fetchpriority=high warning about?

loading="lazy" tells the browser to defer the image until it is near the viewport, while fetchpriority="high" tells it to fetch the image urgently. Those instructions contradict each other. For your LCP image (usually the hero, above the fold) use eager loading plus fetchpriority="high" so it loads as fast as possible. For below-the-fold images use lazy with auto priority. The audit flags the conflicting combination so it never ships by accident.

Why does the tool keep nudging me to set an aspect-ratio?

Without a reserved height, the browser does not know how tall an image will be until it downloads, so surrounding content jumps when the image arrives. That jump is Cumulative Layout Shift (CLS), one of the Core Web Vitals. Setting an aspect-ratio (for example 16/9) reserves the correct box up front so the layout is stable. The tool both adds the inline style and outputs a reusable CSS rule for it.

How accurate is the byte-savings estimate?

It is a deterministic, order-of-magnitude guide, not a real encoder. It scales a fixed bytes-per-pixel base by the largest width, your aspect-ratio, and the quality, then applies typical multipliers (WebP about 70% of JPEG, AVIF about 50%). Real file sizes depend heavily on the encoder and the image content, but the relative ordering — AVIF smaller than WebP smaller than JPEG — and the rough percentage are reliable enough to justify adding modern formats.

Responsive Image Generator

Build production responsive image markup — srcset with width or density descriptors, a sizes attribute from declarative rules, <picture> with AVIF/WebP sources, or Next.js / Gatsby components. It transforms URLs for Cloudinary, imgix and the Next image optimizer, estimates the bytes AVIF and WebP save over JPEG, and audits your markup for the mistakes that hurt LCP and CLS (a lazy + high-priority conflict, missing aspect-ratio, empty alt).

About this ToolHow it works, benefits & use cases

Most responsive-image tools just stitch together a srcset string. This one treats the whole markup as the unit and adds the parts that actually move your Core Web Vitals. You enter a source path and alt text, choose an output format (a plain <img> with srcset, a <picture> with AVIF and WebP sources, a Next.js <Image>, a Gatsby <StaticImage>, or plain HTML), then decide whether to serve width descriptors (640w, 1024w) for fluid layouts or density descriptors (1x, 2x, 3x) for fixed-size images like avatars. A declarative sizes builder turns breakpoint rules into "(min-width: 768px) 50vw, 100vw" so the browser picks the right candidate. When you point at a CDN the candidate URLs are rewritten correctly for Cloudinary, imgix, or the Next image optimizer; otherwise it uses the filename-suffix convention. As you edit, the tool estimates how many bytes AVIF and WebP save over JPEG at your largest width, shows a live preview at your chosen aspect-ratio, and runs an audit that flags the mistakes that hurt LCP and CLS: a lazy + fetchpriority=high conflict, a missing aspect-ratio, an empty alt, or a single-format <picture>. The entire configuration lives in a shareable URL.

How to Use

1Start from a preset (Hero, Card thumbnail, Avatar density, or Next.js Image) or configure by hand.
2Enter the image path and a descriptive alt text, then pick an output format.
3Choose width or density descriptors, then toggle the candidate widths (320-2560) or densities (1x-3x).
4For width descriptors, build the sizes attribute by adding breakpoint rules; the last rule is the fallback.
5Set loading, decoding, fetchpriority and an aspect-ratio, and optionally pick a CDN to rewrite the URLs.
6Copy the generated markup (and the aspect-ratio CSS), or share the URL.

Key Benefits

Five output formats: <img>, <picture> with AVIF/WebP, Next.js <Image>, Gatsby <StaticImage>, and plain HTML
Width descriptors for fluid layouts or density (1x/2x/3x) descriptors for fixed-size images
A declarative sizes builder that produces (min-width: ...) rules with a fallback
CDN URL transforms for Cloudinary, imgix, and the Next.js image optimizer
A deterministic byte-savings estimate showing AVIF vs WebP vs JPEG at your largest width
A live audit that catches the lazy + fetchpriority=high conflict, missing aspect-ratio (CLS), and empty alt
Aspect-ratio CSS to reserve layout space and a shareable URL for the whole configuration

Common Use Cases

Generating a full <picture> with AVIF/WebP sources and a JPEG fallback for a hero image
Serving a fixed-size avatar with 1x/2x/3x density descriptors instead of widths
Producing a Next.js <Image> with priority, a sizes string, and the right quality setting
Wiring up Cloudinary or imgix transform URLs across a set of breakpoints
Auditing existing markup for the lazy + high-priority conflict and missing aspect-ratio CLS risk

Generated markup

html — updates live as you adjust settings

<img
  src="/images/hero-1920w.jpg"
  srcset="/images/hero-640w.jpg 640w, /images/hero-1024w.jpg 1024w, /images/hero-1920w.jpg 1920w"
  sizes="(min-width: 768px) 50vw, 100vw"
  alt="Descriptive alt text"
  loading="lazy"
  decoding="async"
  style="aspect-ratio: 16/9;"
/>

Aspect-ratio CSS (prevents CLS)

Reserves the box height before the image loads

.responsive-img {
  display: block;
  width: 100%;
  height: auto;
  aspect-ratio: 16/9;
  object-fit: cover;
}

Estimated size at largest width

jpeg

506 KB

webp

354 KB

avif

253 KB

AVIF is roughly ≈50% smaller than JPEG here. Rough estimate — actual sizes depend on the encoder and image content.

Preview

aspect-ratio 16/9

srcset candidates: /images/hero-640w.jpg 640w, /images/hero-1024w.jpg 1024w, /images/hero-1920w.jpg 1920w
sizes: (min-width: 768px) 50vw, 100vw

Looks good — no errors or warnings

Presets

Custom configuration — adjust any option below.

Source

Image path or URL

Alt text

Output format

Resolution candidates

Widths (w descriptors)

sizes rules

Tell the browser the rendered width at each breakpoint. The last rule has no min-width — it is the fallback.

fallback (no min-width)

sizes="(min-width: 768px) 50vw, 100vw"

Loading & performance

Lazy load (loading=lazy)

Async decoding (decoding=async)

fetchpriority

aspect-ratio

CDN / transform

URL transform

srcset, sizes, and the browser's job

A responsive image hands the browser a menu of candidate files via srcset and a hint about how big the image will render via sizes. The browser then picks the smallest file that still looks sharp at the device's resolution. Width descriptors (640w) suit fluid layouts; density descriptors (2x) suit fixed-size images like avatars and icons.

Why AVIF and WebP, and why aspect-ratio

A <picture> with AVIF and WebP sources lets modern browsers download a much smaller file while older ones fall back to JPEG — often a 50% byte saving with no visible quality loss. Always set an aspect-ratio so the layout reserves space before the image loads; otherwise the page jumps as images arrive and your Cumulative Layout Shift score suffers.

Was this tool helpful?

Share Your Experience

Help others discover this tool!

Share on

Responsive Image Generator

How to Use

Key Benefits

Common Use Cases

Preview

Presets

Source

Resolution candidates

sizes rules

Loading & performance

CDN / transform

srcset, sizes, and the browser's job

Why AVIF and WebP, and why aspect-ratio

Was this tool helpful?

Share Your Experience

Related tools

Frequently Asked Questions - Responsive Image Generator