What is the ar_debug cookie?
Enables transitional debugging and diagnostic reporting for ad conversion measurement via the Privacy Sandbox Attribution Reporting API.
Table of Contents
About ar_debug
| Vendor | |
|---|---|
| Category Category The functional category of the technology, such as Web Analytics or Social Media. Learn more | Advertising & Paid Media |
| Consent Category Consent Category The consent category this cookie most commonly falls under across sites we scan, normalized into four standard categories. Learn more | Targeting & Advertising |
| Prevalence | Very Common |
| Popularity Popularity Popularity is calculated from our dataset of 4.5B+ cookies analyzed across hundreds of millions of web pages. Learn more | Found on 18.6% of scanned pages |
| Expiration Type | Mixed |
| Party Type Party Type Whether the cookie is first-party or third-party. Learn more | 3rd-Party |
| Risk Level Risk Level Rates how sensitive the data stored by this cookie is (High, Medium, or Low) based on data classification and distribution. Learn more | Medium |
| Vendor Privacy Policy | https://policies.google.com/privacy |
| Vendor Website | https://www.google.com/ |
What is the purpose of ar_debug?
The ar_debug cookie is a transitional debug cookie defined by the Privacy Sandbox Attribution Reporting API (ARA), a web-measurement standard stewarded by Google/Chrome. Although the cookie name is standardized by the API specification, the cookie itself is set independently by whichever ad-tech platform acts as the 'reporting origin' on a given site. In this dataset it is set under many different third-party domains - for example Google (google-analytics.com via the Privacy Sandbox conversion endpoint), Pinterest (ct.pinterest.com), LinkedIn (px.ads.linkedin.com), Criteo, AdRoll, RTBHouse, Amazon, and Yahoo - so it is best understood as a multi-vendor cookie rather than one set exclusively by Google.
Functionally, when this cookie is present (typically with the value 1) during both an ad interaction (the source) and the subsequent conversion event (the trigger), it instructs the browser to generate and send transitional debug reports to the reporting origin. This lets ad-tech providers verify their ARA integrations, measure data loss compared with legacy cookie-based measurement, and troubleshoot conversion tracking during the industry transition away from third-party cookies. The cookie carries only a debug flag, not a persistent user identifier. As of Chrome M132 the requirement to set the ar_debug cookie for cookie-based debug reporting was removed, so its presence is increasingly tied to older configurations and to third-party cookie availability.
What are the Privacy Risks of ar_debug?
Risk Level: Medium
The cookie value is a simple debug flag (e.g., 1) rather than a persistent unique user identifier, which on its own is low-risk. However, the technology it serves - the Attribution Reporting API's transitional debug reporting - exists specifically to measure and reconstruct cross-site ad interactions and conversions, and the cookie only functions in a third-party context where the reporting origin already has third-party cookie access. This cross-site conversion-measurement context is characteristic of behavioral advertising and attribution tooling, which justifies a Medium rather than Low rating, even though the cookie itself does not directly store PII.
How to Remove ar_debug from a Website
Removal is controlled by the website operator at the level of the ad-tech tags that use the Attribution Reporting API in debug mode. Because the cookie is set automatically by a vendor's reporting-origin script (e.g., Google Analytics/Ads, Pinterest, LinkedIn, Criteo, AdRoll) when that vendor requests transitional debug reports, it cannot be removed independently of the tag that sets it. A site administrator should identify which vendor tag is the reporting origin (the domain on which ar_debug is set), then either disable that vendor's Attribution Reporting debug configuration/debug mode, update the tag so it no longer requests cookie-based debug reporting, or remove the associated marketing/measurement tag entirely from the tag management system. If the debugging configuration is managed account-side by the vendor, the operator should contact the vendor to disable it. If none of these options are available, the cookie effectively cannot be removed without removing the vendor's measurement integration.