What is fbclid? The Facebook click ID and the _fbc cookie, explained
When someone clicks one of your Meta ads, the landing page URL gets an extra parameter, something like ?fbclid=IwAR2F4.... fbclid is short for Facebook click ID. It is how Meta can tell, days later, that a purchase came from that click. It only works if your site keeps it, and many sites lose it without anyone noticing. Here is what it is, how it differs from UTM parameters, whether you should remove it, where it gets lost, and how to check your site in a few minutes.
What does fbclid mean in a URL?
Meta calls it the ClickID: a parameter Meta generates and adds to your website’s URL when someone clicks an ad on Facebook or Instagram. It identifies that one click, so every click gets a new value. On its own it does nothing. Your site has to store it and send it back to Meta with later events.
Meta documents it for ad clicks, but Facebook also adds it to many ordinary links people click, such as links in posts. So a URL with fbclid does not prove the visit came from an ad. And if someone copies such a URL and shares it elsewhere, everyone who opens it arrives with the same old click ID.
The value is case sensitive, and Meta says not to modify it in any way before using it, not even changing upper or lower case. Anything on your site that rewrites URLs should leave it alone.
How fbclid tracking works
The pixel turns it into _fbc
When the Meta Pixel runs on a page whose URL contains fbclid, it saves the value in a first-party cookie called _fbc on your domain. Meta’s developer documentation gives the format with this example:
fb.1.1554763741205.IwAR2F4-dbP0l7Mn1IawQQGCINEz7PYXQvwjNwB_qa2ofrHyiLjcbCRxTDMgk
fbis a fixed prefix.1is the subdomain index: the level of the domain the cookie belongs to (comis 0,example.comis 1,www.example.comis 2).1554763741205is the time the cookie was created, in milliseconds since 1970.- The rest is the fbclid itself, unchanged.
Next to it you will usually find _fbp, the pixel’s browser ID. _fbp says “this browser”. _fbc says “this browser arrived from that ad click”. From then on the pixel sends the stored value with its events, so a lead on the contact page or a purchase on the thank-you page carries the click ID, even though the URL no longer contains it.
If your developer builds the value with Meta’s Parameter Builder library, it can carry one more short segment after the click ID. Meta documents that variant, so it is not an error.
How long it lives
Meta says the _fbc cookie should be set with a 90-day expiry. When a person clicks another ad, the new click ID should replace the old one, so that your site always sends the most recent value.
Browsers do not always allow 90 days. Safari’s Intelligent Tracking Prevention caps cookies written by JavaScript at seven days, and the pixel writes _fbc with JavaScript. It cuts that to one day when the visitor was sent to your page by a site Safari classifies as a tracker, through a link with a query string. Meta’s documentation also describes setting the formatted click ID as a cookie from your server, which some Conversions API setups do.
How Meta uses it for attribution
Meta credits conversions to ads by matching events to the people who saw or clicked them. The click ID is the most direct evidence it can get. In Meta’s list of customer information parameters, click ID is one of only two rated high priority for matching, next to email.
Server events carry it too, as the fbc parameter, unhashed. Most Conversions API setups read it from the _fbc cookie in the visitor’s request, so if the browser never stored it, the server cannot send it either. Without the click ID, Meta relies on weaker signals: fewer conversions are linked to the ad that caused them, campaigns optimize on thinner data, and reported results can fall even when sales do not.
How is fbclid different from UTM parameters?
Both sit in the query string, but they do different jobs.
| fbclid | UTM parameters | |
|---|---|---|
| Who adds it | Meta, automatically | You, in the ad’s URL |
| Value | Unique to each click, not readable | Names you choose, such as utm_campaign=spring_sale |
| Who reads it | The Meta Pixel and Conversions API | Analytics tools such as Google Analytics 4 |
| What it is for | Tying a later conversion to one click | Grouping visits by source, medium and campaign |
You need both. Google Analytics 4 does not use fbclid to recognise paid traffic: its default Paid Social channel needs a social source and a paid medium, such as utm_medium=paid_social or cpc. Without UTM parameters, visits from your Meta ads can end up counted as organic social or direct traffic. In Ads Manager you can add UTM parameters in the ad’s URL parameters field, including dynamic values such as {{campaign.name}} that Meta fills in at click time. The two work side by side: your UTM parameters stay in the URL and Meta adds fbclid next to them.
Should you remove fbclid from your URLs?
Not before your tracking has read it. A redirect, link shortener or script that removes fbclid before the pixel runs is exactly what breaks attribution (see below). If you want tidy URLs, there are safer ways:
- Analytics reports: hide it in Google Analytics instead of removing it from the page (next section).
- SEO: the parameter does no harm as long as your pages declare a canonical URL. Google’s guide to duplicate URLs itself uses an address with an ad click ID (
?gclid=ABCD) as an example of a URL you would point to a canonical version. - The address bar: if a script cleans the URL for looks, it must run after the pixel has stored
_fbcand after any form script has read the value.
So, does removing fbclid affect your Meta ads? Removing it before the pixel stores it does: that visit loses its click ID. Hiding it in your analytics reports does not, because that only changes what your analytics tool records, not the address the pixel reads.
How to remove fbclid from Google Analytics reports
In GA4 most reports never show it. Page path, the dimension behind the Page path and screen class view of the Pages and screens report, is the part of the URL before the query string, so fbclid does not split your pages there. It only appears in dimensions that include the query string, such as Page location or Page path + query string.
If those dimensions matter to you, use GA4’s data redaction: in Admin, open Data streams, select your web stream and click Redact data, then add fbclid to the URL query parameters to redact. GA4 then replaces the value with (redacted) in the browser before the data is sent. It does not change data already collected, and it does not touch the page address, so the pixel still sees the click ID.
How to capture fbclid in forms, funnels or a CRM
If leads turn into sales outside your website (a sales call, a CRM, an invoice), store the click ID with the lead so you can send it to Meta later.
- Read the
_fbccookie, not just the URL. The cookie is already in the format Meta expects, and it survives navigation, so a form on the third page still gets it. Fall back to the URL’s fbclid only when the cookie is missing. - Put it in a hidden form field, filled by a small script or by your form tool if it can read cookies or URL parameters.
- Store the formatted value in your CRM. Meta allows keeping the formatted click ID in your own storage instead of a cookie. If you build it from the URL yourself, use the format
fb.1.<creation time>.<fbclid>with the time you first saw that fbclid. - Send it back as
fbcwith your Conversions API events, and do it promptly: Meta rejects events more than 7 days old.
Leads from Meta’s own Instant Forms (lead ads) never visit your site, so they have no fbclid. They come with a Meta lead ID instead.
Why fbclid goes missing
The visit did not come from a Meta click. Or it came from a lead form inside Facebook or Instagram, as above.
Redirects that drop the query string. This is the most common cause. The ad points to http://example.com/shoes, your server redirects to https://www.example.com/shoes/, and the redirect rule does not carry ?fbclid=... along. It happens before any script runs, so no tracking tool can recover it. Watch for redirects from http to https, between www and non-www, for trailing slashes, for language or country versions, and from old URLs to new ones.
Link shorteners and click trackers. If the URL in your ad is a short link or a tracking redirect, fbclid survives only if that service forwards query parameters to the final page. Test before you rely on one.
Consent setups. If the pixel waits for consent and the visitor never accepts, no _fbc is written. That is the consent setup doing its job. The problems are the other cases:
- the visitor accepts, but the consent tool never releases the pixel (see the pixel does not fire after consent);
- the visitor accepts on a later page, when
fbclidis no longer in the address bar; - first-party cookies are switched off in the pixel’s settings in Events Manager;
- the consent tool deletes
_fbcbecause it does not recognise it as approved.
Do not solve this by loading the pixel before consent. That swaps one problem for another (see the pixel fires before consent).
In-app browsers. On phones, ad clicks often open inside the Facebook or Instagram app’s own browser, and _fbc is stored there. If the person comes back later in Safari or Chrome to buy, that browser has no _fbc. Sending customer information such as a hashed email with your server events gives Meta another way to match the purchase.
URL clean-up and Safari’s protections. Some sites and single-page apps strip unknown parameters from the address bar as the page loads, sometimes before the pixel reads the URL. Safari’s Private Browsing removes some query parameters it identifies as used for cross-site tracking. Since Safari 26, Apple also says Safari stops known fingerprinting scripts from reading query parameters and from setting long-lived cookies. Apple does not publish which parameters or scripts are on its lists.
Is storing fbclid a privacy concern?
It is an identifier. fbclid points to one click, and Meta uses it to connect a conversion to the person who clicked. The _fbc cookie exists for advertising, so consent tools usually treat it as a marketing cookie. In practice: keep it behind the same consent choice as your pixel, store it only where you need it, and do not keep it longer than you use it. What the law requires in your case is a question for your privacy advisor; we only describe the technical behaviour.
How to check it on your site
Use Chrome or Firefox for this, since Safari’s private mode may remove the parameter on its own.
- Open a private window, open developer tools (F12) on the Network tab and tick Preserve log, so redirects stay visible.
- Open the exact landing URL from your ad with a made-up click ID added:
https://example.com/landing?fbclid=test123(or&fbclid=test123if the URL already has a?). This sends a normal page view to your own pixel. It does not create an ad click. - Look at the first requests. If you see a
301,302,307or308, click it and check the Location header. Does it still containfbclid=test123? - Accept the cookie banner and wait a few seconds.
- Go to Application (Chrome) or Storage (Firefox), open Cookies for your domain and find
_fbc. It should look likefb.1.<timestamp>.test123. - Filter the Network tab by
facebook.com/tr. Pixel requests sent after you accepted usually carry anfbcparameter with the same value. - Click through to another page of your site.
_fbcshould still be there.
If _fbc is missing or does not end with your test value, our guide on a click ID that is not stored walks through each cause and fix. If you also send server events, make sure they pass the same value as fbc; the Conversions API setup guide covers what else they should carry.
IsPixelWorking runs this test for you, redirects included, as part of its free check.
Check your own pixel. Paste a landing page and see what it sends to Meta before and after consent. Free, about a minute.
Check a page