fbclid decoder and _fbc builder

How to use the fbclid decoder

1. From a URL to _fbc. Paste the landing page URL as it arrived, with its fbclid, or the fbclid on its own. The tool finds the parameter and writes the _fbc value with the current time. Copy it.
2. Decoding a cookie. Paste an _fbc or _fbp value from your browser's cookie storage, a Conversions API payload or a log line. You get each part, the creation time as a date, and a check against Meta's format.

Both modes run in your browser. Nothing you paste is sent anywhere, which matters when the URL comes from a real visitor.

Can you decode an fbclid? What this fbclid decoder does

No tool can tell you what's inside an fbclid, and this one doesn't try. Meta generates the value and documents no structure for it. Its Conversions API documentation on ClickID says the value is case sensitive and must not be modified before use, not even lowercased.

So treat fbclid as an opaque string. “Decoding” here means two mechanical things: pulling the value out of a URL, and splitting an _fbc or _fbp cookie into the fields Meta defines. If you want to know which ad a visit came from, an fbclid won't tell you. Put {{ad.id}} in your URL parameters with the Meta Ads URL builder and read it on the landing page.

fbclid, _fbc and _fbp: what each one is

Meta's Cookies Policy gives _fbp and _fbc a lifespan of 90 days, and the ClickID documentation recommends the same 90-day expiry when you set _fbc yourself. The fbclid glossary entry covers what the click ID is good for, and our guide to fbc and fbp cookies goes further into how they're created.

The _fbc cookie format, field by field

Meta defines _fbc as four parts joined by dots. _fbp has the same shape, with a random number in place of the fbclid.

Values that went through Meta's Parameter Builder library can carry an extra appendix as a fifth part. The decoder recognises it and shows it separately.

Worked example

Example: a click reaches your landing page at 10:00:00 UTC on 4 November 2026, with this URL:

https://example.com/offer?utm_source=facebook&fbclid=IwAR2F4-dbP0l7Mn1IawQQGCINEz7PYXQvwjNwB_qa2ofrHyiLjcbCRxTDMgk

That moment is 1793786400000 in Unix milliseconds. Your server isn't saving an _fbc cookie, so the subdomain index is 1, and the value to send is:

fb.1.1793786400000.IwAR2F4-dbP0l7Mn1IawQQGCINEz7PYXQvwjNwB_qa2ofrHyiLjcbCRxTDMgk

The fbclid is the sample value from Meta's own documentation. Paste the result into the decoder and it reads back as 2026-11-04T10:00:00.000Z.

Build fbc on the server when the cookie is missing

The _fbc cookie only exists if the Meta Pixel ran and could write it. Ad blockers, a declined consent banner or a landing page without the Pixel all leave you with no cookie, even though the fbclid was right there in the URL.

Meta's documentation covers this case. If there's no _fbc cookie but the request URL has an fbclid, build fbc yourself:

• Read the fbclid server-side, from the query string of the first request, before any redirect can drop it.
• Use subdomain index 1 when you're building the value without saving a cookie.
• Use the time you first received that fbclid as the creation time, in milliseconds, and keep it. Don't rebuild the value with a fresh timestamp on every event.
• Store it, either as an _fbc cookie set in your HTTP response (Meta recommends a 90-day expiry) or in your own database. Replace it when a new fbclid arrives.

This is work server-side tracking is good at: the server sees the URL whether or not a script runs.

Send fbc and fbp unhashed in user_data

In a Conversions API event, fbc and fbp go in user_data as plain strings. Meta's customer information parameters mark both as “Do not hash”, while email and phone are sent as SHA-256 hashes. Hash fbc and Meta can no longer read the click ID inside it.

"user_data": {
  "em": "<SHA-256 hash of the email>",
  "fbc": "fb.1.1793786400000.IwAR2F4-dbP0l7Mn1IawQQGCINEz7PYXQvwjNwB_qa2ofrHyiLjcbCRxTDMgk",
  "fbp": "fb.1.1596403881668.1116446470",
  "client_ip_address": "203.0.113.7",
  "client_user_agent": "Mozilla/5.0 …"
}

The Meta CAPI glossary entry walks through the rest of the payload, including event_id for deduplication.

Safari ITP and cookies set by JavaScript

The Meta Pixel is a script, so the _fbc and _fbp cookies it writes are JavaScript cookies, and Safari treats those differently. WebKit's tracking prevention documentation says ITP deletes cookies created in JavaScript after 7 days without user interaction with the site. When a click ID arrives as a URL parameter and JavaScript on the landing page stores it, ITP can cap those cookies at 24 hours.

That second case is exactly how a Pixel-written _fbc is born. A cookie your server sets with a Set-Cookie header, on the landing page's own domain, isn't covered by those JavaScript caps. Meta's own recommendation is to set _fbc in the HTTP response, and the same logic is why first-party tracking starts on the server.

DropCPL reads the fbclid on the landing page's own domain, in the same response that renders the landing page, and sends fbc and fbp with the Lead event through the Conversions API. The click ID reaches Meta even when the Pixel never ran. Start free →

Common mistakes with fbc and fbp

• Changing the case. Lowercasing a whole cookie string or URL is a classic normalisation step. Meta says the click ID is case sensitive, so the fbclid has to stay exactly as received.
• Seconds instead of milliseconds. A 10-digit creation time is seconds. The decoder flags it.
• A fresh timestamp on every event. The creation time is when the fbclid was first seen, not when you send the event.
• Hashing them along with email and phone. fbc and fbp go unhashed.
• Inventing an fbc when the visit had no fbclid. No fbclid means no fbc: send fbp and the other identifiers you have.
• Reading the fbclid from the fragment. Anything after # never reaches your server.