Open Graph checker that fetches the page and measures the image

01Check a page by URL or by pasting its HTML

Two ways in. Type an https URL and press Fetch, and the served HTML arrives through a small relay the author runs, exactly as a crawler would receive it, then runs through the same checker. Or paste HTML yourself, from view source rather than the rendered DOM, and nothing leaves your browser at all. The head alone is enough. In fetch mode the og:image is loaded and measured straight away. In paste mode the image stays untouched until you press the measure button in the preview card, because pasting must stay a fully offline act.

Parsing happens in your browser. The one thing a browser cannot do on its own is read another site's HTML, so the Fetch button calls a relay endpoint the author of this site runs on workers.dev. It requests the one URL you typed over https, follows at most five redirects, refuses anything but https, caps the body at one megabyte and reports its status, final URL, byte count and whether it truncated. Every relay error is shown to you word for word. Measuring an image means your browser requests that image file from wherever it is hosted, which is why paste mode asks before doing it.

Nothing you type is stored, and the paste box works with no fetch at all.

02Every rule the checker applies, and the line it comes from

No rule here is invented. Each row quotes the protocol or the vendor page it came from, and the image figures the measurement compares against are the ones those vendor pages publish, quoted with their source. Where a source publishes no limit, the checker applies none.

The four required properties

Optional properties the protocol documents

The image properties

Some properties can have extra metadata attached to them, and those structured properties are written the same way as any other, with the extra segment on the property name. Put them after the root tag they belong to, because when another root element is parsed the previous structured property is considered done and another one is started.

The image figures the measurement compares against

Once the image is loaded, its natural width and height are read from the image element and set beside these published figures. Each figure is quoted from the vendor page named in the row. File size is not in the table because a browser cannot read the byte size of a cross origin image without CORS headers on that image, so the checker states that plainly rather than guessing.

The type vocabulary

A page that is not marked up should be treated as og:type website, and Meta says the default is website when you do not specify a type. The documented values are below. Types outside the global list are CURIEs that carry a colon, and namespaced global types are always prefixed with the namespace and then a period.

Who reads which property

03What the tags actually look like on major homepages

Reference tables tell you what the protocol allows. They do not tell you what large sites bother to ship. So the homepage of every host in a fixed list of large, well resourced sites was fetched once over HTTPS on 6 September 2026 with a desktop browser user agent, and of those, 58 returned served HTML and were measured for the counts below. Served HTML only, nothing rendered by script.

Of those 58 measured homepages, 51 carried at least one og property and 40 carried all four required ones. The gap between those two counts is the ordinary case, a page with a title and an image and no type or no url.

Sample of 58 measured homepages, instrument one HTTPS GET per host reading served HTML, captured 6 September 2026. The raw machine readable file is data/homepage-tag-census-2026-09-06.json, served from this origin, and every count above is read from it by code rather than typed. Two things worth taking from the table. The image alt count and the width and height count are far below the count for og:image itself, so the two properties the vendor documentation asks for are the two most often skipped by sites with real budgets. And the type field is close to a formality, since most hosts that set it set the value a crawler would assume anyway.

04Common questions

Why a preview shows the wrong image

Three causes cover most cases, and the checker above tests all three. First, Meta documents that images are cached based on the URL and will not be updated unless the URL changes, so replacing the file at the same address leaves the old card in place. Publish the new image at a new URL, and if the content was not available when the crawl happened, Meta says a crawl can be forced once it becomes available, either by passing the URL through the Sharing Debugger tool or by using the Sharing API. Second, if the page carries the same property twice with different values, the protocol says the first tag from top to bottom is given preference during conflicts, so a stale tag near the top of the head quietly wins over the correct one further down. Third, the file itself is too small or the wrong shape. Meta documents a minimum allowed dimension of 200 x 200 pixels and recommends at least 1200 x 630, and a file below the minimum can be dropped from the card altogether. Fetch the page above and the checker loads the image and tells you which of these it is.

Making og url match the canonical

The protocol describes og:url as the canonical URL of your object that will be used as its permanent ID in the graph. Meta describes the same property as the canonical URL for your page, and says it should be the undecorated URL, without session variables, user identifying parameters or counters. Two pages that share content and differ only by a tracking parameter therefore want the same og:url. The checker compares your og:url against the canonical link element in the same HTML and shows both strings when they differ, which is the mismatch that splits one page into two objects. In fetch mode it also shows you the final URL the relay ended at after redirects, since a redirect chain that lands somewhere other than og:url is a second way to split the object.

Choosing a type value

Use website unless the page is genuinely one of the documented objects. A page that is not marked up should be treated as og:type website, and Meta says the default is website when no type is specified, so setting website on an ordinary page changes very little. The protocol documents article, book and profile as global types alongside website, a music vertical covering music.song, music.album, music.playlist and music.radio_station, a video vertical covering video.movie, video.episode, video.tv_show and video.other, and payment.link as a beta type. Picking a vertical type matters because the protocol says other properties may also be required depending on the type specified.

The closing slash on a meta tag

Both forms are fine. The protocol writes its own examples with a trailing slash. The HTML Standard lists meta among the void elements, and says the trailing solidus on a void element does not mark the start tag as self closing but instead is unnecessary and has no effect of any kind. So a checker that reports a missing slash as an error is reporting nothing. What does matter is the attribute carrying the name. The protocol writes og properties with a property attribute and the value in a content attribute, the HTML Standard requires exactly one of name, http-equiv, charset and itemprop on a meta element, and property is defined by RDFa Core, which uses it for expressing relationships between a subject and either a resource object if given or some literal text. The checker flags any og property written with name so you can see it.

What leaves your browser

In paste mode, nothing. Your HTML is parsed in the page, the report is built from that parse, and no request is made with any part of it. The preview card does not load the image until you press the measure button, and pressing it makes your browser request that one image file from its host, the same request any visitor to your page makes when they see the card. In fetch mode, the URL you typed is sent to the relay, the relay fetches it and hands the HTML back, and the image is then requested by your browser. Nothing is stored either way, and the relay's answer, including any error, is printed on the page word for word.

06Where these rules and numbers come from

By Michael Lip, who fetched and published the census on this page and wrote the checker above.

Every count on this page is read by code from the census file published beside it and rendered into the page at build time, so no figure here was typed by hand or estimated. A value that could not be fetched is held as null and rendered as unknown rather than defaulted to something flattering. Every rule the checker applies, and every image figure it compares against, is quoted from one of the pages below.

• SPECThe Open Graph protocol, for the four required properties, the optional and structured properties, the type vocabulary, the locale format and the first tag wins rule.
• DOCSMeta sharing, Meta image sharing and Meta crawlers, for the undecorated url, the default type, the image cache behaviour, and the minimum, recommended, ratio and file size figures.
• DOCSLinkedIn help, for the tags that must exist for a link share and the sharing module image figures, and Slack docs, for classic unfurling.
• SPECThe HTML Standard, semantics and syntax, for what a meta element may carry and the trailing slash, and RDFa Core 1.1, for the property attribute.
• DATAThe census file, every figure in section 03, fetched 2026-09-06 and published unmodified.

Reading crawler traffic in raw server logs teaches you quickly that a request claiming to be Googlebot has to be checked against Google's published IP range files, because the user agent string is free to forge, and the same instinct applies to metadata. What a page claims in its head and what a reader of served HTML actually gets are two different things, so the counts here come from fetching the HTML rather than from asking anyone what they ship, and the checker fetches and measures for the same reason. The same instrument produced the robots.txt census behind the robots.txt checker on this site.