SPFx 1.21.1 version has issue loading images from SharePoint public CDN

[DakSanjay]

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

• 💥 Internet Explorer
• 💥 Microsoft Edge
• 💥 Google Chrome
• 💥 FireFox
• 💥 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.

[Ashlesha-MSFT]

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

[Ashlesha-MSFT]

@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!