gclid is the Google Click Identifier. Google Ads adds it to the landing page URL when someone clicks a paid advertisement, so that Google Analytics and Google Ads can connect the click to whatever the visitor does next. Like every parameter of its type, the page works without it.
If you have arrived here because you found a wbraid or a gbraid instead and could not find an explanation, skip to the section below. Those are the newer members of the same family, and almost nothing covers all three together.
How gclid gets onto a URL
Google Ads has a setting called auto-tagging. When it is switched on, which it is by default, Google appends gclid to the destination URL at the moment of the click:
https://example.com/pricing?gclid=EAIaIQobChMIx9v2
The advertiser does not add it manually and often does not think about it. The value encodes information about the click: which campaign, which ad group, which keyword matched, which device. It is not readable by you or by the advertiser directly. It is a lookup key into Google's own systems.
When the visitor lands, Google Analytics reads the gclid, and from that point the session is attributed to the paid campaign rather than showing up as generic organic traffic. Turn auto-tagging off and that link breaks, which is why advertisers leave it on.
wbraid and gbraid, and why they exist
In April 2021 Apple introduced App Tracking Transparency in iOS 14.5, which required apps to ask permission before tracking users across other companies' apps and websites. Most people said no.
That broke click-level attribution on iOS, so Google introduced two replacement parameters:
gbraid appears when the click starts inside an app, typically the Google app or YouTube, and lands on the web.
wbraid appears on web-to-web clicks in Safari where user-level tracking is not permitted.
The important difference is that both are designed to be aggregated rather than individual. A gclid maps to one click by one person. A wbraid is meant to support modelled, group-level reporting, so advertisers still get campaign numbers without a per-user identifier. Google's documentation on consent mode and conversion modelling describes the machinery in more detail than most people will want.
In practice you will encounter all three, sometimes on the same site depending on which device and browser produced the click.
dclid and srsltid
Two more from the same family, both less discussed.
dclid comes from Google's display and video advertising products rather than search. Same principle, different system.
srsltid started appearing on links from Google Shopping listings. It has caused genuine confusion among site owners, because it turns up on organic-looking traffic and can create a large number of distinct URLs for the same product page. If you run an online shop and have noticed your analytics filling with variants of your product URLs, this is usually why.
What I find genuinely interesting about this
Most writing about tracking parameters lands somewhere between shrug and outrage, and I do not think either is right.
The reason I keep reading about this stuff is that the parameter list is a readable record of an argument. Browsers restrict something, advertising systems move the same function somewhere the browser does not restrict, browsers restrict that, and on it goes. fbclid appearing weeks after Safari's tracking prevention update. wbraid appearing months after Apple's app tracking prompt. Every one of these parameters is a response to a specific restriction, and you can date them.
You can watch the same argument happening in reverse, too. Firefox now strips some of these parameters from URLs automatically. Safari removes tracking parameters from links in private browsing. The parameters get added, then removed, then redesigned to survive removal.
I clean my links because I prefer them short and I would rather not forward somebody's click receipt into a group chat. But I would be overselling it if I said that was the reason I find the topic worth the reading time.
Is it safe to remove?
Yes, in the sense that matters to you as someone receiving or sharing a link. No page needs gclid, wbraid, gbraid, dclid or srsltid to load correctly.
One caveat if you are on the other side of this. If you are an advertiser testing your own landing pages, stripping these parameters from your test URLs will break your own conversion tracking, and you may spend an afternoon wondering why your campaign appears to have stopped working. Strip them when sharing, not when testing.
Removing them by hand
Delete from the ? if there is nothing else in the query string. If there is, remove just the offending parameter and its value, keeping the & separators intact around it.
Google also wraps links in a redirect in some contexts, which is a separate problem with a separate fix. Links copied out of Google Search results, Google Docs and Gmail often look like this:
https://www.google.com/url?q=https%3A%2F%2Fexample.com%2Fguide&sa=D&usg=AOvVaw2K9pQ
The real destination is inside q. The google link cleaner unwraps that and strips the click identifiers in one step, and it also reverses Google AMP URLs, which are a third variation on the same theme.
For a quick one-off, the url cleaner tool online on the homepage handles any of these.
Frequently asked questions
What is the difference between gclid and utm_source?
utm_source is a label written by a human: it says "this link was placed in our newsletter". gclid is generated by Google at click time and encodes far more, including which keyword matched. UTM parameters are readable. gclid is not. There is more on the readable ones in UTM parameters explained.
Why do I see wbraid instead of gclid?
Almost always because the click came from an iOS device where user-level tracking was not permitted. It is the privacy-constrained substitute.
Does gclid work if I have blocked cookies?
Partly, and that is the point of it. Because the identifier travels in the URL rather than in storage, blocking cookies does not remove it. It still needs something on the destination site to read it.
Is srsltid hurting my SEO?
It can create duplicate URLs for the same page if your site treats query strings as distinct pages. A correct canonical tag on each product page is the standard fix.