Facebook share previews are generated from Open Graph meta tags in the page head, not from a Graph API access token. The crawler that builds the share card fetches the public URL, parses the HTML it returns, and reads four required properties — og:title, og:type, og:image, and og:url — each expressed as a meta element with a property attribute. If any of those four are missing or malformed, the preview degrades regardless of how thoroughly you configured an app or generated an access token. This is why the question "how to get a Facebook Graph API token" is often the wrong question for share preview work. The token governs read and write operations against Facebook's data layer through the Graph API — posting to a Page, fetching Page insights, uploading a photo, listing comments — and none of those operations participate in the link-preview pipeline. The link-preview pipeline reads your own server's HTML. So if your goal is to control what appears when someone pastes your URL into a Facebook post, the practical answer is to publish a complete, valid Open Graph block, not to register an app and request an access token.
What Facebook Reads When Someone Shares Your Link
When a Facebook user pastes a link into a post, comment, or message, the platform's crawler fetches that page and looks at the meta elements in its head. It does not ask for credentials. It does not call the Graph API on your behalf to render a preview. The crawler behaves like any other web crawler: it requests the public URL, parses the HTML, and chooses the values it needs from the metadata already there.
That model is why the Open Graph Protocol exists. The protocol, documented publicly at ogp.me, defines a small set of property-based meta tags that describe a page as a "graph object" — a thing that can be shared, liked, and acted on consistently across services that understand the spec. Facebook's crawler, LinkedIn's crawler, Slack's unfurler, and several other platforms all implement that same vocabulary. The WHATWG HTML specification documents the underlying meta element semantics, including how browsers and tools parse its attributes.
In practical terms: if your page head already contains the right Open Graph tags, Facebook will pick them up the next time its crawler reaches the URL. No token, no app review, and no Graph API call is involved.
Why a Graph API Token Does Not Change the Preview
A Facebook Graph API access token is a credential that proves a request comes from a registered app or a logged-in user. You use tokens when you want to read the graph (fetching a Page's posts, posting to a Page, uploading a photo to a profile) or when you want to programmatically publish content. Those are write operations on Facebook's data layer.
The link preview pipeline is a read operation on your own website. Facebook's crawler reads your HTML. It does not authenticate against the Graph API for the metadata step; it only consumes the meta tags that are already publicly served. That is why developers who chase a token for "fixing" share previews often come away with a working app, a configured product, and the same blank or stale preview they started with. The token never touched the preview path.
The Open Graph tags, by contrast, sit directly inside the HTML the crawler fetches. That is the layer you can influence.
Building a Share-Ready Open Graph Block
This is the practical path. Instead of registering an app, requesting permissions, and exchanging an OAuth code for an access token, you generate the metadata Facebook's crawler is actually waiting for and place it on the page.
The fastest way to do that without writing raw HTML by hand is the Open Graph Generator, a browser-side tool that builds the block from the four facts Facebook needs and the three optional properties the protocol supports. All work happens in your browser; nothing is uploaded to a server.
Follow these steps:
- Open the Open Graph Generator and enter the object title in plain text. Use the same wording you want users to see in the Facebook share card. Avoid clickbait, and keep the value concise so it does not get truncated on smaller cards.
- Choose the object type from the dropdown. The tool deliberately limits the choice to website or article. Pick website for a homepage, landing page, or product page; pick article for a blog post, news story, or editorial.
- Paste the canonical page URL. It must be an absolute HTTP or HTTPS link with no fragment and no embedded credentials. The tool normalizes the address and rejects anything else, because client-side anchors would split shares across variations of the same resource and credentials would leak account information into public metadata.
- Paste a publicly reachable image URL. The tool checks the URL shape but does not fetch the image, so verify on your end that the link returns a successful response, serves an image MIME type, and meets each platform's recommended dimensions and byte size for the largest preview surface.
- Optionally add an og:description that summarizes the object in one or two sentences, an og:site_name that names the larger publication, and an og:locale in language_TERRITORY form such as en_US. The generator trims and bounds each value, rejects control characters, and escapes ampersands, quotes, and angle brackets so the generated meta element cannot break.
- Generate the block. The output is a small set of property-based meta tags in stable order — the four required properties first, then the optional ones in the order you filled them. Copy the entire block.
Required and Optional Properties at a Glance
The seven properties the Open Graph Generator exposes split cleanly into a required set and an optional set. The table below compares them by class, purpose, and an example value, so you can see at a glance which four the protocol insists on and which three add depth without becoming mandatory. Missing any required value causes the generator to block output rather than emit an incomplete block.
| Property | Class | Purpose | Example value |
|---|---|---|---|
| og:title | Required | Names the object as it appears in the share card | How to Get a Facebook Graph API Token Without an App |
| og:type | Required | Classifies the object for the consumer | article |
| og:image | Required | Supplies the representative preview image | https://example.com/preview.png |
| og:url | Required | Identifies the permanent canonical object | https://example.com/facebook-token/ |
| og:description | Optional | Summarizes the object beneath the title | A practical tag-only path to Facebook share previews. |
| og:site_name | Optional | Names the larger publication or brand | Example.com |
| og:locale | Optional | Specifies the resource's language and region | en_US |
Adding the Block to the Canonical Page Head
The generated tags go inside the head of the page that matches the og:url value. Paste them once, and paste them only there. A few practical rules keep the block from being silently rewritten or ignored.
Place the block before any framework-injected social metadata. Many CMS plugins and JavaScript frameworks write their own meta tags into the head. If two blocks describe the same property, the later one wins for parsers but the earlier one can confuse debuggers. The protocol specifies property syntax, not name syntax, and consumers expect exactly that shape.
Do not encode the block twice. Wrapping the meta elements inside a JavaScript string and writing them out at runtime defeats the crawler. The crawler fetches HTML, not an executed DOM.
Do not place the tags in the body as visible text. They are not user-facing content. They are machine metadata.
After publishing, view the page source and confirm the block is present, in order, with the values you entered. Build tools can reorder, overwrite, or strip head content. The only check that matters is the raw HTML the crawler receives.
Verifying Crawl Access and Cache Refresh
A valid Open Graph block is necessary but not sufficient for the share card you actually want. Facebook's crawler can be blocked by a robots.txt disallow, by an authentication wall, by a rate-limited CDN, or simply by a previous cache entry. After deployment, two checks close the loop.
Open the platform's current preview debugger and enter the og:url. The debugger fetches the page from a Facebook-controlled crawler and reports the values it sees, the warnings it has for missing or invalid properties, and the size of the image it downloaded. If it cannot fetch the page, the share preview will remain blank.
Use the scrape-again action to force a cache refresh after you change the metadata. Facebook keeps an internal copy of the metadata it last saw; a live URL change does not immediately invalidate it. The scrape call clears the cache and re-fetches the page.
Run the same checks on any other platforms you care about — LinkedIn's Post Inspector, Slack's link unfurler, X's Card Validator — because each service applies its own image requirements, caching rules, and field fallbacks.
When a Token Actually Becomes Necessary
A Graph API token becomes necessary the moment you stop being a passive participant in sharing and start asking Facebook to do work. If you want to programmatically post to a Page, read insights, upload a photo to a Page album, or pull a list of comments, every one of those requests must carry an access token issued by an app with the corresponding permission and a current review status. None of those token-gated actions control how a link preview renders for a third party's share. They live in a separate layer.
So if the only thing you wanted the token for was "making Facebook show the right preview when someone shares my URL", the Open Graph tags already cover that. If you genuinely need to read or write Facebook data, plan on registering an app, configuring OAuth, and managing token lifecycles — but expect that work to be additive to the metadata layer, not a replacement for it.