How to Find a Facebook Page ID for the Page Plugin

A Facebook Page ID is the numeric identifier for a Page, found by resolving the Page's public URL. Note one thing before you start: the Page Plugin's data-href attribute is documented as taking the URL of the Facebook Page, not a bare ID. You usually need the ID for Graph API calls and the URL for the embed itself.

That mismatch is the single most common reason a Page embed renders as an empty box. A developer finds the Page ID, drops it into data-href, and gets nothing. No console error worth reading, no broken-image icon, just blank space where a timeline should be. The plugin was handed something it does not accept.

Does the Page Plugin need a Page ID or a Page URL?

A URL. Meta's Page Plugin documentation describes href (as the HTML5 attribute data-href) simply as the URL of the Facebook Page, and that is the only form the documentation specifies. So the working markup looks like this:

<div class="fb-page"
  data-href="https://www.facebook.com/YourPageName"
  data-tabs="timeline"
  data-width="500"
  data-height="700">
</div>

If what you are holding is a numeric ID rather than a name, you can construct a URL form from it. A profile-style URL built around the ID is generally what people reach for here. Test it in your actual embed before shipping, because plugin behaviour with ID-derived URLs is not something the documentation promises and Meta has changed plugin internals before.

The other attributes are worth knowing because the defaults surprise people. The documented set includes data-tabs (default timeline, also accepting events and messages, comma-separated), data-width (default 340, minimum 180, maximum 500), data-height (default 500, minimum 70), data-hide-cover, data-show-facepile, data-hide-cta, data-small-header, data-adapt-container-width (default true) and data-lazy. The old data-show-posts attribute is deprecated; use data-tabs="timeline" instead.

Two of those cause most layout complaints. The maximum width is 500 pixels, so a plugin cannot fill a wide desktop column no matter what CSS you write around it. And data-adapt-container-width defaults to true, which means the plugin shrinks to its parent, so a narrow wrapper silently overrides your data-width.

So when do you actually need the numeric Page ID?

For everything that is not the embed. The ID is what the Graph API addresses, so it is what you need the moment you move past a decorative timeline widget into reading or writing data.

Reading a Page's public fields, pulling insights, publishing a post as the Page, subscribing the Page to webhooks, attributing Conversions API events, targeting ad audiences by Page engagement: every one of those references the Page by ID. The embed is the odd exception, not the rule, which is why the mix-up happens so reliably. Developers learn the ID-based pattern from the API and then apply it to the one component that wants something else.

Store the ID rather than the Page name, because names change. A rebrand that updates the vanity URL breaks every stored reference to facebook.com/oldname while leaving the numeric ID valid. If your embed is generated from stored data, keep the ID as the source of truth and build the URL at render time.

How do you find a Facebook Page ID?

Several routes, and which one fits depends on whether you administer the Page and whether you have API credentials set up.

If the ID is already in the URL

Some Pages still use the older URL form facebook.com/pages/SomeName/123456789012345, where the final path segment is the Page ID. If yours looks like that, copy the number and you are done. This format appears less often now than it used to, but it has not disappeared.

If you administer the Page

Page management surfaces expose the ID somewhere in the Page's own settings or about information. Meta reorganises these interfaces frequently and has run several parallel versions of Page management in recent years, so rather than following a menu path that may have moved, look for the Page's settings or transparency details and scan for a field labelled with the Page ID. If you cannot find it, the URL-resolution route below works regardless of interface changes.

If you have Graph API access

With a valid access token you can query the Page node and read its id field. This is the canonical method and the one to build into production code. Pin an explicit API version while you are at it: v26.0 became current in July 2026, and it made several legacy Page fields return a version error outright for Pages on the New Pages Experience. A call that worked on an older version can break on a version bump, so read the changelog before upgrading.

If you just need the number from a public URL

Paste the Page URL into the Facebook Page ID finder and read off the result. No login, no app, no token. This is the pragmatic route when you are converting a list of client Page URLs into IDs during onboarding, where setting up a Graph API app would be more work than the task deserves.

The limit to be honest about: this reads public data only. Pages are public by nature so they resolve well, but an unpublished Page, one still in draft, or one restricted by region or age-gating may not. That is the platform's visibility rules applying, not a defect in the lookup.

Why is the Page Plugin rendering as an empty box?

Assuming you have passed a Page URL and not an ID, work through these in order. They account for most failures.

The SDK is not loaded, or is loaded after the plugin markup, or the fb-root div is missing. The plugin is parsed by the Facebook JavaScript SDK, and without the SDK present the div.fb-page is just an empty div that renders as nothing. In single-page applications this shows up as an embed that works on first load and vanishes on client-side navigation, because the SDK only parses the DOM once. Re-parsing after a route change is the fix.

The container is too narrow. With data-adapt-container-width defaulting to true, the plugin collapses to fit its parent, and a parent with no resolved width can produce an embed with no visible width. Give the wrapper an explicit width.

The target is not a Page. A personal profile URL or a group URL will not render in this plugin. The three object types look interchangeable and are not; if you are unsure which you are holding, resolve it first. Groups in particular have a separate plugin, so the Page Plugin will never show group content.

Content blockers and tracking-prevention settings stop the SDK from loading at all in some browsers. Test in a clean profile before concluding your markup is wrong, and be aware that a meaningful share of real visitors will never see any Facebook embed for this reason. If the timeline matters to your page, do not make it the only way to reach that content.

A share link rather than a canonical URL. Shortened or wrapped Facebook links do not work as data-href values. Run them through the share link expander to recover the real destination URL first.

Should you use the Page Plugin at all?

A fair question, and the answer depends on what you want from it. As a decorative "find us on Facebook" element it is cheap and it works. As a content delivery mechanism it has real drawbacks that are worth weighing before you build around it.

It loads third-party JavaScript, which costs you page weight and adds a cross-origin dependency on your critical path. It is blocked for a non-trivial share of visitors by privacy tooling. It caps at 500 pixels wide, which fits badly into modern layouts. And because it renders inside an iframe, its content is not part of your page for search engines.

The alternative, for anyone with API access, is to pull Page posts through the Graph API by Page ID, cache them server-side, and render them in your own markup. More work up front, but you control the layout, the content is real HTML in your page, and no third-party script is involved. This is also where having the Page ID stored properly pays off, which loops back to the point of resolving it in the first place.

If you are working across platforms, the equivalent identifier for each one has its own quirks. Instagram's numeric user ID is covered in the Instagram ID lookup, and YouTube's three-way split between channel ID, handle and custom URL is covered in the YouTube channel ID lookup. Neither behaves quite like Facebook.

Frequently asked questions

Can I put a numeric Page ID directly in data-href?

Not as a bare number. Meta documents data-href as taking the URL of the Facebook Page, so pass a URL. You can construct a URL form from an ID, but test it in your real embed before shipping, since ID-derived URLs are not what the documentation specifies and plugin internals have changed before.

Why does my embed work locally but not in production?

Usually the SDK. Check that it loads over HTTPS on the live domain, that the fb-root element exists, and that the script is not blocked by your content security policy. In single-page apps, also confirm the SDK re-parses the DOM after client-side navigation, since it only scans for plugin markup once on initial load.

How wide can the Facebook Page Plugin be?

The documented maximum for data-width is 500 pixels, with a minimum of 180. No CSS around the plugin will push it past that cap, because the content renders inside an iframe the plugin controls. If you need a full-width feed, pull posts through the Graph API and render them yourself instead.

Does the Page Plugin work for personal profiles or groups?

No. It is built for Pages only. A personal profile URL will not render content there, and groups have a separate plugin of their own. If you are not certain which object type your URL points at, resolve it first, because the three look similar in URL form but are entirely different objects to the platform.

Will I need API credentials to find a public Page ID?

Not for a one-off lookup. Resolving a public Page URL to its numeric ID needs no app, token or login. Build the Graph API path when your own application needs to resolve IDs at runtime; for turning a spreadsheet of client Page URLs into IDs, a browser-based lookup is faster and involves no credential management.

Does the Page ID change if the Page is renamed?

No. Renaming a Page or changing its vanity URL leaves the numeric ID untouched, which is precisely why integrations should store the ID rather than the name. The old vanity URL may stop working after a rename, and the freed handle can be claimed by someone else, so a stored name is not a stable reference.