Why Third-Party Cookies Can't Be Deleted by Your CMP

Why website JavaScript cannot delete cookies set on a third-party domain.

No consent platform can delete third-party cookies, because browsers only let JavaScript remove cookies belonging to the site’s own domain. When consent is withdrawn, Cookie Control deletes what it can and, for the rest, shows the visitor a manual opt-out link for each provider — an honest answer to a hard browser limit.

Here is a limitation every consent platform on the market shares and few put on a public page: when a visitor withdraws consent, some cookies cannot be deleted by the platform. Not ours, not anyone’s. The reason is the browser itself, and what separates CMPs is not whether they hit this wall — it is whether they tell the visitor the truth when they do.

The browser rule behind it

Cookies belong to domains, which is the whole first-party or third-party distinction. A script running on your site can create, read and delete cookies for your domain — that is how the consent cookie itself works. But a cookie set for another domain, by an embedded script or iframe, lives in a jar your JavaScript is never allowed to touch. The browser’s same-origin discipline, the thing that stops a malicious page reading your bank’s cookies, equally stops a well-intentioned consent platform deleting an ad network’s. There is no API, no workaround, no clever trick that a CMP vendor is withholding: deletion of a third-party cookie is available only to the third party, or to the visitor through their own browser. Our documentation says it in one line — Cookie Control, and JavaScript generally, cannot delete third-party cookies for browser security reasons.

What consent withdrawal can actually do

Withdrawal still works — it just works at the right layer. When a visitor revokes a category, the associated scripts stop loading from that point on — on the current edition through the category’s onRevoke handler your developer wires up, on Premium through its automatic script blocking — so the third-party cookies stop being refreshed and stop being read by the vendor’s script on your pages. The already-set cookie sits inert until it expires or is removed. What withdrawal cannot do, for the reason above, is reach into another domain’s jar and empty it.

How Cookie Control handles it: the attention list

Rather than silently succeeding at half the job, Cookie Control tells the visitor. On the current edition, where cookies could not be automatically revoked, the preference panel presents them under an explicit heading — Some cookies require your attention — with the statement that consent for the following cookies could not be automatically revoked, and a manual opt-out link for each provider. The visitor gets a working route to finish the job with the party that can actually do it. The behaviour is driven by the thirdPartyCookies property on each category, which lists the vendors that category enables along with the URL where users can opt out — and it exists precisely because this browser limit does.

Cookie Control listing third-party cookies that require a manual opt-out after consent withdrawal.

What you should do as a site owner

1. Prefer blocking to cleanup. Cookies that never get set never need deleting — keeping scripts off the page before consent does the real work (Premium’s automatic script blocking, or category callbacks on the current edition), and cleanup is the fallback. This is also why our Meta Pixel integration initialises the pixel with consent revoked rather than letting it set cookies first.
2. Configure the manual opt-out links for the third-party services you actually use, so the attention list is accurate rather than generic. A scan tells you which third parties are setting cookies; our note on what a scanner can and cannot find tells you where to double-check.
3. Say it plainly in your cookie policy: withdrawal stops our use of these services, and for their existing cookies here is where to go. Honesty about the limit reads far better than a deletion promise no one can keep.