Fingerprinting scripts present
We surface when fingerprinting libraries or custom fingerprinting routines appear in your request chain.
Educational Demonstration
Most people have heard that third-party cookies are being phased out. In practice, the transition is uneven and slow across browsers and ecosystems. Meanwhile, many vendors combine browser and device fragments into persistent identifiers.
This page shows how those fragments can be assembled into a fingerprint. Then it shows how Lokker helps site owners identify when fingerprinting techniques are running on their pages, often through third parties they did not fully audit.
Typical fingerprint inputs
We surface when fingerprinting libraries or custom fingerprinting routines appear in your request chain.
We map parent-child request relationships so you can see whether a first party, tag manager, or third-party vendor introduced the behavior.
Some fingerprinting can support fraud prevention or bot defense. We focus on where behavior, disclosure, and consent expectations are misaligned.
Before you start
This is an educational simulation. The page does not start signal collection until you choose to run it. We do not transmit your generated fingerprint to any external system, and we do not persist it in local storage.
Click Start local demo to collect browser/device fragments and produce a simulated fingerprint hash in-browser.
No network calls. No storage. No export.
Why this matters
Even when users do not knowingly accept all tracking, fingerprint-style profiling can still emerge from ambient browser signals. That is why consent banners alone are not enough.
Privacy teams need to observe what actually leaves the browser, validate opt-out and GPC behavior, and continuously monitor third-party changes over time.
Legitimate vs risky usage
From demo to action
Lokker helps teams measure real request behavior, validate consent controls, and reduce privacy exposure across portfolios of sites.