Web Workers and Consent: The Scripts Your Wrapper Cannot See

Published 2026-10-16

Every consent stack has a mental model: scripts arrive as tags, the wrapper holds the non essential ones, choices release or block them, and the network panel tells the truth about what ran. Web workers break the model quietly. A worker is a script running in a parallel thread, created by code rather than by a tag in the page, with the ability to make its own network requests. Analytics, fingerprinting, and data collection code can live there, beyond the reach of blocking that only inspects the document.

Workers are not exotic. Legitimate uses are everywhere, from image processing to offline sync. The consent problem is specific: collection that migrates into a worker inherits invisibility. This guide explains how worker based tracking escapes common wrappers, how to detect it, and what to require from vendors who use workers.

Why wrappers miss workers

Most blocking works at predictable checkpoints: script elements in the document, known tag manager containers, and in some tools, main thread fetch and beacon calls. A worker bypasses the first two completely, because it is instantiated from a URL or even from an in page blob by code that itself looks innocuous. Once running, the workers requests originate from its own context, and request logs that attribute traffic to the page can mislabel or miss the source. A fingerprinting routine that would be flagged instantly as a script tag can run for years inside a worker created by a mainstream library, noticed by nobody, because every audit tool was pointed at the document.

Detecting worker based collection

Detection starts in the browser tools most teams already have: the application and sources panels list active workers per page, and any worker you cannot attribute to a known feature deserves investigation. Search your own codebase and your vendor configuration for worker construction and for libraries known to offload collection into workers. Then do the behavioral test that settles arguments: in a clean profile, decline all optional categories and watch total network traffic while using the site thoroughly, including the features vendors describe as performance or security tooling. Requests to analytics or advertising endpoints after a full decline are findings regardless of which thread sent them.

What to require from vendors

Put workers in the vendor conversation explicitly. Ask whether the vendors code creates workers, what data those workers collect and transmit, and whether the whole mechanism, worker included, honors consent state changes including withdrawal mid session. Get the answer in the data processing documentation, not in a sales call. In your own integration, gate worker creation behind the same consent check that gates the parent script: if the category is declined, the worker is never constructed. Treat a worker the way you treat a tag, because from the visitors data perspective there is no difference at all.

The withdrawal test

Consent systems are usually tested at load time, but workers expose the harder case: what happens when a visitor withdraws consent after collection has started? A worker already running may keep its schedule, its queued payloads, and its network access unless the integration explicitly terminates it or flags it silent. Test it directly: accept, browse, withdraw, and observe. Silence after withdrawal, no further transmissions from any thread, is the passing grade. Vendors whose architecture cannot stop a running worker have told you something important about how seriously withdrawal was engineered into the product.

Related reading

These earlier guides cover connected questions in more depth: Returning Visitors and Consent Expiry: When to Ask Again, Consent Granularity: Why Category Level Choices Beat All or Nothing, and Top Cookiebot Alternatives Worth Switching To.

Frequently asked questions