PingfloatVisit Website →
← Back to blog

7 Curl and Debugger Checks That Fix og:image Issues for Developers

October 9, 2026
7 Curl and Debugger Checks That Fix og:image Issues for Developers

If your og:image is not showing up when a link gets shared, the fastest first move is to check the tag exists and points to a reachable, absolute URL, then run a platform debugger. Most failures trace back to a missing or malformed og:image tag, an image the scraper cannot fetch, or a stale cache holding an old preview. When a debugger flags a fetch error, look at HTTP status, SSL, and redirects next.

TL;DR:

  • Verify the page has an absolute HTTPS og:image URL, then confirm it returns HTTP 200 with the correct Content-Type and is not blocked to crawlers.
  • Use 1200×630 or 1200×628 pixel images; most scrapers select the first og:image tag, so place your preferred image there and include its dimensions.
  • Run each platform’s debugger separately: X/Twitter reads Card tags, while LinkedIn caches aggressively and may reject HTTP image URLs on HTTPS pages.
  • If browser loading succeeds but a debugger reports a fetch error, inspect redirects, expired signed URLs, crawler access rules, compression, and the SSL certificate chain.
  • After changing an image, rename its file or add a query string to its URL, then force a fresh scrape with the relevant debugger.
Pingfloat
pingfloat.com
Check Your Site’s SSL Health
When an image fetch fails, Pingfloat’s SSL certificate checks and network diagnostics can help you investigate website health and connectivity.
Explore Pingfloat tools

Table of Contents

Seven high-impact checks to run right now

Before touching infrastructure, work through a short list that either fixes the problem outright or tells you exactly where to dig deeper.

  1. Confirm an absolute og:image URL exists in the page source, and if you have multiple og:image tags, know that most platforms grab the first one.
  2. Open that image URL directly in a browser or with curl to confirm it returns HTTP 200 and the right Content-Type header.
  3. Check that the image meets common size expectations; very small or oddly shaped images get rejected or ignored by scrapers.
  4. Review robots.txt and any X-Robots-Tag headers, since a rule that blocks crawlers can also block social scrapers from reaching the image.
  5. Look for redirect chains, expired signed URLs, or hotlink protection, all of which commonly return a 403 instead of the image.
  6. Force a re-scrape with a platform debugger rather than assuming the platform will pick up changes on its own.
  7. Inspect response headers for compression settings like Brotli or deflate, since a misconfigured encoding can corrupt the bytes a scraper receives.

Running through these seven in order takes a few minutes and usually narrows the problem to one of three buckets: the tag itself, image accessibility, or caching. From there, the fix is either a markup change, a server-side adjustment, or simply waiting out (or busting) a cache. The Wordpress community has documented plenty of cases where an SEO plugin silently overrides og:image, so if you run a CMS, check plugin settings before assuming the problem is custom code.

Which validators and scrapers to use and how to interpret their output

Platform debuggers and command-line tools answer different questions, and using both saves time.

  • Facebook Debugger: paste the URL and read the "Based on the raw tags" section, which shows exactly what Facebook's scraper saw; SSL or fetch errors appear here before anything else.
  • LinkedIn Post Inspector: validates tags similarly but caches more aggressively, so a fix may not appear until you explicitly re-inspect.
  • X/Twitter Card Validator: checks Twitter Card markup separately from Open Graph tags and will fall back to a generic in-page image if the card tags are missing or malformed.
  • Pingfloat's Meta Tag Checker: useful when a CMS plugin might be duplicating or overriding tags.

On the command line, curl -I <image-url> shows you the response headers without downloading the body, which is enough to confirm status code and Content-Type. curl --verbose <image-url> goes further, showing the TLS handshake, which matters if a debugger reports a certificate error. wget <image-url> is a quick alternative when you want to actually save the file and inspect it locally.

Error messages map fairly predictably to root causes. An SSL chain error usually means a certificate problem on your server. A 403 means access restriction, often hotlink protection or a signed URL that expired. A 404 means the path is wrong. "Image too small" or a rejected download usually points to dimensions or file size. Community debugging on Stack Overflow shows Facebook's debugger reporting that an og:image "was not defined, could not be downloaded or was not big enough," along with raw cURL and SSL errors when the scraper simply cannot reach the file.

Pro Tip: Run curl before you run a platform debugger. If curl can't fetch the image, no social platform will either, and you'll save a debugger cycle.

Platform-specific quirks that commonly break previews

Each platform's scraper behaves a little differently, and knowing the quirks saves guesswork.

  • Facebook enforces stricter size and format expectations than most platforms and reports download failures with the same cURL and SSL-style messages you'd see from a raw HTTP request, which makes its debugger genuinely useful for diagnosing server-side problems.
  • X/Twitter reads its own Card markup in addition to Open Graph tags; when Card tags are missing or broken, Twitter sometimes falls back to whatever image it finds elsewhere on the page, which can look like a partial success but isn't using your intended og:image.
  • LinkedIn caches previews for longer stretches and pays attention to og:image:secure_url when present, so a page serving mixed content or an HTTP-only image URL can quietly fail there even when Facebook renders it fine.
  • When a page includes multiple og:image tags, most scrapers use the first one in document order, so if you're testing variants, put the preferred image first and set accompanying og:image:width and og:image:height to help the platform choose correctly.

These differences explain why a preview can look perfect on one platform and broken on another with no code changes in between. Testing each platform's debugger separately, rather than assuming one validator speaks for all of them, is the only reliable way to catch this.

Concrete image size, format, and metadata rules

Getting the markup right the first time avoids most of the troubleshooting above.

  • Use 1200×630 or 1200×628 pixels as the safest default size for cross-platform display; smaller images risk being rejected or cropped awkwardly.
  • Prefer JPEG or high-quality WebP for photographic images, and PNG for logos or illustrations with sharp edges and flat colors.
  • Set the correct Content-Type header on the image response so scrapers don't have to guess the file format from the extension alone.
  • Always use an absolute URL, matching the page's protocol (https when the page is https); data URIs and relative paths are not reliably supported.
  • Where possible, include og:image:width, og:image:height, og:image:type, and og:image:alt alongside og:image, since the Open Graph protocol defines these structured properties specifically to help scrapers render images correctly without re-fetching to measure them (see the differences between aria label vs labelledby for accessibility parallels).
  • If you're replacing an image at the same URL, rename the file or add a cache-busting query string, since platforms cache aggressively and may keep showing the old version otherwise.

In developer debugging reports on Stack Overflow, an image sized at 470×246 failed validation while the same content resized to 1200×628 was accepted. That gap illustrates why "technically present" isn't the same as "reliably accepted": platforms apply minimums in practice that are stricter than what their documentation implies.

Deeper infra problems: CDN, signed URLs, redirects, compression, and SSL

When the tag is correct and the image loads fine in a browser but still fails in a debugger, the cause usually sits one layer deeper, in infrastructure rather than markup.

  • Signed or expiring URLs used for image hosting will return a 403 once the signature expires, so check the URL's lifetime against how often a page actually gets shared or re-scraped.
  • CDN or origin protection rules sometimes block requests that don't look like a normal browser, which can catch social scrapers in the same net as bots you intended to block; check origin access rules and Host header handling.
  • Redirect chains (HTTP to HTTPS to CDN to origin) can confuse some scrapers that don't follow more than one or two hops; a single-step redirect is safer than a chain.
  • Content-Encoding problems, particularly a misconfigured Brotli setup, can deliver corrupted image bytes to a scraper even though the same file loads fine in a browser that handles the encoding differently; test the response both with and without compression to isolate this.
  • SSL certificate chain errors, including a missing intermediate certificate or an incomplete SAN list, cause TLS failures that a browser might tolerate but a strict scraper won't; running a full chain check catches this before a debugger does.

These problems are the ones community discussions on Stack Overflow point to most often when everything in the markup looks correct and the image still won't fetch: CDN access rules, encoding mismatches, and certificate issues that only show up under the stricter conditions a scraper imposes. Pingfloat's SSL Checker is a quick way to confirm whether your certificate chain is complete and whether the hostname matches what's on the certificate, without waiting on a social platform's debugger to tell you indirectly.

Pro Tip: If a debugger reports an SSL error but your browser loads the image fine, check for a missing intermediate certificate. Browsers sometimes tolerate incomplete chains that strict scrapers reject outright.

Exact verification steps and re-scrape sequence

Once you've made a fix, verify it methodically rather than just refreshing a debugger and hoping.

  1. Run curl -I <page-url> to confirm the page itself returns 200 and check for unexpected redirects before looking at the image.
  2. Run curl -I <image-url> and curl -v <image-url> to confirm status, Content-Type, and inspect the TLS handshake if SSL is in question.
  3. Use curl --compressed <image-url> to test how the server behaves with compression negotiated, which can expose encoding problems that plain curl misses.
  4. Paste the page URL into the relevant platform debugger and confirm the raw tags shown match what you expect, not a cached version.
  5. If the platform still shows an old image, rename the image file or add a cache-busting query string rather than waiting for the cache to expire on its own.
  6. Set up a simple HTTP check, such as Pingfloat's Website Uptime Monitor, to confirm the image URL keeps returning 200 over time rather than failing intermittently.

A successful re-scrape shows your current image and current title and description in the debugger's preview pane, not a cached mismatch. If a debugger still shows the old image after a forced re-scrape, that's a caching issue rather than a markup issue, and renaming the file is faster than troubleshooting the cache further.

Pingfloat tools and author-backed checks to run now

Each common failure mode has a fast, free check that narrows down the cause before you touch server configuration.

  • Run the Open Graph Checker first to confirm og:image and the rest of your Open Graph tags are present, well-formed, and pointing to an absolute URL.
  • Use the SSL Checker when a platform debugger reports a certificate or TLS error, since it will show whether your chain is complete and whether the hostname matches.
  • Set up the Website Uptime Monitor on your image URL if the problem is intermittent, since a one-time fetch check won't catch a host that fails occasionally.
  • For implementation examples and sample markup, our walkthrough on implementing Open Graph tags covers the structured properties worth adding beyond the basic og:image tag.

These checks cover the three buckets that cause most failures: malformed tags, broken TLS, and unreliable hosting. Running them in that order before opening a platform debugger usually tells you which bucket you're in within a couple of minutes.

Author's triage order and time-saving heuristics

Author's triage order and time-saving heuristics — overview diagram

The order that saves the most time is tags, then debugger, then accessibility, then infrastructure, then cache-busting. Check the markup first because it's free and instant. Run a debugger next because its raw error maps directly to an HTTP or TLS problem you can reproduce with curl. Only after that should you loop in an infrastructure or CDN team, and when you do, bring them the exact response headers, status codes, and any SSL chain errors you've already collected, since vague reports of "the image isn't showing" waste everyone's time.

A couple of heuristics worth remembering: renaming the image file forces an immediate refresh on platforms that would otherwise serve a stale cached version for days. And don't rely on a platform debugger alone to diagnose certificate problems. Debuggers report the symptom, but a direct chain check tells you the actual cause.

— Andreas

Pingfloat: a practical toolkit for diagnosing og:image problems

We built our tools around the exact failure points covered above, so you don't have to juggle five different services to run one diagnosis. Instead of guessing which layer broke, you can check tags, TLS, and availability from one place, each in under a minute.

Pingfloat

FAQ

Twitter reads its own Card markup separately from Open Graph tags, so a missing or malformed Twitter Card tag can cause it to fall back to a different image or none at all. Check both your og:image and your Twitter Card tags with the X/Twitter Card Validator to see which set the platform actually parsed.

Why are images not loading?

Images commonly fail to load due to a wrong or relative URL, a server returning an error status instead of 200, a blocked path in robots.txt, or an expired signed URL. Running curl -I against the image URL quickly shows the status code and Content-Type, which usually points to the cause.

How to check Open Graph image?

The quickest way is to view the page source for an og:image tag with an absolute URL, then confirm that URL loads directly in a browser with a 200 status. Tools like the Open Graph Checker or a platform debugger will also show exactly what tags and image a scraper detected.

Facebook's scraper reports when an og:image "was not defined, could not be downloaded, or was not big enough," and these errors typically trace back to SSL problems, access restrictions, or an image below the platform's practical size threshold, according to developer debugging reports. Running the URL through Facebook's Debugger shows the exact raw tags and fetch error so you know which one applies.

How do I force a social platform to update a stale preview image?

Most platforms cache og:image aggressively, so the fastest fix is renaming the image file or adding a cache-busting query string so the scraper treats it as a new resource. Follow that by running the relevant platform debugger to force an immediate re-scrape rather than waiting for the cache to expire naturally.

Sources

These are the protocol documentation, debugging tools, and community threads referenced throughout this guide.