Srcset Oluşturucu

Generate srcset, sizes and picture markup in one place

Writing responsive image markup by hand is fiddly — the srcset list, the matching sizes attribute, the <picture> block with WebP and AVIF fallbacks — and a single typo means the browser quietly downloads the wrong file. This srcset generator builds the whole tag for you: enter a filename and your widths and it produces a complete, copy-ready responsive <img> or <picture> element with correct descriptors, lazy loading and async decoding.

It's a free responsive image generator that runs entirely in the browser — no sign-up, nothing uploaded, and it keeps working offline once loaded.

srcset and sizes, explained

A responsive image needs two parts working together. srcset is the list of files and their real widths — hero-640.jpg 640w tells the browser that file is 640 pixels wide. sizes describes how wide the image will display in your layout, for example (max-width: 600px) 100vw, 600px. The browser reads sizes, multiplies by the device pixel ratio, and downloads the closest srcset candidate.

Switch the descriptor to x and you get pixel-density markup instead — logo.png 1x, logo@2x.png 2x — ideal for fixed-size images like logos and icons on retina screens, where w descriptors and sizes would be overkill.

When to use the picture element instead

Plain srcset handles resolution switching — the same image at different sizes. Reach for the <picture> element when you need more control: serving next-gen formats with a fallback, or art direction (a different crop on mobile than on desktop).

In <picture> mode this tool emits a <source type="image/avif">, a <source type="image/webp"> and a JPEG or PNG <img> fallback, so modern browsers get the smallest format and older ones still see an image.

Resize your image to every width, locally

Markup is only half the job — you still need the actual resized files. Drop an image into the tool and it will resize it to each of your widths right on an HTML canvas, then let you download the whole set with filenames that match the generated markup exactly (hero-320.jpg, hero-640.jpg, and so on).

There's no upload and no build pipeline. Because enlarging past the original only adds blur, the tool flags any width that's larger than your source so your image set stays accurate.

How it compares to Squoosh, Responsivebreakpoints.com and CloudFlare Image Resize

Squoosh (by Google) excels at single-image compression and conversion — it's superb for picking the right quality setting for a WebP or AVIF. But it doesn't generate srcset markup or produce a full responsive image tag for pasting into HTML. It's a compression tool, not a markup generator.

Responsivebreakpoints.com by Cloudinary uploads your image to Cloudinary's servers to calculate optimal breakpoints and generate resized images. The results are solid, but your file leaves your machine and Cloudinary's terms apply. Cloudflare Image Resize and Imgix are CDN services — they process images at delivery time but require account setup, API integration, and ongoing billing. UtiloKit's srcset generator sits in a different position: it generates complete HTML markup and resizes images locally, client-side, with no upload, no account, no cost and no file size limits. Useful when you want the markup or the resized files on the spot, without wiring up infrastructure.

Widths, breakpoints and Core Web Vitals

A reliable width set is 320, 640, 960, 1280 and 1920, roughly doubling at each step to cover phones through large retina displays; add 2560 for full-bleed heroes. Serving a right-sized image is one of the biggest wins for Core Web Vitals: fewer bytes means a faster Largest Contentful Paint, and adding width and height attributes prevents the layout shift (CLS) that hurts both users and rankings.

Add loading="lazy" to off-screen images so they load only when scrolled into view, and fetchpriority="high" to your hero so it loads first — both are one-click toggles here.

Private, instant and offline — works on any device

There's nothing to install and no account to create. Every tag is assembled in your browser as you type, and any image you resize is processed locally with the canvas API — nothing is ever uploaded. The generator works offline once the page loads, so you can build responsive img srcset and <picture> markup anywhere — on a plane, on a phone, without Wi-Fi.

How the browser actually picks an image from srcset

Understanding the browser's selection algorithm explains why both srcset and sizes are necessary. When the browser parses an <img> tag it runs through three steps before downloading anything. First it reads the sizes attribute and finds the first media condition that matches the current viewport — for example sizes="(max-width: 768px) 100vw, 50vw" means the image occupies 100% of the viewport on mobile and 50% on wider screens. Second, it multiplies that CSS width by the screen's device pixel ratio (1× on a standard monitor, 2× on most modern phones, 3× on high-end Android devices) to derive the target pixel count it needs. Third, it scans the srcset list and downloads the candidate whose width descriptor (w) is closest to that target without going below it.

This entire calculation happens before a single byte of image data is fetched, which is why the sizes hint is critical for efficiency — omit it and the browser assumes the image is 100vw wide, almost always causing it to fetch a file far larger than needed on desktop or tablet layouts. Width descriptors (w) are the right choice for fluid, layout-driven images because they let the browser account for both layout width and pixel density dynamically. Density descriptors (x) are the right choice for fixed-size UI elements — a 48 px icon that should look sharp on a retina screen needs icon.png 1x, icon@2x.png 2x and nothing more. Mixing both descriptor types in a single srcset attribute is invalid HTML.

One important nuance: the spec explicitly allows the browser to serve a larger image than strictly necessary if it is already cached. A browser that downloaded the 1280w version for a wide viewport is allowed to reuse it when the window is resized to mobile rather than re-downloading the 640w file. This is intentional behaviour — you are providing hints, not commands — and means you may not see file switching in all testing scenarios.

Modern image formats: JPEG, PNG, WebP, AVIF and JPEG XL compared

JPEG (Joint Photographic Experts Group, 1992) is the baseline: lossy compression with 8-bit colour and no transparency support, excellent for photographs where a small quality loss is imperceptible. PNG (1996) uses lossless compression and supports full transparency via an alpha channel, making it the right choice for logos, icons, screenshots and any graphic with flat colours or hard edges where compression artifacts would be visible. Neither format adapts to modern delivery requirements particularly well — JPEG files are often larger than necessary, and PNG files for photographs are enormous.

WebP (Google, 2010) supports both lossy and lossless modes plus transparency, and delivers files roughly 25–34% smaller than JPEG at equivalent perceived quality. It has enjoyed full browser support across Chrome, Firefox, Edge and Safari since 2020, making it the practical default for new projects today. AVIF (AV1 Image File Format, 2019) pushes compression further still — typically 50% smaller than JPEG at the same quality — and likewise supports transparency and HDR wide-colour. Chrome, Firefox and Safari all support it as of 2023, though encoding is slower and there are occasional colour-profile edge cases worth testing. The modern pattern is to offer AVIF first, WebP second and JPEG as the final fallback inside a <picture> element, so every browser gets the smallest format it understands.

JPEG XL (2022 ISO standard) promises even better compression than AVIF, lossless JPEG recompression (you can store the original bits inside a JXL file), and excellent progressive decoding. However, as of 2024 browser support remains limited — Chrome removed its experimental flag and the format's future in Chromium is uncertain, though Firefox and Safari have added support. For production use today, WebP and AVIF are the safe choices; JPEG XL is one to watch.

The <picture> element: art direction and format switching

The <picture> element addresses two problems that plain srcset on <img> cannot solve. The first is art direction: showing a tightly cropped portrait on mobile and a wider landscape composition on desktop. Each <source> child element accepts a media attribute — <source media="(max-width: 600px)" srcset="portrait-400.jpg 400w, portrait-800.jpg 800w"> — and the browser loads the first source whose media condition matches, falling back to the bare <img> at the end. This is fundamentally different from srcset resolution switching: you are dictating which image to load, not leaving it to the browser's discretion.

The second problem is format switching with graceful degradation. The type attribute on a <source> element tells the browser what MIME type the files are: <source type="image/avif" srcset="hero.avif 1280w, hero-640.avif 640w">. The browser tries each source in order and uses the first format it supports, so the canonical modern pattern is: AVIF source → WebP source → JPEG/PNG <img> fallback. This gives browsers without AVIF support a smaller WebP, and browsers without WebP (essentially none today, but older iOS Safari) the JPEG. The <img> tag is always required as the last child of <picture> — it is what actually renders and carries alt, width, height, loading and fetchpriority; the <source> elements only provide alternative candidates.

You can combine both techniques: art-directed sources can each carry their own srcset for resolution switching, so a mobile portrait source might list 400w, 800w and 1200w versions, while a desktop landscape source lists 800w, 1280w and 1920w versions. The markup becomes verbose quickly, which is exactly why generators exist.

Core Web Vitals: LCP, CLS and the impact of responsive images

Largest Contentful Paint (LCP) measures the time from navigation start to when the browser renders the largest visible element — almost always a hero or above-the-fold image. Google uses LCP as a ranking signal: a score below 2.5 seconds is 'Good', above 4 seconds is 'Poor'. Serving a 1400 px image to a 375 px mobile screen forces the browser to download roughly twelve times more data than necessary; a properly constructed srcset cuts that transfer to the 400 px file and can slash LCP on mobile by a second or more. Every width you add to your srcset is a potential LCP improvement on the device that falls into that range.

Two attributes are critical for the LCP image specifically. fetchpriority="high" tells the browser to request it at the highest network priority, ahead of other resources discovered later in parsing. And you should never add loading="lazy" to your LCP image — lazy loading defers the fetch until the element is near the viewport, which for an above-the-fold hero means a guaranteed delay before any download begins. For all other images — anything that starts off-screen — loading="lazy" is a free win: the browser skips those fetches entirely until the user scrolls close, reducing both page weight and network contention during the critical loading window.

Cumulative Layout Shift (CLS) is the other image-related Core Web Vital. When a browser loads an image without knowing its dimensions it has to re-flow the page once the image arrives, pushing content down and generating CLS. The fix is simple but easy to forget: always include width and height attributes on your <img> tag. Modern browsers use these to reserve space in the layout before the image loads, eliminating the shift. If your image is fluid (scaled with CSS max-width: 100%), add height: auto in your stylesheet so the browser uses the intrinsic aspect ratio from the HTML attributes rather than locking to a fixed pixel height. This combination — HTML dimensions plus height: auto in CSS — is the standard CLS fix for responsive images.