SSR: Hydration attribute mismatch in HTML on <img> with dynamic alt attribute

[mrleblanc101]

Vue version

3.5.27

Link to minimal reproduction

https://stackblitz.com/~/github.com/mrleblanc101/repro-nuxt-i18n-node-mismatch?file=app/pages/index.vue

Steps to reproduce

If I add :alt="t('Ville de Québec l’accent d’Amérique')" this to my <img src="...">, then I get a Hydration attribute mismatch if i run pnpm build && pnpm preview.

<img
    class="quebec-city-logo"
    src="@/assets/img/ville-quebec.svg"
    :alt="t('Ville de Québec l’accent d’Amérique')"
    width="276"
    height="81"
/>

Hydration attribute mismatch on <img class="quebec-city-logo" src="/_nuxt/ville-quebec.Ctek8D92.svg" alt="Partenaires" width="276" height="81">

Everything is fine if I run pnpm run dev.

Notice that, on the server-side, the domain is not in the url, but on the client it is.
I think this is what is causing the mismatch.

These alt don't seem to cause problem:

<img
    class="quebec-city-logo"
    src="@/assets/img/ville-quebec.svg"
    :alt="'Ville de Québec l’accent d’Amérique'"
    width="276"
    height="81"
/>
<img
    class="quebec-city-logo"
    src="@/assets/img/ville-quebec.svg"
    alt="Ville de Québec l’accent d’Amérique"
    width="276"
    height="81"
/>

What is expected?

No hydration mismatch

What is actually happening?

Hydration mismatch

System Info

System:
    OS: macOS 26.2
    CPU: (8) arm64 Apple M1 Pro
    Memory: 169.63 MB / 32.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 24.4.1 - /Users/sleblanc/.nvm/versions/node/v24.4.1/bin/node
    npm: 11.4.2 - /Users/sleblanc/.nvm/versions/node/v24.4.1/bin/npm
    pnpm: 10.14.0 - /Users/sleblanc/.nvm/versions/node/v24.4.1/bin/pnpm
  Browsers:
    Chrome: 144.0.7559.97
    Chrome Canary: 146.0.7654.0
    Edge: 144.0.3719.92
    Firefox: 146.0
    Safari: 26.2
  npmPackages:
    vue: ^3.5.27 => 3.5.27

Any additional comments?

Relates to nuxt/nuxt#34207
Relates to nuxt-modules/i18n#3881

[mrleblanc101]

More context, Daniel Roe says it's most probably not a Nuxt bug:
https://discord.com/channels/473401852243869706/473406506579263488/1466097751958749420

I'll try to create a repro with Vue SSR instead of Nuxt SSR, but I've never done SSR without Nuxt.

[mrleblanc101]

I've updated the link from a Github repo to a StackBlitz

[mrleblanc101]

From the vue-3 discord, https://discord.com/channels/325477692906536972/568340117052456970/1466118350437355621

[edison1105]

skirtle's analysis is correct. When a vnode contains dynamic attributes, it checks for props mismatch during hydration because purely static nodes are unlikely to cause mismatches, so they are not checked.

Does not work with SSR
This pattern does not work if you are using Vite for Server-Side Rendering, because import.meta.url has different semantics in browsers vs. Node.js. The server bundle also cannot determine the client host URL ahead of time.

Vite's documentation clearly states that new URL(...) can cause SSR/CSR inconsistencies. You can refer to the resource handling options mentioned in this documentation to make changes, such as placing the SVG in the public folder.
You can also use https://vuejs.org/api/ssr.html#data-allow-mismatch to avoid warnings.

[mrleblanc101]

@edison1105 I did not put the new URL() there... Vue/Vite did !
Also it has anything to do with SVG ? It also happens with every other image types...

I've been importing image this way for as long as I can remember, so is most vue project...
How am I supposed to know ? There is not even a development warning, just a production warning if you enable the __VUE_PROD_HYDRATION_MISMATCH_DETAILS__ flag and build for production and care enough to double check.

I'm not sure placing the asset in the public folder is a real solution unless we prevent loading image this way...

[edison1105]

@mrleblanc101
I've made a PR for this one. Please feel free to review.

[mrleblanc101]

@edison1105 Thanks for reconsidering.
So, from my undertanding there were never really any hydration issue, just an invalid warning and your PR solves that ?
That seems fine to me !
Thanks