How to find which script sets a cookie in Chrome

A cookie's domain tells you where it belongs. It does not tell you which line of JavaScript created it. First determine whether the cookie came from an HTTP response or a browser script. Then follow the response or call path. Searching a tag-manager container before making that distinction can send you to the wrong part of the stack.

You need access to the browser, not necessarily the site's source repository, to start this investigation. Source maps, tag-manager preview access and a staging environment make the final attribution much easier. Where those are unavailable, keep the conclusion narrower: a request origin is useful evidence, but it is not always the exact caller.

Record the cookie identity before searching for it

Write down the name, domain and path. Include a partition key if the browser shows one, along with Secure, HttpOnly and SameSite attributes. Record whether the cookie existed before the page loaded. Avoid pasting its value into a public issue; an apparently random string may be a session credential or a persistent identifier.

Reproduce the event with DevTools open before navigation. Keep a baseline without banner interaction, then note the exact action that produces the cookie. If you only opened DevTools after the cookie appeared, start again rather than treating a missing request as proof that JavaScript created it.

If the cookie comes from a response, follow the request

1. Search the recorded network traffic for the cookie name and inspect candidate response headers for Set-Cookie.
2. Record the response URL and status. Check redirects as well as the final document; an earlier response may be responsible.
3. Check whether Chrome accepted the cookie or blocked it. An attempted Set-Cookie header and a stored cookie are different observations.
4. Inspect the request initiator to understand why the browser made that request. If a JavaScript stack is available, follow it into the relevant source.
5. If a first-party endpoint sets the cookie, investigate the application or middleware serving that endpoint. Do not assume a third-party hostname is required for tracking.

Chrome's Network reference documents the Initiator column and the available request stack trace. These help explain a request. They do not, by themselves, identify every JavaScript cookie write on the page.

If JavaScript writes it, narrow the caller

Search loaded sources for the cookie name and the vendor's initialization code. Look for cookie helpers as well as direct document.cookie assignments. Names can be assembled dynamically, so a failed text search is not decisive. Use a source breakpoint on the candidate write or helper, reload, and inspect the call stack when execution pauses.

When source maps are available, work from the original modules instead of guessing from a minified bundle name. On staging, temporarily disable one suspected integration at a time and repeat the same action. A disappearing cookie narrows the cause, but check that the experiment did not also prevent unrelated parts of the page from loading.

Where ConsentScope helps, and where Chrome is still needed

The ConsentScope DevTools panel brings captured events and their consent timing together. Its Initiator Trace displays available browser-provided origin and frame information for third-party requests. That can point you toward an embedded player, a document or another origin worth investigating.

Initiator Trace is not a full JavaScript debugger. It does not promise a source line for every cookie, and an origin-only trace cannot identify a specific tag inside a GTM container. Use Chrome's stack and source tools, or the container's preview mode, when you need that level of attribution. Keep both pieces of evidence in the same ticket.

A worked investigation, without invented audit results

Consider this hypothetical staging problem: a marketing cookie appears after Reject all. A developer finds the vendor tag in GTM and disables it, but the cookie still appears. The next capture shows a second installation loaded by a site plugin. The practical lesson is to test the actual writer rather than stopping when you find the first familiar vendor name.

A useful ticket would include the exact reproduction path, cookie identity, request or breakpoint evidence, the suspected second installation, and a retest after its removal. The example is an investigation pattern, not a claim about a real website or a finding produced by ConsentScope.

Avoid three attribution traps

The cookie is first-party, so our application must have written it

A third-party library executing on your page can create a cookie scoped to your domain. The storage domain alone does not identify the library owner. Keep the distinction between the domain storing the cookie and the code responsible for the write.

The initiator says Other, so there is no source

It means that this view did not give you a useful script attribution. Recheck document responses, redirects, frame activity and whether recording began early enough. If the evidence still stops at the request, report that boundary honestly.

The export is redacted, so it is safe to publish

Inspect URLs, request payloads and screenshots before sharing. Redacting cookie values does not remove every possible identifier. Use a private developer ticket for sensitive evidence, and follow the client report template for a summary that does not expose raw session data.