BUG: incorrect url encoding in <link rel="preload"> for prioritized images

[HelaGone]

Link to the code that reproduces this issue

https://github.com/HelaGone/image_testing

To Reproduce

1. build the application
2. start the server
3. visit the provided url
4. right click and select view source code
5. search for the link rel=preload of the imageSrcSet

7. see the wrong encoding of the & it's & and should be & or %26
8. copy the path and concatenate the path with the localhost:3000
9. see the error in the browser: "w" parameter (width) is required

Current vs. Expected behavior

current behavior is the error in the browser:

Expected behaviour:
The image should resolve correctly in the browser.

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 23.5.0: Wed May  1 20:12:58 PDT 2024; root:xnu-10063.121.3~5/RELEASE_ARM64_T6000
  Available memory (MB): 32768
  Available CPU cores: 10
Binaries:
  Node: 20.9.0
  npm: 10.1.0
  Yarn: 1.22.21
  pnpm: N/A
Relevant Packages:
  next: 15.0.0-canary.118 // Latest available version is detected (15.0.0-canary.118).
  eslint-config-next: N/A
  react: 19.0.0-rc-49496d49-20240814
  react-dom: 19.0.0-rc-49496d49-20240814
  typescript: 5.3.3
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

Image (next/image)

Which stage(s) are affected? (Select all that apply)

Other (Deployed)

Additional context

This is affecting our application in production and reporting Google Search Console errors

Here is a production with wrong encoding

The same image with proper encoding:

[HelaGone]

hello Vercel / Next team. Do you have any update or eta to review this bug? Is there something we can do to solve this issue without losing the image optimization?

[Mohamed-Asar]

@HelaGone I'm also facing the same issue

[ica-nis]

We are also facing this issue. Firefox and Chrome seems to be automatically applying some html decoding on the preload url, thus avoiding this issue, but Safari does not, causing a lot of unnecessary 400 errors on our back end.

[samcx]

@HelaGone I'm currently unable to replicate this with the on the latest canary (on both Chrome and Safari).

[samcx]

@HelaGone Sorry I made a typo, I meant to say I was unable to replicate

[HelaGone]

@samcx so do you think this will be solved in the latest releases?

[samcx]

@HelaGone Possibly. Can you try verifying that it's fixed for you on the latest stable or canary?

[Mohamed-Asar]

@samcx you are getting the image url in inspect element, browser will convert & to &, but if you view the source code like @HelaGone mentioned in the screenshot, you can able to reproduce the issue

[samcx]

@Mohamed-Asar @HelaGone My apologies! I see now. Taking another look!

[Vignesh-M21]

@samcx Can you please check this discussion #37340

@HelaGone can you please correct me If I am wrong

I set a new Next Js with version 15.0.3

Added a new image on the index page

Please check the image @samcx it was taken after the build was complete

I guess this is the default behavior of the next build to make an HTML document during SSG
As for the & is HTML entity of &

I hope this causes an issue when the Google Search Console accesses an HTML format URL

We are also facing this issue, I hope I can find a permanent solution

[samcx]

I wonder if it's because we're not URI-encoding the & here →

next.js/packages/next/src/shared/lib/image-loader.ts

Line 77 in ac0d72d

return `${config.path}?url=${encodeURIComponent(src)}&w=${width}&q=${

, resulting in the difference between what the browser does + path where image exists

[samcx]

@HelaGone @Vignesh-M21 Update on the investigation—

Essentially React is encoding the HTML (turning & into &) after the image-loader.ts runs, and then the DOM updates it to &. Just testing this, and doing the reverse (with .outerHTML) returns what is present in the source code.

• https://developer.mozilla.org/en-US/docs/Web/API/Element/outerHTML

Here is a production with wrong encoding

The same image with proper encoding:

Just noticed there are the same links.

I think this is working as expected—it's unclear about Google Search Console (we need more context on the screenshot in the description). I would expect if this is working in Chrome, the Google Search Console should be fine as well.

[Vignesh-M21]

I missed your message @samcx

Yeah, I guess so.

I look at the most recent two-month data on 404 Image URLs on our website.

I confirm it does not happen on all the images. It thought randomly on most of the pages

Would it be possible to relate to load time if it is high?

[ica-nis]

@samcx As I wrote in a previous post, both Firefox and Chrome seems to be handling this by doing some HTML decoding on the preload url. Safari on the other hand seems not to be able to handle it, sending the raw '&' instead of '&', resulting in a 400 response from Next.

[HelaGone]

Hi @samcx The bad encoding in Chrome is resulting in a lot of 404 errors in Google Search Console. We're not using the priority attribute anymore because of this. I'm confused about how Chrome is handling the encoding as expected but It's throwing an error: "w" parameter (width) is required that confuses me. The issue here is that that encoding of the & > & is not properly decoded neither in chrome nor GSC, causing the increase in 404 errors on the GSC report on those image urls with the bad encoding. Let me know if you need more evidence of the issue.

[Mohamed-Asar]

Hi @samcx any update on this issue ?

Edit by maintainer bot: Comment was automatically minimized because it was considered unhelpful. (If you think this was by mistake, let us know). Please only comment if it adds context to the issue. If you want to express that you have the same problem, use the upvote 👍 on the issue description or subscribe to the issue for updates. Thanks!