A working open graph generator example shows the four required og: properties — og:title, og:type, og:image, and og:url — emitted in stable order as escaped property-based meta elements inside the HTML head. The Open Graph protocol defines those four as the minimum data a sharing service needs to recognize a page as a shareable graph object, and any generator that ships fewer than four is producing incomplete metadata. A complete example also includes three optional properties — og:description, og:site_name, and og:locale — that enrich the preview when they are present, and it applies exact HTML escaping so that ampersands, quotes, and angle brackets inside the values cannot break the meta element. The output is a copy-paste block of meta tags that you place in the canonical page's head; it is not a script, not a JSON-LD payload, and not a visible body element. The example below is what an open graph generator example should produce when the four required inputs are valid: an absolute page URL, an absolute image URL, a non-empty title, and a recognized object type from a deliberately short list.
Anatomy of a Valid Open Graph Block
When you run a focused Open Graph generator, the result is a small, ordered sequence of meta tags written with the property attribute rather than the more familiar name attribute. The Open Graph protocol is documented at ogp.me and explicitly requires property-based syntax; using name="og:title" instead of property="og:title" is the single most common reason a "working" block silently fails at a sharing service. The block must also be placed inside the document head, not rendered as visible text or duplicated by both a theme and a plugin.
For an og:type of website or article, the four required properties are sufficient. Once you switch to richer types such as music.song, video.movie, or profile, the protocol expects additional structured properties (for example music:duration or profile:first_name) that a generic generator cannot supply from a short form, which is why those types are deliberately omitted. You can run this kind of minimal, valid example through the Open Graph Generator and paste the result straight into your canonical page.
A correctly formed sample block looks like this when you preview it as raw HTML:
| Property | Example value | Where it appears |
|---|---|---|
| og:title | How to Validate Open Graph Tags | Headline in the share preview |
| og:type | article | Classifier for the object |
| og:image | https://example.com/static/og.png | Representative visual crawled by the service |
| og:url | https://example.com/guides/open-graph-validation/ | Permanent identifier for the object |
| og:description | A short summary of the guide. | Supporting text under the title |
| og:site_name | Example Docs | Names the larger site |
| og:locale | en_US | Language and territory in the conservative two-letter form |
Required vs Optional Properties
Splitting the seven supported properties into required and optional columns makes the contract of any open graph generator example explicit. Missing any required value blocks the output entirely rather than producing a partial preview block, while optional fields are simply omitted when left blank.
| Category | Properties | Behavior when blank |
|---|---|---|
| Required (always emitted first) | og:title, og:type, og:image, og:url | Output is blocked until each value passes validation |
| Optional (emitted only when present) | og:description, og:site_name, og:locale | Tag is omitted from the generated block |
| Excluded by design | Twitter Card tags, JSON-LD blocks, music/video/profile extensions | Generated by separate, specialized tools |
This split is the reason a small browser-side generator can stay auditable: the four required fields are runtime-checked even though the form uses a select control, and every optional field has a conservative shape (bounded length, trimmed, control-character-rejected) that prevents the form from silently emitting malformed HTML.
Generate Open Graph Tags in Three Steps
- Enter the object text, choose a type, and supply two absolute URLs. Provide a non-empty title that names the object, pick website or article from the type selector, and paste an absolute HTTP or HTTPS page URL plus an absolute image URL. Both URLs must be fragment-free and must not contain embedded credentials such as user:pass@.
- Generate the block and copy the protocol-only output. Add optional fields only when you have a real value to supply — a short description, a real site name, and a conservative locale such as en_US. Copy the resulting meta block without re-encoding it as a script or wrapping it in another template.
- Paste the block into the canonical page head. Place the tags inside the head of the canonical URL the block describes. Inspect the delivered source to confirm the build pipeline did not reorder, overwrite, or duplicate the properties, then use each target platform's current preview debugger to check crawl access, image handling, and cache refresh.
The browser does the escaping, validation, and ordering work; the page does the placement. Anything between those two steps — reformatting the block, swapping property for name, or splitting the tags across the head and a plugin — is where most "I copied the example but it still doesn't show" reports originate.
URL Rules That Decide Whether the Block Works
Two of the four required properties are URLs, and the URL rules are stricter than what most form inputs accept. A valid open graph generator example only produces output when the page and image addresses clear all of the following checks at once:
- Absolute HTTP or HTTPS only. Relative paths, file://, data:, and javascript: URLs are rejected before the block is generated. Half of the gray preview tiles people see on social platforms come from relative image paths that the sharing service cannot resolve.
- No fragments. A trailing #section on the canonical page URL keeps shares of the same resource from splitting across client-side anchors; the parser strips the fragment during normalization.
- No embedded credentials. Any user:password@ segment in either URL is rejected so that user information cannot leak into public metadata.
- Publicly reachable for the crawler. The generator does not fetch either URL. Authentication, robots controls, redirects, MIME type, byte size, aspect ratio, and HTTP status are all verified separately at deployment time. A companion guide on producing a renderable image URL walks through what that verification step actually looks like in practice.
These rules are deliberately narrower than the URL grammar the browser accepts elsewhere. The point is not to be restrictive for its own sake — it is to prevent the generator from emitting blocks that look valid but quietly misbehave the first time a sharing service crawls them.
Inspecting Delivered Source and Platform Debuggers
A valid open graph generator example proves that the block can be produced; it does not prove that the block reaches a sharing service intact. Three checkpoints close that gap:
- View raw source on the canonical URL. Confirm that the meta elements appear inside head, that property is used rather than name, and that nothing has been duplicated by a theme plus a plugin plus a CDN worker.
- Fetch the image URL directly. Check the HTTP status, content type, byte size, and dimensions. Sharing services publish their own image requirements and will fall back, crop, or reject the asset if those requirements are not met.
- Run each platform's current debugger or share inspector. Compare the title, description, image, and URL it displays against what you intended. Caches mean a successful block can still render an older preview until the service refreshes; allow for that delay rather than assuming the new metadata failed.
At every checkpoint, the metadata must match the visible content of the page. A misleading title or image can earn a single click but it undermines trust on the next share, and most platforms reserve the right to downgrade pages that consistently mislead their crawlers. When the page moves or changes identity, update the canonical block, the image asset, and the live platform preview together rather than chasing them one at a time.
Open Graph metadata is also separate from Twitter Card metadata. The same Open Graph properties can act as fallbacks on some platforms, but service-specific tags and validation rules remain a different contract. Keeping the protocols separate is what lets the copied block stay auditable and prevents an assumed cross-platform field from masquerading as a standard requirement. For more on the protocol itself, the canonical reference at ogp.me documents every property the standard exposes, and the WHATWG HTML meta-element specification explains the attribute grammar the tags rely on.
If you're weighing options, Avoid Mistakes When Generating llms.txt With an Example covers this in detail.