Now that I updated many of my sites to be HTTPS only, redirecting HTTP requests as needed, I did notice that sharing on Facebook produced a blank image. Refreshing the Share Attachment does not change anything, so I looked into t he FB documentation. It says to specify the og:image:secure_url tag if your site requires an HTTPS connection, so I replaced the simple og:image tag with the secure one and the Facebook OpenGraph Debugger says that og:image is missing but the site no longer has any insecure images.

Must I really set both? And can they both point to exactly the same HTTPS URL?

  • Presumably you mean og:image:secure_url?
    – DocRoot
    Commented Nov 30, 2017 at 0:36
  • @DocRoot - Good catch. Fixed and make sure that was what I actually had on the site.
    – Itai
    Commented Nov 30, 2017 at 0:40

2 Answers 2


As I understand it, if your site is 100% SSL (and everything redirects to HTTPS, so there is essentially no plain HTTP) then you only need the og:image tag in which you specify the https://... URL. Although, must admit, this is not particularly clear from the OGP documentation (or Facebook Docs) - which seems to imply (by example) that the og:image URL is HTTP only - this does not appear to be the case.

The og:image:secure_url tag is used to specify an alternative HTTPS URL ("alternative" being the word used in the OGP documentation). This only appears to be required when the site supports both HTTP and HTTPS - when HTTPS is indeed an "alternative".

However, there is no harm in specifying both og:image and og:image:secure_url and pointing them both at the same https://... URL. WordPress appears to do this by default. However, as mentioned, if your site is only HTTPS then there does not appear to be a need to specify og:image:secure_url as well. Both methods validate OK in the Facebook Debugger. Both methods "work" in my testing. StackExchange (which is now 100% HTTPS) uses only the og:image tag (specifying an https:// URL) - which validates and "works" OK.

Refreshing the Share Attachment does not change anything

Not really sure what you are referring to with regards to "Share Attachment"? But problems like this are often the result of (Facebook) caching. Within the Facebook Debugger, check the "Time Scraped" and hit the "Scrape Again" button if required.

However, there have been numerous queries raised in the past regarding the failure to display the image when URLs are shared. Some "fixes" include:

  • Specify a different image URL.
  • Specifying og:image:width and og:image:height tags.
  • Having to wait 10 minutes for the FB cache. (!?)
  • Image never appearing when the URL is first shared. (Because of the FB cache.)

These all appear to relate to the FB cache, so refreshing the request via FB debugger may be the required fix.

Reference: (however, whilst this question is a few years old, I think some answers may still be relevant)

  • Going to try some of this today but even the docs you linked to say og:image:secure_url - An alternate url to use if the webpage requires HTTPS.. Note the word requires which I think is the case for an HTTPS site, or am I misinterpreting something? And, yes, the first share used to not work but doing refresh attachment always fixed it back when the site served both HTTP and HTTPS.
    – Itai
    Commented Nov 30, 2017 at 14:06
  • @Itai To be honest, the more I think about this the less it seems to make sense. If the og:image tag supports both HTTP and HTTPS URLs (as it appears to) then there doesn't seem to be a need for a og:image:secure_url tag? The og:image tag appears to be mandatory (one of "the four reqd properties for every page" - according to the OGP). "if the webpage requires HTTPS" then only specify HTTPS URLs in the og:image tag? Incidentally, YouTube, WordPress.com and Amazon all just use the og:image tag with HTTPS. No sign of og:image:secure_url.
    – DocRoot
    Commented Dec 1, 2017 at 1:20

Mixed content does not apply within those tags therefore the SSL will still work correctly regardless if they are HTTPS or HTTP, however the whole point of SSL is for security and privacy for your users... so, why not gone the whole distance?

  • 2
    Sorry but I don't understand your last sentence/question. What do you mean? This (and most others of my sites) are now completely secure, even most ads are delivered over HTTPS.
    – Itai
    Commented Nov 30, 2017 at 0:41
  • If your site is SSL... why OG non-ssl. Commented Nov 30, 2017 at 11:10
  • That's the question. I removed the non-ssl version but FB debugger says it's missing... so maybe the tool is not up to date which is why I am asking.
    – Itai
    Commented Nov 30, 2017 at 14:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.