Responsive Images: Serving the Right Size for Every Screen

Posted Jun 17, 2025

By Joey

11 min read

In today’s multi-device world, delivering a great user experience means ensuring your website looks and performs flawlessly on everything from a tiny smartphone to a high-resolution desktop monitor. Images, often the heaviest components of a web page, play a critical role in this. Serving unnecessarily large images to small screens wastes bandwidth and slows down loading, while small images on large, high-resolution displays appear blurry and pixelated.

This article explores two prominent approaches to displaying different image sizes on different layouts: the JavaScript-based solution exemplified by jQuery Foundation’s Interchange and the modern, native HTML attributes srcset and <picture>. We’ll provide examples and dissect their pros and cons to help you choose the best strategy for your projects.

The Challenge of Responsive Images

The core problem is simple: a single image file cannot optimally serve all devices.

Small Screens (Mobile Phones): Need smaller, lighter image files to conserve data and load quickly on potentially slower mobile networks.
Large Screens (Desktops/Laptops): Can handle larger, higher-quality images, but still benefit from efficient loading.
High-Resolution (“Retina”) Displays: Require images with double (or more) the pixel density to appear sharp and crisp.

Method 1: JavaScript-Based Solutions (e.g., jQuery Foundation Interchange)

JavaScript libraries like Foundation’s Interchange (and similar plugins for other frameworks or standalone scripts) were among the first robust solutions for responsive images. They work by dynamically changing the src attribute of an <img> tag based on client-side conditions.

How it Works (Foundation Interchange):

Interchange leverages the data-interchange HTML attribute. You define a list of image paths paired with media queries. When the page loads, or the viewport changes, Interchange evaluates these media queries and updates the <img> tag’s src to the path of the first matching rule.

Example:

  
<img
  class="logo"
  id="logo_dickens"
  data-interchange="[/assets/course_logos/x1/dickens-default.png, (default)], [/assets/course_logos/x2/dickens-retina.png, (retina)], [/assets/course_logos/x3/dickens-large.png, (large)]"
  src="/assets/course_logos/x1/dickens-default.png"
  alt="Dickens Logo"
/>

<script src="/path/to/jquery.js"></script>
<script src="/path/to/foundation.js"></script>
<script src="/path/to/foundation.interchange.js"></script>
<script>
  $(document).foundation(); // Initializes Interchange and other Foundation components
</script>

In this example:

/assets/course_logos/x1/dickens-default.png is loaded by default.
/assets/course_logos/x2/dickens-retina.png is loaded on high-resolution (Retina) screens.
/assets/course_logos/x3/dickens-large.png is loaded when the viewport matches Foundation’s (large) breakpoint.

The src attribute provides a fallback if JavaScript is disabled or fails.

Pros of JavaScript Solutions:

Fine-Grained Control: Can handle complex logic and custom conditions beyond standard media queries.
Legacy Browser Support: For a time, these were the only reliable ways to achieve responsive images across older browsers.
Centralized Logic: Image selection logic is often managed within JavaScript, which can be convenient for developers familiar with that paradigm.
Dynamic Scenarios: Useful for images loaded via AJAX or added to the DOM after initial page load, as you can reinitialize the script.

Cons of JavaScript Solutions:

Performance Hit (FOUC & Double Downloads):
- “Flash of Unstyled Content” (FOUC): The browser typically starts downloading the src image before JavaScript executes. If Interchange then decides to load a different image, the initially downloaded image is discarded, leading to wasted bandwidth and a potential flicker as the new image replaces the old one.
- JavaScript Dependency: If JavaScript is blocked, fails, or loads slowly, the responsive behavior won’t work, and only the fallback src image will be displayed (which might be too large or too small).
Increased Code Complexity: Requires including and managing additional JavaScript libraries.
Less Semantic HTML: The logic for responsive images is pushed into JavaScript, making the HTML less self-describing.

Method 2: Native HTML Attributes (`srcset` and `<picture>`)

Modern web standards offer powerful and performant native solutions directly within HTML, reducing the reliance on JavaScript for core responsive image functionality.

2.1. The `srcset` Attribute (on `<img>`)

The srcset attribute on the <img> tag is ideal for resolution switching (serving different resolutions of the same image) and basic width-based switching (serving different sizes of the same image).

How it Works:

You provide a comma-separated list of image URLs, each with a descriptor (e.g., 1x, 2x for pixel density, or 400w, 800w for intrinsic width). The browser intelligently picks the most appropriate image based on the user’s device pixel ratio, viewport size, and network conditions.

Understanding `srcset` Descriptors: `x` vs. `w`

The two main types of descriptors tell the browser about the image in different ways, influencing how it makes its selection.

a) Pixel Density Descriptor (x) - For Resolution Switching

Purpose: Used when you want to serve different pixel densities of the same image where the image will occupy roughly the same CSS dimensions on the page regardless of screen size. This is perfect for “Retina” support.
How it works: The browser checks the device’s pixel ratio (e.g., a standard display is 1x, a Retina display is typically 2x or 3x). It then picks the image with the matching or closest higher x descriptor.
Syntax: URL Nx (where N is a non-negative number).

Example (x descriptor):

This is most common for logos or small fixed-size UI elements where sharpness is key on high-res screens.

  
<img
  class="logo"
  id="logo_dickens"
  srcset="
    /assets/course_logos/x1/dickens-default.png 1x,
    /assets/course_logos/x2/dickens-retina.png 2x,
    /assets/course_logos/x3/dickens-super-retina.png 3x
  "
  src="/assets/course_logos/x1/dickens-default.png"
  alt="Dickens Logo"
/>

In this example:

On a standard display (1x DPR), dickens-default.png is loaded.
On a Retina MacBook (2x DPR), dickens-retina.png is loaded.
On an iPhone Pro Max (3x DPR), dickens-super-retina.png is loaded.
The src attribute serves as a crucial fallback for browsers that don’t support srcset (though modern browsers universally do) and as the default if no x descriptor matches.

When to use x: Ideal for fixed-width images like logos, icons, or avatars where the visual dimensions don’t change, but you need higher resolution versions for sharper displays.

b) Width Descriptor (w) - For Width-Based Switching (and often with sizes)

Purpose: Used when you have images that will be displayed at different CSS widths on different layouts (e.g., a hero image that’s 100% width on mobile but 50% width on desktop). You specify the intrinsic width of each image file.
How it works: This descriptor is almost always used in conjunction with the sizes attribute. The sizes attribute tells the browser how wide the image will be displayed on the page at different viewport conditions (e.g., 50vw, (max-width: 600px) 100vw). The browser then uses this information, along with the w descriptors, to calculate the most efficient image to download. It aims to download an image whose intrinsic width is closest to the rendered width at the current resolution.
Syntax: URL Nw (where N is the image’s intrinsic width in pixels).
Crucial Companion: The sizes attribute is required when using w descriptors to provide the browser with context about the image’s display size.

Example (w descriptor with sizes):

Consider a hero image that spans the full width on small screens but takes up 60% of the screen on larger desktops.

  
<img
  class="hero-image"
  srcset="
    /assets/hero-small.jpg   480w,
    /assets/hero-medium.jpg  800w,
    /assets/hero-large.jpg  1200w,
    /assets/hero-xlarge.jpg 1600w
  "
  sizes="
    (max-width: 600px) 100vw,   /* Up to 600px viewport, image is 100% viewport width */
    (max-width: 1024px) 70vw,   /* Up to 1024px viewport, image is 70% viewport width */
    60vw                        /* Otherwise (larger screens), image is 60% viewport width */
  "
  src="/assets/hero-medium.jpg"
  alt="Beautiful mountain landscape"
/>

In this example:

srcset: Defines several versions of the hero-image with their actual pixel widths (e.g., hero-small.jpg is 480 pixels wide).
sizes: Provides a set of media conditions and corresponding display widths (e.g., if the viewport is up to 600px wide, the image will take up 100% of the viewport width, 100vw).
The browser performs calculations: if on a mobile phone (viewport 360px) and the image is 100vw, it needs roughly a 360px wide image. It will then look at srcset and might download hero-small.jpg (480w) as it’s the closest suitable size. On a large desktop (viewport 1920px) where the image is 60vw (1152px), it might choose hero-large.jpg (1200w).

When to use w with sizes: Ideal for images that scale with the viewport (fluid images), such as hero banners, content images, or gallery items. It allows the browser to download the smallest possible image that still looks good at its rendered size and pixel density.

2.2. The `<picture>` Element

The <picture> element is used for art direction (displaying different image content based on media queries) or format switching (serving different image file types).

How it Works:

The <picture> element acts as a wrapper for multiple <source> elements and a single <img> tag. The browser iterates through the <source> elements, looking for the first one whose media attribute (a CSS media query) and/or type attribute (image MIME type) matches the current environment. If a match is found, the srcset specified in that <source> is used. If no <source> matches, or if the browser doesn’t support <picture>, the fallback <img> tag is used.

Example (Art Direction - cropping for smaller screens):

Sometimes simply scaling an image isn’t enough; you might need to show a different crop or even a different image entirely.

  
<picture>
  <source
    media="(max-width: 600px)"
    srcset="/assets/product-cropped-small.jpg 1x, /assets/product-cropped-small-retina.jpg 2x"
    type="image/jpeg"
  />

  <source
    media="(min-width: 601px) and (max-width: 1200px)"
    srcset="/assets/product-landscape-medium.jpg 1x, /assets/product-landscape-medium-retina.jpg 2x"
    type="image/jpeg"
  />

  <source
    media="(min-width: 1201px)"
    srcset="/assets/product-wide-large.jpg 1x, /assets/product-wide-large-retina.jpg 2x"
    type="image/jpeg"
  />

  <img
    src="/assets/product-full-default.jpg"
    alt="Detailed view of product across different perspectives"
    class="product-detail"
  />
</picture>

In this example:

On small screens (max-width: 600px), a product-cropped-small.jpg (and its retina version) is served, focusing on the main subject.
On medium screens (min-width: 601px and max-width: 1200px), a product-landscape-medium.jpg (and its retina version) provides a broader view.
On large screens (min-width: 1201px), the product-wide-large.jpg (and its retina version) gives the most expansive view.
Notice how srcset with x descriptors can be used within each <source> to handle retina for each art-directed image.

Example (Format Switching - WebP for modern browsers, PNG fallback):

This allows you to leverage newer, more efficient image formats (like WebP or AVIF) for browsers that support them, while gracefully falling back to widely supported formats like PNG or JPEG for older browsers.

  
<picture>
  <source
    srcset="/assets/logo.webp 1x, /assets/logo-retina.webp 2x"
    type="image/webp"
  />
  <source
    srcset="/assets/logo.png 1x, /assets/logo-retina.png 2x"
    type="image/png"
  />
  <img src="/assets/logo.png" alt="Company Logo" class="logo" />
</picture>

In this example:

A browser supporting WebP will first check the image/webp source. If the device is Retina, it will load logo-retina.webp; otherwise, logo.webp.
If WebP is not supported, the browser moves to the next source, image/png. It will then load the appropriate PNG version based on the device’s pixel ratio.
The final <img> tag serves as a universal fallback.

Key Advantages of Native HTML/CSS Solutions:

Performance: The browser can make smart decisions about which image to load before any JavaScript runs, potentially speeding up page load times and reducing unnecessary downloads.
Reliability: Works even if JavaScript is disabled or fails to load.
Standardization: These are official web standards, ensuring better long-term compatibility and understanding across browsers.
SEO: Search engines can more easily understand and index image content when it’s natively defined in HTML.

Comparison Summary

Feature	jQuery Foundation Interchange	`srcset` & `<picture>` (Native HTML)
Implementation	JavaScript library + `data-*` attributes	HTML attributes/elements
Performance	Potential FOUC, double downloads, JS dependent	Browser optimized, faster, no FOUC
Reliability	JS dependent	Works without JS
Primary Use Cases	Resolution/width switching, complex JS logic	`srcset`: Resolution (`x`) & Basic Width (`w`) switching. <br> `<picture>`: Art direction, Format switching.
Code Structure	JS manages logic, cleaner HTML attributes	HTML contains all logic, potentially verbose
Browser Support	Excellent (with JS enabled)	Excellent (modern browsers)
Maintainability	Requires JS knowledge/updates	Standard HTML/CSS knowledge

Conclusion and Recommendations

For new projects or modernizing existing ones, the native HTML srcset and <picture> elements are almost always the superior choice for responsive images. They offer significant performance benefits, are more reliable, and leverage the browser’s built-in optimization capabilities.

For simple resolution switching (e.g., 1x and 2x images for Retina displays), use <img> with the srcset attribute and x descriptors. This is the most direct and efficient solution.
For images that scale fluidly with the viewport, requiring different image files for different display widths, use <img> with srcset and w descriptors, always paired with the sizes attribute. This allows the browser to select the optimal file based on the image’s actual rendered width.
For “art direction” (displaying different image content/crops based on layout) or “format switching” (e.g., WebP vs. PNG), use the <picture> element. This gives you precise control over which image to serve based on media queries or browser capabilities.

While jQuery Foundation’s Interchange was a valuable tool in its time, the web platform has evolved. Embracing native HTML solutions for responsive images leads to faster, more robust, and future-proof websites.

web development, responsive design

This post is licensed under CC BY 4.0 by the author.

The Challenge of Responsive Images

Method 1: JavaScript-Based Solutions (e.g., jQuery Foundation Interchange)

Method 2: Native HTML Attributes (srcset and <picture>)

2.1. The srcset Attribute (on <img>)

Understanding srcset Descriptors: x vs. w

2.2. The <picture> Element

Comparison Summary

Conclusion and Recommendations

Trending Tags

Method 2: Native HTML Attributes (`srcset` and `<picture>`)

2.1. The `srcset` Attribute (on `<img>`)

Understanding `srcset` Descriptors: `x` vs. `w`

2.2. The `<picture>` Element