How to Build Responsive Images with srcset and a DAM

Responsive images let the browser choose an image that matches the layout and device instead of downloading one oversized file everywhere. A DAM makes the pattern maintainable by keeping one managed source asset and exposing predictable delivery URLs for the widths and formats your page needs.

Stashr supports explicit width, height, fit, format, and quality parameters. Combined with HTML srcset, sizes, and picture, those URLs cover a practical responsive-image workflow without storing a separate file for every breakpoint.

Why one image URL is rarely enough

Imagine a content image displayed at these sizes:

• 360 pixels wide on a phone;
• 720 pixels wide in a tablet layout;
• 1200 pixels wide on desktop;
• twice those device pixels on a high-density screen.

Serving the largest source to every visitor wastes delivery bytes. Serving only the smallest source makes the image soft when the layout or display needs more detail.

The browser already knows the viewport, layout, pixel density, and supported formats. Responsive image markup gives it a set of valid choices.

Google's responsive images guide explains how srcset lets the browser select an appropriate source. The important implementation detail is that the candidate URLs must be easy to produce and maintain.

The Stashr transform surface

Start from a canonical delivery URL returned by Stashr:

https://stashr.dev/acme/docs/guide/dashboard.optimized.webp

Request a width and format using short query parameters:

?w=640&format=webp&q=80

Stashr supports:

The service does not enlarge beyond the source dimensions. Transforms apply only to images, are generated on demand, and do not create additional assets in the library.

A width-based srcset

For a content image that follows the width of its container, provide several candidates with width descriptors:

<img
  src="https://stashr.dev/acme/docs/guide/dashboard.webp?w=800&format=webp&q=82"
  srcset="
    https://stashr.dev/acme/docs/guide/dashboard.webp?w=480&format=webp&q=80 480w,
    https://stashr.dev/acme/docs/guide/dashboard.webp?w=800&format=webp&q=82 800w,
    https://stashr.dev/acme/docs/guide/dashboard.webp?w=1200&format=webp&q=84 1200w,
    https://stashr.dev/acme/docs/guide/dashboard.webp?w=1600&format=webp&q=84 1600w
  "
  sizes="(max-width: 700px) 100vw, 700px"
  alt="Asset library showing project folders and image thumbnails"
  width="1600"
  height="1000"
/>

The src value remains a dependable fallback. Each srcset candidate declares its intrinsic width with a w descriptor. The sizes attribute tells the browser how wide the image is expected to render under the page's layout rules.

The browser, not your JavaScript, selects the candidate.

Write sizes from the layout, not the device list

A common mistake is to copy CSS breakpoints into sizes without describing the actual rendered width.

If an article column is full-width below 700 pixels and 700 pixels wide above it, this is appropriate:

(max-width: 700px) 100vw, 700px

If a card occupies half the viewport above 900 pixels, with 32 pixels of surrounding space, the rule may be closer to:

(min-width: 900px) calc(50vw - 32px), 100vw

The exact expression comes from the CSS layout. An inaccurate sizes value can make the browser choose a needlessly large or visibly small source.

Add AVIF and WebP with picture

Stashr does not automatically negotiate the output format. Use picture to offer formats explicitly:

<picture>
  <source
    type="image/avif"
    srcset="
      https://stashr.dev/acme/docs/guide/dashboard.webp?w=480&format=avif&q=78 480w,
      https://stashr.dev/acme/docs/guide/dashboard.webp?w=800&format=avif&q=80 800w,
      https://stashr.dev/acme/docs/guide/dashboard.webp?w=1200&format=avif&q=82 1200w
    "
    sizes="(max-width: 700px) 100vw, 700px"
  />
  <source
    type="image/webp"
    srcset="
      https://stashr.dev/acme/docs/guide/dashboard.webp?w=480&format=webp&q=80 480w,
      https://stashr.dev/acme/docs/guide/dashboard.webp?w=800&format=webp&q=82 800w,
      https://stashr.dev/acme/docs/guide/dashboard.webp?w=1200&format=webp&q=84 1200w
    "
    sizes="(max-width: 700px) 100vw, 700px"
  />
  <img
    src="https://stashr.dev/acme/docs/guide/dashboard.webp?w=800&format=jpeg&q=88"
    alt="Asset library showing project folders and image thumbnails"
    width="1600"
    height="1000"
  />
</picture>

The browser evaluates sources in order and uses the first supported type. Keep the fallback img as the final child.

For the format trade-offs and quality workflow, read how to convert PNG and JPEG images to WebP or AVIF.

Fixed-ratio cards and thumbnails

Cards often need a consistent box regardless of source aspect ratio. Request both dimensions with fit=cover:

?w=640&h=360&fit=cover&format=webp&q=80

Create candidates at the same ratio:

<img
  src="https://stashr.dev/acme/site/articles/cover.webp?w=640&h=360&fit=cover&format=webp&q=80"
  srcset="
    https://stashr.dev/acme/site/articles/cover.webp?w=320&h=180&fit=cover&format=webp&q=78 320w,
    https://stashr.dev/acme/site/articles/cover.webp?w=640&h=360&fit=cover&format=webp&q=80 640w,
    https://stashr.dev/acme/site/articles/cover.webp?w=960&h=540&fit=cover&format=webp&q=82 960w
  "
  sizes="(min-width: 900px) 33vw, 100vw"
  alt="Abstract asset delivery workflow"
  width="16"
  height="9"
/>

Cropping is mechanical. If the subject needs different framing on mobile and desktop, use separate art-directed assets or separate picture sources. A transform cannot know the creative focal point unless the crop naturally works.

Preserve layout stability

Set width and height attributes on the img element using the source aspect ratio. Browsers use those values to reserve space before the image arrives, while CSS can still make the image fluid:

img {
  display: block;
  max-width: 100%;
  height: auto;
}

For a fixed-ratio card, CSS aspect-ratio and object-fit can define the presentation. The delivery transform should use the same ratio so transferred pixels are not immediately discarded by the browser.

Alt text belongs to the page context

Stashr lets you store alt text with asset metadata. That is useful for asset management and provides a strong default description. The final HTML alt should still reflect the purpose of the image where it appears.

The same screenshot could be informative in documentation, decorative in a hero, or a link target in a card. Those contexts may require different alternative text. Do not use a filename as a substitute.

Choose a small candidate set

More widths are not automatically better. Every distinct transform URL is a valid delivery request and a cacheable variant, but a dense list is harder to review and may provide little practical saving.

Start with widths that match real layout ranges, for example:

• 480 for narrow phones and compact cards;
• 800 for article columns and tablets;
• 1200 for larger content regions;
• 1600 for wide or high-density presentations.

Measure your actual CSS and source dimensions. Stashr will not upscale a 900-pixel source into a genuine 1600-pixel image, so keep an appropriate source for the largest candidate.

Delivery and caching considerations

Transformed bytes count toward the workspace delivery allowance. A small source set helps browsers avoid waste, but traffic still needs to be monitored.

Delivery URLs are public and unlisted. Stashr does not currently provide signed URLs, automatic format negotiation, video transforms, or custom delivery domains. If those are requirements, choose an architecture that supplies them.

The dashboard shows storage and delivery usage. Current allowances and prepaid delivery bundles are listed at Stashr pricing.

A responsive-image checklist

• Upload a source large enough for the largest real presentation.
• Use the canonical deliveryUrl returned by Stashr.
• Select a few candidate widths from the CSS layout.
• Write an accurate sizes attribute.
• Use picture when explicit format fallbacks are needed.
• Match crop ratios between delivery transforms and CSS containers.
• Add meaningful contextual alt text.
• Include intrinsic dimensions to reduce layout movement.
• Inspect image quality and transferred bytes on real viewports.
• Monitor delivery rather than assuming every transform saves bandwidth.

Responsive images are a browser capability, not a JavaScript image loader. A DAM makes them easier by turning one organized source asset into a predictable family of URLs.

Explore the image transform reference, review how Stashr compares with Cloudinary, or start a workspace and build a source set from one of your real product images.