og:image could not be downloaded because it exceeded the maximum allowed sized of 8Mb

Question

Building a website that requires sharing links with an image. Done this I don\'t know how often...but this time the Facebook Open Graph Debugger says:

og:image {image ur

Answer 1

I realize this is an old question and has an accepted answer, but as of now, 2018, none of the solutions above worked for me by themselves. What finally worked is a combination of workarounds:

• add a HTTP version in the og:image tag and add a og:image:secure_url tag that points to a HTTPS version. In the debugger tool, you should now be getting a message that fetching the image is an asynchronous process and thus won't be available for first request
• add og:image:height, og:image:width and og:image:type meta tags with appropriate contents. The asynchronous message in the debugger should now disappear and you should be able to see the image on first fetch as well

My website is a HTTPS only (HTTP requests are redirected to HTTPS version), images are hosted on Amazon S3. I am using a Cloudfront CDN, but I had to serve the og:image directly from S3. Trying to serve it from the CDN seems to work fine as long as the image is already cached in the CDN. If the image is not cached in CDN and Cloudfront forwards the request to S3, FB debugger reports an error.

It seems like FB doesn't play well with redirects and HTTPS versions noted in the og:image meta.

Answer 2

I experienced this problem today.

Since the developer link to a bug in the other answer says that the problem was fixed, I thought I would provide information about the issue I experienced.

The fact is that my website is expected to be used on HTTPS (with SSL) and not HTTP. I give the tool an address with, clearly, HTTPS everywhere (all URLs on the page are HTTPS and the one I paste in the Sharing Debugger is also HTTPS). Yet, they ended up failing because in their test, somehow, they drop the "S" and hit the server without any encryption.

I thought that could help some other people. By enabling the non-encrypted website, Facebook started working since everything was in place (and it was for a while, but that error was driving me crazy!)

Answer 3

This is a bug, and it's confirmed, after getting the warning, if you retry the debug, or click on "Scrape Again", the error message will be gone. This is an issue because if someone tries to share the post, the image will not show up since it didn't get scrapped, but subsequent shares will display the image.

You may subscribe to the Bug report or add some extra comments.

https://developers.facebook.com/bugs/1626463061012181/

And yeah, this started happening around April 17th, I hope this solves our issue.

EDIT:

Facebook Team replied with a workaround:

It seems like the issue is with the misleading error message which we will be updating. In the meantime, since the crawler has to see an image at least once before it can be rendered, it means that the first person who shares a piece of content won't see a rendered image. This seems to be the actual issue here and the workaround is available here: https://developers.facebook.com/docs/sharing/best-practices#precaching I will post here once we update the error message.

Adding the og:image:width and og:image:height Open Graph tags seems to do the trick, I can swear I tried that before and didn't do much, but this time it seems to work just fine.

Answer 4

This continues to be an issue in May 2017. I tried:

• adding og:image:width and og:image:height
• manually resizing the img to 1200x630 (FB's recommended minimum)
• rounding the size to the nearest hundredth (a sol'n I saw elsewhere)
• confirming that the filesize was indeed well below the 8MB (it's 322 KB)
• renamed the file to exclude non-alpha characters
• converting img to jpg.

The only "solution" in my case was to run the FB Sharing Debugger on the non-https:// version of the webpage (i.e. simply http://). Then the "og:image could not be downloaded because it exceeded the maximum allowed sized of 8Mb" error msg disappeared. FWIW, FB did show the 301 redirects from the http: to the https:.

(I would have posted this as a comment but do not have enough cred yet.)