Social Preview Checker vs. checking your tags by eye
Opening view-source or DevTools' Elements panel and reading the og: and twitter: meta tags is the method most developers reach for first, and it is a real, free way to catch the most obvious failure: a tag that is missing outright. This page names no company or product -- reading a page's own markup is a generic habit every web developer already has, not a tool being compared against.
That habit works well for exactly the case it is suited to: is the tag there at all. It runs into trouble the moment the question becomes anything more specific than presence -- is the image actually big enough, is the URL actually absolute, and is there exactly one of each tag rather than two fighting for the same platform's attention? None of those three are visible from reading the tag's text.
| Question | Reading the tags by eye | This checker |
|---|---|---|
| Is an og:image (or twitter:image) tag present at all? | Catches it -- a missing tag is visible in the markup. | Catches it too. |
| Is the image behind that tag actually large enough for Facebook's or Twitter's documented minimum? | Not visible from the tag's text -- the URL string says nothing about the file's real pixel dimensions. | Fetches the image and reads its real width/height from the file's own header. |
| Is the og:image URL absolute, as the Open Graph protocol requires, rather than relative? | Easy to miss -- a relative URL opens fine in your own browser tab, because your browser resolves it against the page you're on. | Flags a relative URL explicitly, before any platform's crawler has a chance to fail resolving it with no page context. |
| Did a CMS plugin write a second og:title (or similar) alongside your theme's own tag? | Both tags look equally valid sitting in the markup; which one a parser keeps isn't visible from reading either one. | Reports duplicated tags for the same property as a distinct finding. |
| Is a missing twitter:image actually a problem, given the documented og:* fallback chain? | Reads as broken at a glance, which invites "fixing" it with a second image tag to keep in sync by hand. | Applies the fallback chain first, and only flags the case where the fallback itself has nothing to fall back to. |
| Run the same check the same way every time, right before a page ships? | Manual, and only as thorough as whoever is looking that day. | A CLI with a real exit code, or the browser report viewer on this page. |
A quick look at the markup is still worth doing -- it is free, it needs no tool, and it genuinely catches the tag-is-missing case in seconds. What it cannot do is answer the three questions above that decide whether a preview actually renders, which is the gap this checker exists to close.
Common questions
What does reading the tags by eye actually catch?
Opening a page's view-source or DevTools' Elements panel and scanning for og:title, og:description, og:image, and the twitter: equivalents is a real, fast way to catch the most obvious failure: a tag that is simply missing. If og:image isn't in the markup at all, you'll see that in seconds with no tool.
Where does eyeballing the tags fall short?
Three ways this checker catches and a by-eye read of the markup cannot, even by a careful reader: (1) the og:image tag can be present and point at a real image that is simply too small -- Facebook documents a 200x200 minimum and Twitter's summary_large_image card documents 300x157, and nothing about reading the URL string tells you the image's actual pixel dimensions; that needs opening the file itself and reading its header, which is what this tool's CLI and standalone image checker do. (2) A relative og:image URL ("/images/share.png" instead of "https://example.com/images/share.png") renders fine if you click it in your own browser, because your browser resolves it against the page you're already on -- but the Open Graph protocol requires an absolute URL, and a platform's crawler fetching the tag value directly, with no page context to resolve it against, can fail silently. (3) A CMS plugin that writes its own og:title alongside a theme or hand-written one produces two tags with the same property name in the markup; which one a given platform's parser keeps is not something reading the HTML tells you, since both are sitting right there looking equally valid.
Why does the fallback chain matter here?
Platforms document a fallback: Twitter Cards fall back to the equivalent og:* tag when twitter:image, twitter:title, or twitter:description is absent, so a page missing twitter:image is not automatically broken on Twitter/X if og:image is set. Reading the markup by eye, a missing twitter:image tag looks like a problem -- and it's easy to "fix" by adding a duplicate image tag that then has to be kept in sync by hand. This tool applies the documented fallback chain before reporting anything as missing, so it only flags the case where the fallback itself has nothing to fall back to.
Open the Social Preview Checker to check your own page, or read the fallback chain and size-rule reference.