---
title: "What is fbclid? The Facebook click ID and the _fbc cookie, explained"
description: "fbclid is the click ID Meta adds to links from Facebook and Instagram. What it means, how it differs from UTM tags, whether to remove it, and how to keep it."
author: "IsPixelWorking team"
published: "2026-10-12"
url: "https://ispixelworking.com/blog/fbclid-fbc-cookie-explained"
---

# What is fbclid? The Facebook click ID and the _fbc cookie, explained

IsPixelWorking team · published 2026-10-12

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
```

- `fb` is a fixed prefix.
- `1` is the subdomain index: the level of the domain the cookie belongs to (`com` is 0, `example.com` is 1, `www.example.com` is 2).
- `1554763741205` is 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](https://developers.facebook.com/docs/marketing-api/conversions-api/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](https://webkit.org/blog/8613/intelligent-tracking-prevention-2-1/), and the pixel writes `_fbc` with JavaScript. It [cuts that to one day](https://webkit.org/blog/8828/intelligent-tracking-prevention-2-2/) 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](https://www.facebook.com/business/help/765081237991954), 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](https://developers.google.com/search/docs/crawling-indexing/consolidate-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 `_fbc` and 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](https://support.google.com/analytics/answer/13844737), 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](https://support.google.com/analytics/answer/13544947): 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 `_fbc` cookie, 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 `fbc` with 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](https://ispixelworking.com/guides/meta.not_firing_after_consent/generic));
- the visitor accepts on a later page, when `fbclid` is no longer in the address bar;
- first-party cookies are switched off in the pixel's settings in Events Manager;
- the consent tool deletes `_fbc` because 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](https://ispixelworking.com/guides/meta.fires_before_consent/generic)).

**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](https://webkit.org/blog/15697/private-browsing-2-0/) it identifies as used for cross-site tracking. Since Safari 26, Apple also says Safari [stops known fingerprinting scripts](https://webkit.org/blog/16993/news-from-wwdc25-web-technology-coming-this-fall-in-safari-26-beta/) 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.

1. Open a private window, open developer tools (F12) on the **Network** tab and tick **Preserve log**, so redirects stay visible.
2. Open the exact landing URL from your ad with a made-up click ID added: `https://example.com/landing?fbclid=test123` (or `&fbclid=test123` if the URL already has a `?`). This sends a normal page view to your own pixel. It does not create an ad click.
3. Look at the first requests. If you see a `301`, `302`, `307` or `308`, click it and check the **Location** header. Does it still contain `fbclid=test123`?
4. Accept the cookie banner and wait a few seconds.
5. Go to **Application** (Chrome) or **Storage** (Firefox), open **Cookies** for your domain and find `_fbc`. It should look like `fb.1.<timestamp>.test123`.
6. Filter the Network tab by `facebook.com/tr`. Pixel requests sent after you accepted usually carry an `fbc` parameter with the same value.
7. Click through to another page of your site. `_fbc` should 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](https://ispixelworking.com/guides/meta.fbc_not_set/generic) 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](https://ispixelworking.com/guides/general.server_side_not_detected/generic) covers what else they should carry.

IsPixelWorking runs this test for you, redirects included, as part of its free check.