Open Graph tags render share previews through page HTML, which means most websites do not need a Facebook Graph API access token to control how a link looks when shared. The Open Graph Protocol defines four basic required properties — og:title, og:type, og:image, and og:url — and three widely accepted optional properties (og:description, og:site_name, og:locale) that you can paste into the canonical page's head. A token belongs to API-level work: publishing posts through the Graph API, reading the social graph, or running marketing automation. A static page that simply wants a consistent appearance when someone pastes its URL into a chat window, an email, or a status composer has no need for that token or the surrounding credentials, permission grants, and token rotation. Generating Open Graph metadata with a browser-side tool like the Open Graph Generator produces a clean, escaped property block you can drop straight into your HTML head and forget about.
The Shortcut: Skip the Token, Ship the Tags
Facebook's Graph API documentation makes sense for products that actively post, read, or react on behalf of users through Meta's servers. It does not make sense for a typical blog post, product page, or static landing page. The metadata Facebook (and most other graph-aware platforms) use to render a preview is shipped with the page itself, inside the HTML response, not fetched live through an authenticated API call when a share happens.
That distinction is the entire reason the Open Graph Protocol exists. Instead of forcing every page owner to register a developer account, pass permission review, generate a long-lived user or page token, and handle token refresh, the social platform reads og:* properties straight from your HTML the next time its crawler reaches the page. When the only goal is "make this URL look right when shared," the path is metadata. When the goal is "programmatically publish to a page or pull profile data," the path is the Graph API and the access token that comes with it.
Why a Token Is Usually Unnecessary for Previews
Three differences separate the metadata path from the API path:
- Direction. Open Graph flows from your page outward — the platform reads your HTML. The Graph API flows from your server outward — your code calls Meta's endpoints with a token attached.
- Authentication. Open Graph travels over plain HTTPS like any other web fetch, with no credentials. The Graph API requires a user, page, or system user access token tied to a registered app.
- Onboarding. Open Graph needs only a public URL and a public image. The Graph API needs app registration, business verification for some surfaces, and ongoing token rotation.
If none of your code needs to act on Facebook — only to be acted upon when someone shares a link — the token is overhead. The Open Graph Generator creates the metadata that turns a page into a graph object exactly as the protocol defines, with no API call in sight.
The Four Required Open Graph Properties
The Open Graph Protocol specification lists four basic required properties for any graph object. Every compliant preview block must include all four; missing any one prevents the share system from rendering a meaningful card.
| Property | Purpose | Value rules in the generator |
|---|---|---|
| og:title | Names the shared object | Plain text, trimmed and length bounded, HTML-escaped for the attribute |
| og:type | Classifies the object | Only website or article from the form; re-checked at runtime against altered input |
| og:image | Supplies a representative visual | Absolute HTTP(S) URL with no credentials, no fragments, pointing to a publicly reachable image |
| og:url | Identifies the canonical object | Absolute HTTP(S) URL with no credentials and no fragments; fragment-free so anchors do not split the object |
Two of those rules bear repeating. The page URL must be fragment-free so that client-side anchors do not split one logical resource into multiple graph objects. The image URL must point to a publicly reachable file that the sharing service's crawler can fetch — the generator validates URL shape but does not fetch the image, so HTTP status, MIME type, dimensions, byte size, redirects, robots controls, and authentication all remain your responsibility to verify with the platform's own tooling.
Optional Properties and the Locale Format
Three additional properties are widely supported and frequently used. They are checked, escaped, and serialized after the required block:
- og:description — A short summary of the shared object. Trimmed, length bounded, and rejected when it contains control characters.
- og:site_name — The name of the larger site the object belongs to (the publication, not the individual article).
- og:locale — The resource's primary language and territory in language_TERRITORY form, such as en_US. The validator accepts only a conservative two-letter language and two-letter territory shape; alternate locales and script subtags are deliberately out of scope for this focused form.
For every value, attribute escaping keeps ampersands, quotes, and angle brackets from breaking the generated meta element. The four required properties always come first in the output, in stable order, because a debugger or share scraper that reads them in a predictable sequence has fewer surprises to swallow.
Build a Valid Block From Clean Inputs
The workflow using the Open Graph Generator is intentionally short. Each step protects a different failure mode.
- Enter accurate object text and pick the type. The title is the headline a person reads in the preview card. Choose website for a homepage, generic landing page, or section root; choose article for a dated or editorial piece. The interface is a select control, but the type is re-validated at runtime, so programmatic or altered input cannot slip an unsupported type past the form.
- Provide the canonical page URL and a public image URL. Both must be absolute HTTP or HTTPS addresses with no embedded credentials (no user:pass@) and no fragments (no trailing #section). The browser's URL parser normalizes each value, and a fragment-free object URL keeps one logical resource from splitting into multiple graph objects when client-side anchors are added.
- Add the optional description, site name, and locale. Each of these is trimmed, length bounded, escaped for an HTML attribute, and rejected if it contains control characters. The locale must match the conservative language_TERRITORY shape (such as en_US) or it will not be accepted.
- Generate and copy the protocol-only block. The output is property-based meta elements in stable order, with the four required properties emitted first and the optional ones after them. There is no padding, framework hook, or platform-specific guesswork in the result.
- Paste the block into the canonical page head. Place the meta elements inside the HTML head of the canonical page, not as visible text on the page. Do not double-encode the whole block, and do not duplicate the same metadata through both a framework template and a separate plugin.
- Inspect delivered source and verify with each target platform's debugger. Build tools can reorder, overwrite, or add conflicting properties. View the page source after deployment, then use each sharing service's current preview debugger to confirm crawl access, image handling, and cache refresh.
Output Behavior You Can Rely On
Because the generator performs all work in the browser, no URL or text value is ever sent elsewhere to produce the block. The same escaping code that protects your title also protects the description, the site name, and the locale. Missing any required value blocks output rather than producing an incomplete preview block — useful when you want to know nothing slipped through. Object types outside website and article, including music, video, and profile variants that carry their own required structured properties, are deliberately unsupported; a specialized implementation is the right next step rather than free-text type fields that silently produce invalid combinations.
The output uses property syntax (<meta property="og:title" …>), not the older name syntax, which is what the current protocol specification expects and what share debuggers consume. The generator does not produce Twitter Card metadata; some platforms can use OG fields as fallbacks, but Twitter's own tags, validator, and rules remain a separate concern. Keeping the protocols separate makes the copied result auditable and prevents an OG field from masquerading as a Twitter requirement.
Why a Clean Block Does Not Guarantee the Preview
A valid Open Graph block is necessary but not sufficient. Sharing systems can crop images, truncate text, ignore fields, choose cached data, or apply account-level presentation rules. The image URL you supplied may technically exist but fail a platform's minimum dimensions, exceed its byte limit, or trigger a redirect that the crawler declines to follow. After deployment, treat each platform's current debugger as part of the workflow — paste the URL in, confirm the fetched image matches what you uploaded, and re-trigger the fetch after any metadata change because most platforms keep a snapshot of the last successful preview.
The same caution applies to the visible content. A misleading title, description, or image can disappoint visitors and erode trust even if it earns a click. Metadata should describe what the page actually delivers, and when the page changes identity (a renaming, a relocation to a new canonical URL, a major restructure), every representation should be updated together: raw source, the fetched image response, and the live platform previews.
The reference for the protocol itself, including the four required and three optional properties discussed here, is the Open Graph Protocol specification. For the surrounding HTML rules around the meta element — where it belongs in the head, how escaping works, and how it relates to other metadata — the WHATWG HTML living standard applies.