Cookies Aren't the Whole Story: How Browser Tracking Works Without Them
August 1, 2026 | Compliance | 4 min de lecture
Sur cette page
- An Empty Cookie Jar Can Still Hide Data Flows
- The Browser Has More Than One Storage Surface
- Local Storage Can Replace Part of a Cookie's Job
- Pixels and Beacons Can Send Data Without Storing It
- Link Decoration Carries Identity Through the URL
- Fingerprinting Uses Signals Instead of a Stored ID
- Service Workers Can Outlive a Single Page
- First-Party Collection Can Hide Downstream Vendors
- Audit Tracking Beyond Cookies
- What Your Consent Tests Should Assert
- Common Blind Spots
- Where SiteWall and CookieWall Fit
- Frequently Asked Questions
- Follow the Data, Not the Label
Progression de lecture
0%
encore 4 min
An Empty Cookie Jar Can Still Hide Data Flows
Cookies are visible, familiar, and easy to inspect, so they often become shorthand for every form of browser tracking. That shorthand creates a dangerous blind spot. A website can recognize a browser, preserve state, or transmit behavioral data without creating a traditional cookie.
A meaningful privacy review must follow the complete path: what code executes, what browser capabilities it reads, where it stores state, what identifiers it creates, what requests it sends, and how downstream systems use the result.
The Browser Has More Than One Storage Surface
| Mechanism | What it can hold | Important distinction |
|---|---|---|
Cookies | Session state, preferences, identifiers, and tokens | Eligible cookies are attached automatically to matching HTTP requests |
Local Storage | Persistent key-value data for an origin | Scripts must read the value and attach it to a request |
Session Storage | Key-value data scoped to a page session | Usually disappears when the tab or session ends |
IndexedDB | Larger structured datasets and application state | Can store complex records that are not visible in the cookie table |
Cache Storage | Responses and assets managed by applications or service workers | May preserve resources and state outside normal HTTP caching views |
Service workers | No direct identifier store by themselves | Can intercept requests and coordinate Cache Storage or IndexedDB |
Local Storage Can Replace Part of a Cookie's Job
A script can create an identifier in Local Storage, retrieve it on later visits, and include it in analytics or personalization requests. The browser does not place that value into request headers automatically, but the practical result can still be persistent recognition.
Review the key name, value pattern, origin, creation time, reader, business purpose, and outbound requests that use the value. A generic key such as visitor_id is only the beginning of the investigation.
const readStorage = (storage) =>
Object.fromEntries(
Array.from({ length: storage.length }, (_, index) => {
const key = storage.key(index);
return [key, key ? storage.getItem(key) : null];
})
);
const databases = await indexedDB.databases();
const cacheNames = await caches.keys();
const registrations = await navigator.serviceWorker.getRegistrations();
console.log({
cookiesVisibleToJavaScript: document.cookie,
localStorage: readStorage(window.localStorage),
sessionStorage: readStorage(window.sessionStorage),
indexedDB: databases,
cacheStorage: cacheNames,
serviceWorkers: registrations.map((item) => item.scope),
});Pixels and Beacons Can Send Data Without Storing It
A tracking pixel is often a tiny image request whose URL carries event information. JavaScript can also transmit data through fetch(), XMLHttpRequest, form submissions, WebSockets, or navigator.sendBeacon(). None of these mechanisms must create a new cookie to send the page URL, referrer, campaign data, event details, or an identifier obtained elsewhere.
Request details
- Destination hostname, path, method, resource type, and redirect chain.
- Query parameters, request body, custom headers, and response-set cookies.
- Whether the request occurs before consent, after rejection, or only after an approved choice.
Event context
- The page, interaction, form, or navigation that initiated the request.
- Whether the same event is sent through several vendors or first-party endpoints.
- Whether retries, batching, or page-unload behavior creates delayed transmissions.
Identifier sources
- Values read from cookies, Local Storage, IndexedDB, the URL, or application state.
- Account, order, campaign, device, or session identifiers supplied by the site.
- Values generated by the third party during the current page visit.
Consent behavior
- Which purpose and category authorize the request.
- Whether the request changes when consent is denied.
- Whether withdrawal stops future sends from already loaded code.
Link Decoration Carries Identity Through the URL
Links can include campaign parameters, click identifiers, affiliate codes, or other values that connect one visit to another. The destination can read those values from the URL and store or forward them through a different mechanism.
Inspect landing URLs, redirect chains, history changes, and links rewritten after page load. Pay particular attention when identifiers move between domains or appear in URLs that can enter browser history, referrer headers, analytics logs, screenshots, or support tickets.
Fingerprinting Uses Signals Instead of a Stored ID
Fingerprinting attempts to distinguish a browser or device using a combination of observable characteristics. Potential inputs can include platform details, language, time zone, screen properties, supported features, graphics behavior, font availability, media capabilities, and network characteristics.
| Observation | Question to ask |
|---|---|
Many device characteristics collected together | Is the combination used to distinguish or score a browser? |
Canvas, graphics, audio, or font probing | Does the use support a visible feature, or does it produce a stable signature? |
A derived value sent to a remote service | Can it link sessions, devices, accounts, or activity over time? |
Collection occurs before a consent choice | What purpose and legal basis authorize the behavior? |
Signals change after rejection | Is the technology reducing data, or does recognition continue through another path? |
Service Workers Can Outlive a Single Page
A service worker can intercept requests for pages within its scope, serve cached responses, receive messages from pages, and coordinate background behavior supported by the browser. It can work with Cache Storage and IndexedDB, so clearing cookies alone may leave other application state intact.
Check the service worker's script URL, scope, owner, registration timing, controlled pages, cache names, network behavior, and unregister path. Do not remove a legitimate worker merely because it exists. Progressive web applications and offline features often depend on one.
First-Party Collection Can Hide Downstream Vendors
A browser may send an event to your own domain while a server, tag gateway, or edge worker forwards it to another provider. From the browser, this can look like first-party traffic even though additional recipients process the event downstream.
Browser-side evidence
- First-party collection endpoints and the events sent to them.
- Identifiers, account data, page context, and consent signals in each payload.
- Scripts or tags responsible for creating the request.
Server-side evidence
- Forwarding rules, tag-gateway destinations, queues, and event transformations.
- Providers receiving the data after the browser request completes.
- Retention, access, deletion, and consent enforcement in downstream systems.
Governance evidence
- Owner, purpose, legal basis, vendor agreement, and approved data fields.
- How revocation or deletion requests propagate to recipients.
- How changes to forwarding configuration are reviewed and monitored.
Disclosure evidence
- Whether notices describe the purposes and relevant recipients.
- Whether consent categories match the actual downstream use.
- Whether the cookie list incorrectly presents a complete picture of tracking.
Audit Tracking Beyond Cookies
Create a clean test state
Observe before consent
Exercise each choice
Connect reads to sends
Follow first-party endpoints
Compare with policy
What Your Consent Tests Should Assert
Storage controls
- Controlled Local Storage, IndexedDB, and Cache Storage remain absent before the required choice.
- Rejected categories do not create or refresh their identifiers.
- Return visits apply the saved choice before controlled code initializes.
Transmission controls
- Controlled pixels, beacons, fetches, frames, and WebSocket connections obey the consent state.
- Cookieless requests are classified and tested explicitly rather than ignored.
- URL identifiers and redirect parameters do not bypass the approved category.
Capability controls
- High-risk browser API access matches an approved purpose and consent state.
- New combinations of device signals trigger review.
- Service-worker behavior and scope remain within the approved baseline.
Downstream controls
- First-party collection endpoints receive only approved fields.
- Consent state travels with events when downstream systems require it.
- Server-side forwarding stops or changes when the visitor withdraws consent.
Common Blind Spots
| Blind spot | Why it fails |
|---|---|
Checking only document.cookie | It misses HttpOnly cookies and every non-cookie mechanism |
Searching only for known vendor domains | First-party collection and new dependencies can hide recipients |
Treating no storage as no tracking | Pixels, beacons, fingerprinting, and event forwarding may not persist state locally |
Clearing cookies between tests | Local Storage, IndexedDB, caches, and service workers can survive |
Reviewing only the first page load | Client-side navigation and delayed events can activate different behavior |
Trusting the cookie policy as the inventory | Documentation can lag behind production code and vendor configuration |
Where SiteWall and CookieWall Fit
SiteWall helps inventory browser resources, providers, capabilities, and network behavior. CookieWall helps connect visitor choices to consent categories and tag behavior. Together with manual and automated testing, these controls can provide a broader view than a cookie table alone.
See More Than the Cookie Table
Use SiteWall to investigate the scripts, browser capabilities, dependencies, and destinations operating across real website sessions.
Frequently Asked Questions
Can a website track visitors without cookies?
Yes. Depending on the implementation, recognition or behavioral data can involve Web Storage, IndexedDB, link identifiers, pixels, beacons, account identifiers, fingerprinting signals, or server-side event forwarding.
Is Local Storage a cookie?
No. Local Storage is a separate origin-scoped key-value mechanism. Its values are not automatically attached to HTTP requests, but scripts can read and transmit them.
Do tracking pixels always set cookies?
No. An image or beacon request can transmit event and page information without writing a new cookie. Existing identifiers may still be included through the URL, request headers, or script-generated payloads.
Is cookieless tracking automatically compliant?
No. Compliance depends on the purpose, data, identifiability, recipients, transparency, legal basis, consent rules, and jurisdiction. The absence of a cookie does not settle those questions.
Does clearing cookies remove every identifier?
No. Other state may remain in Local Storage, IndexedDB, Cache Storage, service workers, application accounts, URLs, or server-side systems. Test and document each relevant mechanism.
How can I detect browser fingerprinting?
Look for scripts collecting many device or browser characteristics, especially when they derive and transmit a stable value. Review purpose and context because individual capability checks can also support legitimate functionality.
Can DevTools reveal server-side tracking?
DevTools can show the browser's request to a first-party collection endpoint, but it cannot reveal every downstream transfer. Review gateway, server, edge, and vendor configuration to complete the data flow.
Follow the Data, Not the Label
Cookies remain an important part of browser privacy testing, but they are one mechanism among many. A complete review connects storage, code execution, browser capabilities, network activity, URL state, and downstream processing.
Expand consent tests beyond the cookie table and verify the actual behavior associated with every visitor choice. That is how teams find the data paths a banner or policy inventory can miss.