SPFx 1.21.1 version has issue loading images from SharePoint public CDN

Target SharePoint environment

SharePoint Online

What SharePoint development model, framework, SDK or API is this about?

💥 SharePoint Framework

Developer environment

macOS

What browser(s) / client(s) have you tested

• [x] 💥 Internet Explorer
• [x] 💥 Microsoft Edge
• [x] 💥 Google Chrome
• [x] 💥 FireFox
• [x] 💥 Safari
• [ ] mobile (iOS/iPadOS)
• [ ] mobile (Android)
• [ ] not applicable
• [ ] other (enter in the "Additional environment details" area below)

Additional environment details

• browser version : 138.0.7204.169
• SPFx version: 1.21.1
• Node.js version : v22.17.0

Describe the bug / error

SPFx 1.21.1 version has issue loading images from SharePoint public CDN when png/jpg is used. Works when we use svg file.

Steps to reproduce

Use SPFx 1.21.1 & create a basic webpart which loads image (png/jpg) from SharePoint Public CDN (enabled through powershell). If we use svg file instead it works.

Expected behavior

Expected behavior is that the image should load regardless of type which was working before the SPFx upgrade.

Note: It works when we use svg file.

Hello @DakSanjay, Thank you for bringing this issue to our attention. We will look into it and get back to you shortly.

@DakSanjay, I’ve been working on enabling public access to a .svg file via SharePoint’s Public CDN and have done the following:

• Enabled the Public CDN via PowerShell.
• Verified the default origin paths are active: */CLIENTSIDEASSETS, */STYLE LIBRARY, and */MASTERPAGE.
• Placed the .svg in a document library on the site.
• Checked the Admin Center for any global or site-level access restrictions.

However, I'm still getting an "Access Denied" error when trying to access the SVG through the publiccdn.sharepointonline.com URL.

Could you please review and let me know if I’m missing anything? Specifically:

• Does the document library path (Shared Documents) need to be part of a registered CDN origin? If so, should I move the file to a folder like */CLIENTSIDEASSETS instead?
• Are there library-level settings (e.g. content approval, check-in, versioning) that might be blocking anonymous access?
• Are there file-specific permission considerations or any caching delays in the CDN setup I should be aware of?

Thanks!

Hello @Ashlesha-MSFT. I'm having a similar issue with this. I suspect it is the same issue as #10337. Upon further investigation, I found that SPFx's build task seems to be mangling my pngs by adding a binary EF BF BD (Unicode repalcement character) to the beginning of the PNG, see screenshots below:

@DakSanjay, @tgorgdotcom We tested the scenario by creating an SPFx 1.21.1 web part using PNG assets and enabling the SharePoint Public CDN with the */CLIENTSIDEASSETS origin. After deploying to SharePoint Online, all PNG images loaded successfully (HTTP 200) with no issues observed. At this time, we’re unable to reproduce the issue in our environment — it may be tenant-specific or related to configuration. To assist further, we kindly request affected users to share additional details such as specific CDN URLs, error messages, tenant region, and a minimal repro sample if possible.

@Ashlesha-MSFT: for me I receive no errors, and the problem occurs at the time of bundling, so it doesn't matter which region it occurs. I'll have to do some more investigation and get back to you.

I'm having the exact same issue as @tgorgdotcom. All .png files included in the solution folder are corrupted during the bundling process and can no longer be read. During development everything appears normal since the images are served directly from the dist folder when using a local server.

@Ashlesha-MSFT, did you by any chance test this on a Mac?

@LastGunslinger, what OS are you using?

Note: I am running macOS

Looking at this again because I'm trying to push an update of a webpart with a lot of images, I just realized that it's also doubling the size of the file, and replacing all sorts of data with EF BF BD

Okay I have found the error. This looks to be an issue with using gulp 5: https://github.com/gulpjs/gulp/issues/2777

A few lines near the end of a gulpfile.js (before the build.initialize(gulp);) should fix it:

// patch gulp.src
gulp.parentSrc = gulp.src
gulp.src = (globs, options = {}) => {
  options.encoding = false
  return gulp.parentSrc(globs, options)
}

I am very disappointed with Microsoft support. This is not the first time I have to figure out a workaround for an issue that should have been better supported (the last time involved nights and days with lack of sleep).

Oh my god @tgorgdotcom, thank you so much for this. I share your frustration, I've also spent a ton of time fixing my own issues after reaching out to MS on GitHub. If nothing else comes of it, just know that I appreciate the time and effort that you put into to hunting this down.

@Ashlesha-MSFT / @VesaJuvonen any comments on the above fix? It's been more than a month since you provided a response to this bug.

@tgorgdotcom I know it's not of much help, but SPFx v1.22.0 sort of sidesteps this issue by doing away with Gulp altogether in favor of Heft. I'm testing it out right now, and one of the nice things is that I don't need to worry about patching this problem any longer. Upgrading to 1.22 is a little more involved than a lot of the previous upgrades, but I am supportive of MS at least taking some steps to modernize their build process. We were basically forced to upgrade quickly because of a dependency that we need to upgrade that requires TypeScript >= 5.

Makes sense. Let's hope that will help the team at MS streamline some things. I know they are trying for sure.