I'm troubleshooting an issue loading images published to Experience Edge using the image sizing parameters, e.g. mw= (reference). As an example, let's say the Experience Edge URL for a published image coming down from the layout service when a page is requested is:


This URL resolves as expected (200) when browsed directly (so the image clearly "made it" to Experience Edge during the publish). In the Next.js head application (Sitecore JSS 21.0.0; hosted on Vercel, FWIW) we're using srcset to optimize the loading of images (reference). The image component looks like this:

import { Image } from '@sitecore-jss/sitecore-jss-nextjs';
<Image field={props?.fields?.Image} srcSet={[{ mw: 991 }]} className="img-responsive" loading="lazy" />

The image URL requested by the browser ends up being:


This URL does not resolve as expected (404) and returns the following response body:

ERROR 9404: Could not fetch the image — the server returned HTTP error 404 Not Found

And the following response headers:

HTTP/2 404 
date: Thu, 11 Apr 2024 19:56:07 GMT
content-type: text/plain;charset=utf-8
cf-ray: 872d89c1fe24676e-ATL
cf-cache-status: MISS
cache-control: max-age=30
vary: Accept, Accept-Encoding
cf-resized: err=9404
content-security-policy: default-src 'none'; navigate-to 'none'; form-action 'none'
x-content-type-options: nosniff
x-origin-error: true
server: cloudflare
content-encoding: gzip
alt-svc: h3=":443"; ma=86400
X-Firefox-Spdy: h2

Interestingly, if &sc_lang=en is appended to the broken URL, it does resolve, for whatever reason. Also noteworthy, I guess, is that requesting the image URL without any parameters (meaning: https://edge.sitecorecloud.io/<tenant-name>/media/Images/Foo/Bar/image.jpg) also throws a 404 but with this (XML) response body:

<?xml version="1.0" encoding="utf-8"?>
  <Message>The specified blob does not exist. RequestId:b52e362e-101e-006e-8050-8c8a81000000 Time:2024-04-11T20:37:05.7771855Z</Message>

What's really odd is that there are long-standing images that are published and referenced in the same way (and on the same page) whose URLs still resolve just fine--and they don't include the sc_lang=en parameter. If including this parameter is a requirement (which seems unlikely) then I'd expect all images referenced in the same way to be breaking and they aren't. For example, this URL resolves as expected:


This is happening across all three of our XM Cloud environments and their corresponding Experience Edge tenants.

Has anyone seen this or something similar? What gives?

  • I've opened a Sitecore support ticket for this issue. Support seems to suspect that it's something to do with the language, but we haven't made any changes to the installed or configured languages; the solution uses just one language: en. Support also said that they don't think this issue is related to the Experience Edge service issue that affected images reported (and resolved) earlier this week (support.sitecore.com/…). Commented Apr 11 at 20:59
  • First, there was a recent change in EEdge; a bug was fixed for versioned media items. The fix requires that the sc_lang parameter be passed to EEdge (I think this was the change: developers.sitecore.com/changelog/xm-cloud/…). Second, our solution happens to be using the <Image> component in the @sitecore-jss/sitecore-jss-nextjs (21.0.0) package with the srcSet property; internally, the component strips the sc_lang parameter from the resolved srcset URL, causing the 404s. We're testing a code change to include the parameter. Commented Apr 15 at 18:53

1 Answer 1


Sitecore support confirmed that this issue is reproduceable in @sitecore-jss/sitecore-jss-nextjs version 21.6.0. The issue is being tracked under reference number JSS-1902 and will be addressed in a future release.

There were two contributing factors leading to the 404 errors:

  1. In the last ~2 months or so (based on feedback from Sitecore support and judging loosely from this XM Cloud changelog entry), there was a bug fix that affected the way versioned media items are published to and fetched from Experience Edge. The net out being: if a media item is using a versioned media template and is published to Experience Edge, then the sc_lang query string parameter is required in order to fetch the image from Experience Edge. Prior to this fix, the parameter was not required.
  2. The Image component in the @sitecore-jss/sitecore-jss-nextjs package strips the sc_lang parameter off of the image URL coming down from the layout service when processing URLs that end up in the srcset attribute of the resulting <img> tag (by way of the component's srcSet property).


If you're experiencing this issue and don't want to wait for an official bug fix, then you need to ensure that you're retaining the sc_lang parameter within the srcset attribute in the rendered markup such that the HTTP GET from Experience Edge is a 200.

I implemented a helper function to do this. The function checks the image URL coming down from the layout service for the sc_lang parameter and, if present, adds an entry to the array passed into the srcSet attribute, as suggested by Sitecore support. Here's the function:

export const buildSrcSetParams = (imageSizeParameters: ImageSizeParameters[] | undefined, image: ImageField): ImageSizeParameters[] | undefined => {
  let retVal = imageSizeParameters;
  if (!image?.value?.src) {
    return retVal;
  const queryParams = new URLSearchParams(image.value.src.split('?')[1]);
  const scLangParam = queryParams.get('sc_lang');
  if (retVal && scLangParam) {
    // add sc_lang parameter
    retVal = retVal.map((isp) => ({
      sc_lang: scLangParam,
  return retVal;

In the renderings, any Image component using the srcSet property was updated from this:

<Image field={props?.fields?.Image} srcSet={ [ { mw: 991 } ] } ... />

...to this:

<Image field={props?.fields?.Image} srcSet={buildSrcSetParams([ { mw: 991 } ], props?.fields?.Image)} ... />

For versioned images published to Experience Edge, this results in a srcSet property value of, for example:

[ { mw: 991, sc_lang: 'en' } ]

...which in turn results in a srcset attribute image URL in the rendered markup of:


...as opposed to:


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.