Hi @Razunter. What do you mean by file extension? I believe handler sends the right meme and we are not sending any other header about file name or extension.

Hm… I've meant generation urls always end in the original file extension, and it causes confusion: avif-wepb etc. still end up with urls looking like they are wrong extension. Like in the docs: http://localhost:3000/embed,f_webp,s_200x200/static/buffalo.png. It's webp, but it looks like png since url ends with png.

I can understand DX issues but we cannot change the last part as it has to directly map to the source id. Without the extension, we don't know what is an original file path. I'm closing this issue as cannot think of an easy possible solution but please ping to reopen if you have an idea without changing signature and dropping source extension.

Though it may not be a clever solution, how about appending the converted file extension so that we can keep both the mapping relation while still having the browser to pick up the right file extension.

Example:
Original file @/static/buffalo.png becomes /f_webp/static/buffalo.png.webp

I spent an hour trying to figure out why my images were always in .png format.
I saw @toto6038 's comment and understood. After checking with ffprobe, it was webp all along...

This is not just a DX issue. It makes ipx and nuxt/image unusable for static site deployments, where the middleware isn't in play. Because the generated files have the wrong file extension they also end up being served with the wrong MIME type.

Hi everyone,
While waiting for the option to customize URL parsing, is there a known workaround for static site deployments ?

This is not just a DX issue. It makes ipx and nuxt/image unusable for static site deployments, where the middleware isn't in play. Because the generated files have the wrong file extension they also end up being served with the wrong MIME type.

Same here, Lighthouse think I'm using jpeg images and is lowering my score