Support Forums

Cloud Front or HTML Post-Proc Bug on Image?

At this page:

This LFS image…


is somehow transformed into this broken URL in the deployed html…


Deploy logs include this line, the only reference to this image:

11:57:20 AM: │ /img/2021/08/1mm-dip-phosphine.jpg

The image is visible here:


So the problem seems to be specifically in the HTML post-processing code at netlify, or perhaps in some cloudfront deployment code.

Redeploying and rebuilding does not fix the problem.

Deleting the image, rebuilding/deploying, adding the image back, and rebuilding/deploying does not fix the problem either.

I am using hugo. The problem does not arise in a local build. Nothing in the git repo even references cloudfront.net. I have not found any other images with this problem (but I can’t be sure!), so there might be something idiosyncratic happening here. Perhaps with the file name? Or random failure?

Any help is appreciated.

Help me on this @perry? It is a blocker for us now.

Hi @swamidass,

If you’re using LFS images, do you really need Image optimisation? The image transformations handle that on the fly.

1 Like

The problem is with both webp and jpg. Netlify is not doing any image optimization at all. The problem is still that the HTMLLfile points to the wrong URL for no good reason. I could try changing the name of the image, but if that fixes it, it’s surely a bug on your end, right?

Hi @swamidass,

My question was entirely different. I’m asking, why do you need image optimisation from Post Processing when you can easily use LFS image transformations. Then, if you don’t wish to use LFS transformations and rely on Post processing, it’s better to remove LFS.

What I mean is, there’s no real benefit I can see by using both services at the same time.

I don’t have post processing active, and don’t want it to be active. LFS is the way I want to go. I am not using both services at the same time.

Hi @swamidass,

Could you try clicking on disable asset optimisation?

Once that’s done, try deploying again and recheck.

Already tried that. I’ll check again, and if needed rebuild and let you know if anything changes.

That check box was not checked. Just to be sure, I triggered another build with “clear cache”.

Problem is still there. If it makes any difference to debugging, the wrong URL address seems to be the same as before, so perhaps it’s a bad record or a hash of the content:


For reference, when I build locally, I get this URL instead:


The header image for the article is:


So one possibility is that relative links are being handled differently by netlify and replaced into something non functional? (why???)

That is the issue. Changed the image url in my build to an absolute URL, and now there is no error.

@hrishikesh I have a hard time seeing how this could be intended behavior. This is a bug, right?

1 Like

Relative links are handled by post processing while absolute ones are ignored, I don’t see why it would still resolve into the same address once you’ve disabled post processing.

Well, that appears to be the current behavior. At least I know the workaround.

1 Like