---
title: "Responsive Images in HTML: srcset, sizes and Image Size"
description: Learn HTML image size, srcset, sizes, and responsive images to optimize html image resize across devices and screens.
image: https://blog.blazingcdn.com/hubfs/Gemini-Blog/image-Nov-10-2026-03-22-17-0551-PM.jpeg
---

[![BlazingCDN](https://blog.blazingcdn.com/hubfs/Logo/blog-logo-w.png)](https://blog.blazingcdn.com?hsLang=en-us)

[📘 Learn ▾](https://blog.blazingcdn.com/cdn-learn?hsLang=en-us)

[CDN Fundamentals](https://blog.blazingcdn.com/cdn-fundamentals?hsLang=en-us) [By Content Type](https://blog.blazingcdn.com/by-content-type?hsLang=en-us) [Advanced Concepts](https://blog.blazingcdn.com/advanced-concepts?hsLang=en-us) [📖 Glossary](https://blog.blazingcdn.com/glossary?hsLang=en-us)

[🎬 Video & Streaming ▾](https://blog.blazingcdn.com/video-streaming-cdn?hsLang=en-us)

[🔴 Live Streaming](https://blog.blazingcdn.com/live-streaming?hsLang=en-us) [📺 VOD & OTT](https://blog.blazingcdn.com/vod-ott?hsLang=en-us) [🎞️ Encoding & Players](https://blog.blazingcdn.com/encoding-players?hsLang=en-us) [🎧 Audio & Podcasts](https://blog.blazingcdn.com/audio-podcasts?hsLang=en-us) [💰 Bandwidth & Costs](https://blog.blazingcdn.com/bandwidth-costs?hsLang=en-us)

[🏗️ Infrastructure ▾](https://blog.blazingcdn.com/cdn-infrastructure?hsLang=en-us)

[🗄️ Storage & Origin](https://blog.blazingcdn.com/storage-origin?hsLang=en-us) [📦 Large File Delivery](https://blog.blazingcdn.com/large-file-delivery?hsLang=en-us) [💸 Cloud Costs & Egress](https://blog.blazingcdn.com/cloud-costs-egress?hsLang=en-us) [🌐 Networking & ISP](https://blog.blazingcdn.com/networking-isp?hsLang=en-us) [⚙️ DevOps & Cloud Infra](https://blog.blazingcdn.com/devops-cloud-infra?hsLang=en-us) [⚡ Web Performance](https://blog.blazingcdn.com/web-performance?hsLang=en-us)

[🏭 Industries ▾](https://blog.blazingcdn.com/cdn-industry-insights?hsLang=en-us)

[📺 Media & Broadcasting](https://blog.blazingcdn.com/media-broadcasting?hsLang=en-us) [💾 Software & SaaS](https://blog.blazingcdn.com/software-saas?hsLang=en-us) [📣 AdTech & Advertising](https://blog.blazingcdn.com/adtech-advertising?hsLang=en-us) [🎮 Gaming & Esports](https://blog.blazingcdn.com/gaming-esports?hsLang=en-us) [📱 Mobile Apps & Developers](https://blog.blazingcdn.com/mobile-apps-developers?hsLang=en-us) [🤖 AI & Machine Learning](https://blog.blazingcdn.com/ai-machine-learning?hsLang=en-us) [🏛️ Enterprise & Corporate](https://blog.blazingcdn.com/enterprise-corporate?hsLang=en-us) [📚 E-Learning & EdTech](https://blog.blazingcdn.com/e-learning-edtech?hsLang=en-us) [🏟️ Sports & Live Events](https://blog.blazingcdn.com/sports-live-events?hsLang=en-us)

[💰 Pricing & Compare ▾](https://blog.blazingcdn.com/cdn-pricing-and-cdn-costs?hsLang=en-us)

[Provider Pricing](https://blog.blazingcdn.com/provider-pricing?hsLang=en-us) [Cost Optimization](https://blog.blazingcdn.com/cost-optimization?hsLang=en-us) [Decision Support](https://blog.blazingcdn.com/decision-support?hsLang=en-us) [⚡ Compare](https://blog.blazingcdn.com/cdn-comparison?hsLang=en-us) [Provider Comparisons](https://blog.blazingcdn.com/provider-comparisons?hsLang=en-us) [Strategy Comparisons](https://blog.blazingcdn.com/strategy-comparisons?hsLang=en-us) [📊 Benchmarks](https://blog.blazingcdn.com/cdn-ratings-and-benchmarks?hsLang=en-us)

[🔒 Security ▾](https://blog.blazingcdn.com/cdn-security?hsLang=en-us)

[Attack Protection](https://blog.blazingcdn.com/attack-protection?hsLang=en-us) [Encryption & Access](https://blog.blazingcdn.com/encryption-access?hsLang=en-us) [Video & DRM Security](https://blog.blazingcdn.com/video-drm-security?hsLang=en-us)

[🛠️ Tools](https://blog.blazingcdn.com/cdn-tools?hsLang=en-us)

[Get Started](https://blazingcdn.com/sign-up-contact-form/)

[Web Performance](https://blog.blazingcdn.com/en-us/tag/web-performance) [Infrastructure](https://blog.blazingcdn.com/en-us/tag/infrastructure)

# Responsive Images in HTML: srcset, sizes and Image Size

 Vadym Borovskyi  Nov 10, 2026, 4:25:14 PM

![\<span id="hs\_cos\_wrapper\_name" class="hs\_cos\_wrapper hs\_cos\_wrapper\_meta\_field hs\_cos\_wrapper\_type\_text" style="" data-hs-cos-general-type="meta\_field" data-hs-cos-type="text" \>Responsive Images in HTML: srcset, sizes and Image Size\</span\>](https://blog.blazingcdn.com/hubfs/Gemini-Blog/image-Nov-10-2026-03-22-17-0551-PM.jpeg)

Getting html image size right takes three attributes on one img element: **srcset** with width descriptors, **sizes** that mirror your CSS layout, and **width** and **height** that reserve the box before any byte arrives. Do it and a 390 CSS pixel phone slot at 3x density downloads a roughly 1,200 pixel file instead of a 2,400 pixel master, about 4 times fewer pixels, and the image stops pushing content down as it loads. Plan on about 45 minutes per image template, plus an hour to wire resized variants through an image CDN.

Responsive images in HTML work when srcset offers several pixel widths, sizes states the rendered slot width per breakpoint, and width and height give the intrinsic aspect ratio. A 390 CSS pixel slot on a 3x screen needs a 1,170 pixel file, and since 2020 Chrome, Firefox and Safari derive the reserved box from the width and height attributes, which keeps that image's Cumulative Layout Shift (CLS) contribution at zero.

## **How the browser picks an html image size from srcset and sizes**

The browser multiplies the slot width from sizes by the device pixel ratio (DPR), then picks a srcset candidate at or above that target. It does this before layout, during preload scanning, which is why it cannot measure your CSS and needs sizes to tell it. If sizes is missing, the browser assumes 100vw and downloads for the full viewport width.

Two details matter in production. The HTML standard lets browsers choose freely, so Chrome may reuse a larger candidate already in its cache instead of fetching a smaller one. And the width descriptor (the "w" suffix) describes the file's real pixel width; if it lies, every downstream calculation lies with it.

For fixed-size images such as logos and avatars, skip sizes entirely and use density descriptors: set **srcset** to "logo-160.png 1x, logo-320.png 2x" on an image with a fixed CSS width of 160 pixels.

## **Prerequisites**

- Master images at least 2 times the widest slot they will fill, ideally the camera or design export.
- Your layout breakpoints and the CSS that sizes each image template (column widths, gutters, max-width of the container).
- Either an image CDN that resizes on request, or a build step that writes variants (sharp or libvips both work).
- Chrome or Firefox DevTools with device emulation and DPR override.

## **Step-by-step html image resize with srcset, sizes and an image CDN**

### Step 1: Measure the rendered slot at each breakpoint

Open the page in DevTools, select the image and read its rendered width in the Computed pane at each breakpoint. Write down CSS pixels, not file pixels. Example layout used below: full width under 768 pixels, half the viewport from 768 to 1,199, and a fixed 584 pixel column from 1,200 up.

### Step 2: Build an anchored width ladder

Multiply each slot by the DPR values you care about (1, 2 and 3 on phones; 1 and 2 elsewhere) and round up to a short list. For the example: 390 times 2 is 780, 390 times 3 is 1,170, 384 times 2 is 768, 584 times 1 and 2 give 584 and 1,168. Those targets collapse into a four-step ladder of 400, 600, 800 and 1,200 pixels.

The bound that governs any ladder: if adjacent candidates differ by a width ratio r, the worst-case overfetch is r squared in pixels. A geometric ladder at 1.25 wastes at most 1.56 times the pixels but needs about 10 variants from 320 to 2,400; at 1.5 it needs about 6 and wastes up to 2.25 times; at 2.0 it needs 4 and wastes up to 4 times. Anchoring on measured targets beats all three because the steps sit where real devices land.

| Case | Slot (CSS px) | DPR | Needed px | File picked | Pixel overfetch |
| --- | --- | --- | --- | --- | --- |
| Phone, full width | 390 | 2 | 780 | 800 | 1.05x |
| Phone, full width | 390 | 3 | 1,170 | 1,200 | 1.05x |
| Tablet, half column | 384 | 2 | 768 | 800 | 1.09x |
| Laptop, fixed column | 584 | 2 | 1,168 | 1,200 | 1.06x |
| Laptop, no srcset | 584 | 1 | 584 | 2,400 master | 16.9x |

Four anchored variants keep every measured case under 1.1 times the needed pixels, while shipping the 2,400 pixel master to a 1x laptop column decodes 16.9 times the pixels it displays.

Decode cost follows pixels, not bytes. A 2,400 by 1,600 image occupies about 15.4 MB of memory once decoded (4 bytes per pixel), against about 1.7 MB for an 800 by 533 variant, which matters on low-end Android devices long before network cost does.

### Step 3: Write srcset with width descriptors

Set **srcset** to "hero-400.jpg 400w, hero-600.jpg 600w, hero-800.jpg 800w, hero-1200.jpg 1200w" and keep **src** pointing at the 800 variant as the fallback. Why: src is what non-supporting parsers and some crawlers fetch, so make it a sane middle size, not the master.

### Step 4: Write sizes to mirror your CSS

Set **sizes** to "(min-width: 1200px) 584px, (min-width: 768px) 50vw, 100vw". The first matching media condition wins, so list conditions from widest to narrowest and end with an unconditioned default. Why: sizes is a promise about layout, and when CSS changes without it, the browser keeps downloading for the old layout. Subtract gutters with calc where they matter, for example "calc(50vw - 24px)".

### Step 5: Set width and height to the intrinsic ratio

Set **width** to 1200 and **height** to 800 (the master's 3:2 ratio, any matching pair works), then in CSS set the image to width 100% and height auto. Why: browsers map these attributes to a CSS aspect ratio, so the box is reserved at the right height before the file arrives. Without height auto, the attribute height wins and the image distorts.

### Step 6: Set loading priority by position

On the Largest Contentful Paint (LCP) image, set **fetchpriority** to high and never set lazy loading. On images below the fold, set **loading** to lazy and **decoding** to async. Why: lazy loading the hero delays LCP by a full layout pass, a common regression after a blanket rollout.

### Step 7: Serve the variants from an image CDN

Point srcset at one master per image and let the CDN resize on request, typically with the target width as a URL query parameter. Three rules keep this cacheable. Include the width parameter in the cache key. Snap or reject widths outside your ladder, so a crawler walking widths 1 to 3,000 cannot create 3,000 cache objects and 3,000 origin resizes. Enable origin shield so each variant is generated once, not once per edge.

For content-hashed URLs, set **Cache-Control** to a max-age of 31536000 seconds with the immutable directive. BlazingCDN includes on-the-fly crop, resize, resizefit and resizefill on every plan, along with origin shield and request coalescing, which covers this step without a separate image service; the [**BlazingCDN feature list for image delivery**](https://blazingcdn.com/features/) shows what ships on each plan.

### Step 8: Add AVIF and WebP with a picture element

Wrap the img in a picture element with a source of **type** "image/avif", then one of "image/webp", each with its own srcset and the same sizes, and keep the JPEG img as fallback. Why: explicit format URLs cache cleanly, while negotiating format on the Accept request header requires **Vary** set to Accept, which fragments the cache on many CDNs. If art direction changes the crop per source, set width and height on each source too; current Chrome, Firefox and Safari honor them.

## **How to validate responsive images**

- In DevTools, disable cache, emulate a 390 pixel device at DPR 3, select the image and read its **currentSrc** property in the console. Expected: the 1,200 variant.
- Switch to 1,440 pixels wide at DPR 1. Expected currentSrc: the 600 variant.
- In the Network panel, filter to images and confirm the **Content-Type** is image/avif in Chrome, and the transferred size dropped against the old master.
- Request the same variant twice through the CDN. Expected: the **Age** header grows on the second response and your vendor's cache status header reports a hit.
- In the Performance panel, check the Layout Shifts track during load. Expected: no shift attributed to the image. In the field, Core Web Vitals treat a CLS of 0.1 or less as good.

## **Rollback**

Every change here is additive. Delete srcset and sizes and the browser falls back to src; keep width and height, since they only reserve space. For the CDN, the master stays at origin, so reverting means pointing your URL builder back at the original paths. Purge the variant paths only if a bad resize was cached.

## **Failure modes: symptom, cause, fix**

- **Every device downloads the largest file.** Cause: sizes missing, so the browser assumes 100vw. Fix: add sizes per Step 4.
- **Images look stretched or squashed.** Cause: CSS sets width but not height auto. Fix: add height auto.
- **Blurry on high-density screens.** Cause: sizes understates the slot, or the ladder tops out below slot times DPR. Fix: re-measure and extend the top step.
- **Low cache hit ratio on image paths.** Cause: arbitrary widths or a Vary on Accept or client hint headers. Fix: snap widths to the ladder and move format into the URL.
- **LCP got worse after rollout.** Cause: lazy loading applied to the hero. Fix: remove it there and set fetchpriority to high.

## **Tuning and trade-offs once srcset works**

Cap the ladder's top at 2 times your widest slot. Going from 2x to 3x costs 2.25 times the pixels, and for photographs on phone screens the visible gain is small; this blog's call is that 3x is worth it only for text-heavy graphics and UI screenshots.

For lazy-loaded images, Chrome shipped **sizes** set to "auto" in 2024 (version 126), which uses the laid-out width and removes the drift between CSS and sizes. Verify support in Safari and Firefox before relying on it, and write "auto" followed by your normal list so other browsers get a fallback.

Client Hints (**Sec-CH-DPR**, **Sec-CH-Width**, **Sec-CH-Viewport-Width**, opted into with the **Accept-CH** response header) let the server pick the width instead. The trade-off: support has historically been Chromium-only, and every hint you vary on multiplies cache keys. Markup-driven srcset stays the portable default.

## **FAQ: html image size, srcset and sizes**

### What happens if I use srcset without sizes?

The browser assumes the image renders at 100vw, the full viewport width. On a 1,440 pixel desktop where the image sits in a 584 pixel column, that makes it fetch a file sized for 1,440 CSS pixels times the DPR. Width descriptors without an accurate sizes attribute therefore often download more bytes than a single well-chosen src would.

### Should I still set width and height on responsive images?

Yes, always set width and height on responsive images, using any pair that matches the intrinsic aspect ratio. Browsers convert them into a CSS aspect ratio and reserve the box before the file loads, which prevents layout shift. Pair them with CSS width 100% and height auto so the image scales to its container without distortion.

### How many srcset widths should a responsive image have?

Most templates need four to six srcset widths. Multiply each measured slot width by the DPR values you support, round into a short ladder, and check the gaps: adjacent steps that differ by a width ratio r waste at most r squared in pixels. Anchoring steps on real targets usually keeps overfetch near 1.1 times.

### Does srcset work with lazy loading and sizes auto?

Yes, srcset works with lazy loading, and the sizes value auto is valid only on lazy-loaded images. With auto, the browser waits for layout and uses the real rendered width, so sizes can no longer drift from CSS. Chrome shipped it in 2024; list a normal sizes fallback after auto for browsers that lack support.

## **Audit one image template this week**

Pick the template that produces your LCP element on your top landing page. Measure its slot at three breakpoints, build the anchored ladder from slot times DPR, and record transferred bytes, currentSrc and CLS before and after on a 390 pixel 3x emulation and a 1,440 pixel 1x desktop. Then pull a day of CDN logs for image paths and count distinct width values: anything outside your ladder is cache fragmentation you can remove with a snap rule. The exercise takes an afternoon and gives you numbers for the rest of the image inventory.

If you would rather keep one master per image and generate the ladder at the edge, [**BlazingCDN image processing**](https://blazingcdn.com/image-processing/) handles crop, resize, resizefit and resizefill on every plan at no extra charge.

Share: [f](https://www.facebook.com/sharer/sharer.php?u=https://blog.blazingcdn.com/en-us/responsive-images-in-html-srcset-sizes-and-image-size) [in](https://www.linkedin.com/sharing/share-offsite/?url=https://blog.blazingcdn.com/en-us/responsive-images-in-html-srcset-sizes-and-image-size) [𝕏](https://twitter.com/intent/tweet?url=https://blog.blazingcdn.com/en-us/responsive-images-in-html-srcset-sizes-and-image-size&text=) [✉](mailto:?subject=%3Cspan%20id="hs_cos_wrapper_name"%20class="hs_cos_wrapper%20hs_cos_wrapper_meta_field%20hs_cos_wrapper_type_text"%20style=""%20data-hs-cos-general-type="meta_field"%20data-hs-cos-type="text"%20%3EResponsive%20Images%20in%20HTML:%20srcset,%20sizes%20and%20Image%20Size%3C/span%3E&body=https://blog.blazingcdn.com/en-us/responsive-images-in-html-srcset-sizes-and-image-size)

![BlazingCDN](https://blog.blazingcdn.com/hs-fs/hubfs/Logo/blog-logo-w.png?height=24&name=blog-logo-w.png)

*Heavy traffic.*  
Light bill.

The CDN for video and large traffic

100 TB a month at list price

- BlazingCDN**$415**
- [bunny.net](https://bunny.net/pricing/) Volume**$500**
- [CDN77](https://www.cdn77.com/pricing), plan to 250 TB**$990**
- [KeyCDN](https://www.keycdn.com/pricing), NA and Europe**$2,600**
- [CloudFront](https://aws.amazon.com/cloudfront/pricing/pay-as-you-go/) pay as you go**$6,965**

Each provider's published list price for transfer, lowest first, checked November 2026. BlazingCDN publishes this blog. Up to 50 TB a month a flat plan such as CloudFront Pro ($15) can cost less.

[Calculate your cost](https://blazingcdn.com/cdn-cost-calculator/?utm_source=blog&utm_medium=sidebar&utm_campaign=blog_sidebar&utm_content=compare_calc)

## Related posts

[![Best Image Format for the Web: JPEG, PNG, WebP, AVIF, SVG](https://blog.blazingcdn.com/hubfs/Gemini-Blog/image-Nov-09-2026-01-51-20-7661-PM.jpeg)](https://blog.blazingcdn.com/en-us/best-image-format-for-the-web-jpeg-png-webp-avif-svg?hsLang=en-us)

Web Performance

### [Best Image Format for the Web: JPEG, PNG, WebP, AVIF, SVG](https://blog.blazingcdn.com/en-us/best-image-format-for-the-web-jpeg-png-webp-avif-svg?hsLang=en-us)

Evaluated November 2026: the best image format for web photos is AVIF with a JPEG fallback, or WebP when encode time ...

Nov 9, 2026, 2:53:33 PM [Read more](https://blog.blazingcdn.com/en-us/best-image-format-for-the-web-jpeg-png-webp-avif-svg?hsLang=en-us)

[![JPEG vs JPG: Is There Any Difference?](https://blog.blazingcdn.com/hubfs/Gemini-Blog/image-Nov-05-2026-03-08-19-4198-PM.jpeg)](https://blog.blazingcdn.com/en-us/jpeg-vs-jpg-is-there-any-difference?hsLang=en-us)

Web Performance

### [JPEG vs JPG: Is There Any Difference?](https://blog.blazingcdn.com/en-us/jpeg-vs-jpg-is-there-any-difference?hsLang=en-us)

There is no technical difference in JPEG vs JPG. Both extensions label the same format, defined by ISO/IEC 10918-1 ...

Nov 5, 2026, 4:10:55 PM [Read more](https://blog.blazingcdn.com/en-us/jpeg-vs-jpg-is-there-any-difference?hsLang=en-us)

[![Zstandard Compression for the Web: zstd vs Brotli vs Gzip](https://blog.blazingcdn.com/hubfs/Gemini-Blog/image-Nov-03-2026-08-55-36-5956-AM.jpeg)](https://blog.blazingcdn.com/en-us/zstandard-compression-for-the-web-zstd-vs-brotli-vs-gzip?hsLang=en-us)

Web Performance

### [Zstandard Compression for the Web: zstd vs Brotli vs Gzip](https://blog.blazingcdn.com/en-us/zstandard-compression-for-the-web-zstd-vs-brotli-vs-gzip?hsLang=en-us)

Verdict, evaluated November 2026: serve Brotli at quality 11 for static text you can precompress, use zstd compression ...

Nov 3, 2026, 9:57:58 AM [Read more](https://blog.blazingcdn.com/en-us/zstandard-compression-for-the-web-zstd-vs-brotli-vs-gzip?hsLang=en-us)

[![Does a CDN Help SEO? How CDNs Affect Rankings and Core Web Vitals](https://blog.blazingcdn.com/hubfs/Gemini-Blog/image-Nov-01-2026-06-55-11-8888-AM.jpeg)](https://blog.blazingcdn.com/en-us/the-impact-of-cdn-on-seo-and-website-ranking?hsLang=en-us)

Web Performance

### [Does a CDN Help SEO? How CDNs Affect Rankings and Core Web Vitals](https://blog.blazingcdn.com/en-us/the-impact-of-cdn-on-seo-and-website-ranking?hsLang=en-us)

The short answer to "does CDN affect SEO" is yes, but indirectly. Google gives no ranking credit for using a CDN. As of ...

Nov 1, 2026, 7:58:07 AM [Read more](https://blog.blazingcdn.com/en-us/the-impact-of-cdn-on-seo-and-website-ranking?hsLang=en-us)

[![BlazingCDN](https://blog.blazingcdn.com/hubfs/Logo/blog-logo-w.png)](https://blog.blazingcdn.com?hsLang=en-us)

[📘 Learn](https://blog.blazingcdn.com/cdn-learn?hsLang=en-us) [📊 Benchmarks](https://blog.blazingcdn.com/cdn-ratings-and-benchmarks?hsLang=en-us) [🎬 Video & Streaming](https://blog.blazingcdn.com/video-streaming-cdn?hsLang=en-us) [🏭 Industries](https://blog.blazingcdn.com/cdn-industry-insights?hsLang=en-us) [💰 Pricing & Costs](https://blog.blazingcdn.com/cdn-pricing-and-cdn-costs?hsLang=en-us) [⚡ Compare](https://blog.blazingcdn.com/cdn-comparison?hsLang=en-us) [🔒 Security](https://blog.blazingcdn.com/cdn-security?hsLang=en-us) [🛠️ Tools](https://blog.blazingcdn.com/cdn-tools?hsLang=en-us) [✍️ Publish with us](https://blog.blazingcdn.com/publish-with-us?hsLang=en-us)

in f 𝕏 ✉

 Copyright © BlazingCDN |. All rights reserved.

```json
{
  "@context" : "https://schema.org",
  "@id" : "https://blazingcdn.com/#organization",
  "@type" : "Organization",
  "description" : "High-volume CDN for video, live streaming, OTT/IPTV, software, games, SaaS and large-file delivery.",
  "logo" : {
    "@id" : "https://blazingcdn.com/#logo",
    "@type" : "ImageObject",
    "height" : 560,
    "url" : "https://blazingcdn.com/wp-content/uploads/2024/08/logo-560-560.png",
    "width" : 560
  },
  "name" : "BlazingCDN",
  "sameAs" : [ "https://www.linkedin.com/company/blazingcdn", "https://x.com/BlazingCdn", "https://www.reddit.com/r/BlazingCDN/", "https://www.wikidata.org/wiki/Q141711074" ],
  "url" : "https://blazingcdn.com/"
}
```

```json
{
  "@context" : "https://schema.org",
  "@id" : "https://blog.blazingcdn.com/#website",
  "@type" : "WebSite",
  "inLanguage" : "en-US",
  "name" : "BlazingCDN Blog",
  "publisher" : {
    "@id" : "https://blazingcdn.com/#organization"
  },
  "url" : "https://blog.blazingcdn.com/"
}
```

```json
{
  "@context" : "https://schema.org",
  "@id" : "https://blog.blazingcdn.com/en-us/responsive-images-in-html-srcset-sizes-and-image-size#article",
  "@type" : "BlogPosting",
  "author" : {
    "@id" : "https://blog.blazingcdn.com/en-us/author/blazingcdn#person",
    "@type" : "Person",
    "description" : "Vadym Borovskyi is Chief Product and Marketing Officer at BlazingCDN, where he has led product strategy and growth since 2021. He has more than 11 years of experience in IT product management and B2B marketing. On this blog he writes about CDN pricing and egress costs, video and software delivery, cache configuration, and how teams evaluate and switch CDN providers. He is based in Warsaw, Poland.",
    "image" : "https://143144902.fs1.hubspotusercontent-eu1.net/hubfs/143144902/vadym-borovskyi.jpg",
    "jobTitle" : "Chief Product and Marketing Officer",
    "knowsAbout" : [ "Content Delivery Networks (CDN)", "CDN pricing", "Video streaming delivery", "Software and game distribution", "Cache optimization", "Product Management", "B2B Marketing", "Digital Marketing", "Pay Per Click Marketing (PPC)", "Google Ads", "Search Engine Marketing (SEM)", "Marketing Strategy", "Artificial Intelligence (AI)", "Cloud Management", "SaaS Development", "IT Consulting", "Computer Networking", "Project Management", "Startups" ],
    "name" : "Vadym Borovskyi",
    "sameAs" : [ "https://www.linkedin.com/in/axelt/" ],
    "url" : "https://blog.blazingcdn.com/en-us/author/blazingcdn",
    "worksFor" : {
      "@id" : "https://blazingcdn.com/#organization"
    }
  },
  "dateModified" : "2026-11-10T15:25:14Z",
  "datePublished" : "2026-11-10T15:25:14Z",
  "description" : "Learn HTML image size, srcset, sizes, and responsive images to optimize html image resize across devices and screens.",
  "headline" : "Responsive Images in HTML: srcset, sizes and Image Size",
  "image" : "https://143144902.fs1.hubspotusercontent-eu1.net/hubfs/143144902/Gemini-Blog/image-Nov-10-2026-03-22-17-0551-PM.jpeg",
  "inLanguage" : "en-us",
  "isPartOf" : {
    "@id" : "https://blog.blazingcdn.com/#website"
  },
  "mainEntityOfPage" : {
    "@id" : "https://blog.blazingcdn.com/en-us/responsive-images-in-html-srcset-sizes-and-image-size",
    "@type" : "WebPage"
  },
  "publisher" : {
    "@id" : "https://blazingcdn.com/#organization"
  },
  "wordCount" : 2164
}
```

```json
{
  "@context" : "https://schema.org",
  "@id" : "https://blog.blazingcdn.com/en-us/responsive-images-in-html-srcset-sizes-and-image-size#breadcrumb",
  "@type" : "BreadcrumbList",
  "itemListElement" : [ {
    "@type" : "ListItem",
    "item" : "https://blog.blazingcdn.com/en-us",
    "name" : "Blog",
    "position" : 1
  }, {
    "@type" : "ListItem",
    "item" : "https://blog.blazingcdn.com/en-us/responsive-images-in-html-srcset-sizes-and-image-size",
    "name" : "Responsive Images in HTML: srcset, sizes and Image Size",
    "position" : 2
  } ]
}
```

```json
{
  "@context" : "https://schema.org",
  "@id" : "https://blog.blazingcdn.com/en-us/responsive-images-in-html-srcset-sizes-and-image-size#faq",
  "@type" : "FAQPage",
  "mainEntity" : [ {
    "@type" : "Question",
    "acceptedAnswer" : {
      "@type" : "Answer",
      "text" : "The browser assumes the image renders at 100vw, the full viewport width. On a 1,440 pixel desktop where the image sits in a 584 pixel column, that makes it fetch a file sized for 1,440 CSS pixels times the DPR. Width descriptors without an accurate sizes attribute therefore often download more bytes than a single well-chosen src would."
    },
    "name" : "What happens if I use srcset without sizes?"
  }, {
    "@type" : "Question",
    "acceptedAnswer" : {
      "@type" : "Answer",
      "text" : "Yes, always set width and height on responsive images, using any pair that matches the intrinsic aspect ratio. Browsers convert them into a CSS aspect ratio and reserve the box before the file loads, which prevents layout shift. Pair them with CSS width 100% and height auto so the image scales to its container without distortion."
    },
    "name" : "Should I still set width and height on responsive images?"
  }, {
    "@type" : "Question",
    "acceptedAnswer" : {
      "@type" : "Answer",
      "text" : "Most templates need four to six srcset widths. Multiply each measured slot width by the DPR values you support, round into a short ladder, and check the gaps: adjacent steps that differ by a width ratio r waste at most r squared in pixels. Anchoring steps on real targets usually keeps overfetch near 1.1 times."
    },
    "name" : "How many srcset widths should a responsive image have?"
  }, {
    "@type" : "Question",
    "acceptedAnswer" : {
      "@type" : "Answer",
      "text" : "Yes, srcset works with lazy loading, and the sizes value auto is valid only on lazy-loaded images. With auto, the browser waits for layout and uses the real rendered width, so sizes can no longer drift from CSS. Chrome shipped it in 2024; list a normal sizes fallback after auto for browsers that lack support."
    },
    "name" : "Does srcset work with lazy loading and sizes auto?"
  } ]
}
```