Community Article
Community articles are authored by SitePoint Premium contributors. Content is screened before publication, and SitePoint reserves the right to moderate or remove articles that violate our guidelines. Views expressed are those of the authors and do not necessarily reflect those of SitePoint.
Browser Fingerprinting Explained: How Websites Identify You and How Developers Can Reduce It
DJDiv JohnPublished inSecurity·Browsers·
October 26, 2026
·Updated:October 26, 2026
The AI briefing for Developers
Stay up to date with AI tools, model releases, and developer workflows that matter.
Weekly. Free. One click to leave.
SitePoint Premium
Stay Relevant and Grow Your Career in Tech
- Premium Results
- Publish articles on SitePoint
- Daily curated jobs
- Learning Paths
- Discounts to dev tools
7 Day Free Trial. Cancel Anytime.
You clear your cookies, open a private window, and visit a site again. It still knows you.
Nothing is wrong with your browser settings. What you’re seeing is browser fingerprinting. A site quietly gathers small details about your device, like your screen size, your fonts, and how your graphics card draws text, and puts them together. On their own, those details tell it very little. Combined, they often point to one person. And none of it needs a cookie.
Most articles on this topic stop at the scary part. This one is written for people who build websites, so we’ll go a bit further: what goes into a fingerprint, what the collection code actually looks like, and what you can change in your own projects.
What goes into a fingerprint
Think of a fingerprint as a stack of clues rather than a single value. Your time zone is shared by millions of people. So is your screen resolution. Put twenty clues like that together, though, and the crowd shrinks fast.
Here’s roughly where the clues come from.
HTTP headers. Before any JavaScript runs, every request already tells the server a lot. The User-Agent string and the Accept-Language header give away your browser, its version, your OS, and your languages. Chromium browsers also send Client Hints.
JavaScript APIs. Plenty of everyday APIs leak device details. screen.width and screen.height, navigator.hardwareConcurrency (your CPU core count), navigator.deviceMemory (Chromium only), navigator.platform, and your time zone all add something. Plugin lists used to be a goldmine, but modern browsers now return a fixed, generic list, so that one’s mostly dead.
Rendering. This is the clever bit. Ask two computers to draw the exact same text, and the pixels won’t match perfectly. Fonts, graphics drivers, and the GPU itself all nudge the output slightly. Same browser, same version, different hardware, different result.
Network details. Your IP address, connection type, and even the way your browser sets up a TLS connection can help. IPs change, so these clues are less reliable. Trackers mostly use them to back up a match they already suspect.
How unique does this make you? Back in 2010, the EFF’s Panopticlick study tested around 470,000 browsers and found that about 84% of them had a unique fingerprint. (The project still exists, now called Cover Your Tracks.) Later studies with bigger samples found lower numbers, especially on phones, since a lot of phones share near-identical hardware. The percentages move around, but the basic idea hasn’t changed.
What the code looks like
Canvas fingerprinting gets talked about the most. Here’s a basic version:
functioncanvasFingerprint(){const canvas =document.createElement('canvas');const ctx = canvas.getContext('2d');ctx.textBaseline='top';ctx.font='14px "Arial"';ctx.fillStyle='#f60';ctx.fillRect(0,0,100,30);ctx.fillStyle='#069';ctx.fillText('Browser fingerprint',2,15);return canvas.toDataURL();}Read through it and you’d never guess it was tracking code. It draws an orange box, writes some text, and exports the image. The catch is that anti-aliasing and subpixel rendering vary from device to device, so that exported string varies too.
The data URL is long and clunky, so trackers usually hash it into something shorter. With the Web Crypto API, that’s a few extra lines:
asyncfunctionhashString(str){const data =newTextEncoder().encode(str);const digest =await crypto.subtle.digest('SHA-256', data);returnArray.from(newUint8Array(digest)).map((b)=> b.toString(16).padStart(2,'0')).join('');}const fingerprint =awaithashString(canvasFingerprint());Now there’s a short ID that comes back the same on every visit, cookies or no cookies. One small note if you test this yourself: crypto.subtle only runs on HTTPS or localhost.
WebGL fingerprinting follows the same idea with 3D graphics. A script draws a hidden scene and also reads the WEBGL_debug_renderer_info extension, which can reveal your GPU’s make and model. Audio fingerprinting is sneakier. The script generates a sound, runs it through an AudioContext, and hashes the result. Different audio stacks produce slightly different numbers.
It’s worth remembering that the Canvas API, WebGL, and the Web Audio API were built for charts, games, and music apps. Tracking is a side effect of how much they expose. The W3C’s guidance on mitigating fingerprinting in web specifications covers how standards authors try to avoid adding new signals.
Why this matters if you build websites
You might not write a single line of fingerprinting code yourself and still end up involved. There are three common ways that happens.
Your security tools might already do it. Bot detection, fraud prevention, and “new login from an unknown device” alerts often run on fingerprinting libraries. That’s a fair use case. Just know that the law usually sees it as data collection. In the EU, the ePrivacy rules generally require consent before you read this kind of information from someone’s device. Several US states treat fingerprints as personal information, which means disclosure and opt-out rights.
Your third-party scripts can do it without asking you. Analytics tags, ad scripts, chat widgets, social buttons. Each of them can call the same APIs your own code can. If your page loads fifteen of them, that’s fifteen possible fingerprinters. Checking what each script does has quietly become part of the job.
Browsers are closing the door. Chrome froze most of the User-Agent string and moved detailed info into Client Hints. Safari has Advanced Fingerprinting Protection. Firefox blocks known fingerprinting scripts, and Brave randomizes values returned by fingerprintable APIs. If your site depends on the old, wide-open APIs, you’re building on ground that’s shrinking every release.
How to reduce fingerprinting in your own projects
Most of this comes down to one rule: collect less, and know why you’re collecting what’s left.
1. Remove signals you don’t need
Search your codebase for the high-entropy stuff: canvas exports, WebGL renderer lookups, font detection, and calls to navigator.userAgentData.getHighEntropyValues(). If a feature still works without them, take them out.
In many teams, the biggest win is boring. Someone added a fingerprinting library years ago for one fraud check, nobody reviewed it since, and it’s still loading on every page. Deleting it helps more than any clever fix.
2. Switch from User-Agent parsing to Client Hints
The classic User-Agent string packs browser, exact version, OS, and CPU architecture into one header. Client Hints break that apart so you only get what you ask for.
Accept-CH:Sec-CH-UA-Platform-VersionSkip full version numbers, architecture, and device model unless you have a real reason. Each extra hint makes your visitors a little easier to tell apart.
Keep in mind that only Chromium-based browsers support User-Agent Client Hints. Firefox and Safari won’t send them, so you’ll need a fallback. Where you can, feature detection beats browser detection anyway.
3. Control what third-party code can reach
Here’s an uncomfortable truth: once a script runs on your page, it can call canvas, WebGL, and audio APIs, and there’s no header that switches those off. What you can control is which scripts run and how close they get to your page.
- Put widgets in sandboxed cross-origin iframes instead of dropping their scripts straight into your page.
- Use a Content-Security-Policy that only allows scripts you’ve actually reviewed.
- Add a Permissions-Policy that turns off features you don’t use, so embedded content can’t ask for them.
Permissions-Policy: camera=(), microphone=(), geolocation=()None of these is a silver bullet. Together, they cut down how much code gets the chance to fingerprint your users at all.
4. Watch what you render
If your app draws on canvas (dashboards, editors, browser games), that output can be fingerprinted too. Try not to hand raw canvas data to third-party scripts.
Fonts count as well. Load fifteen unusual web fonts and you’ve given every script on the page an easy font fingerprint. A system font stack blends in better, and for interface text, most users won’t notice the difference.
5. Handle stored fingerprints like personal data
Sometimes you’ll want to keep a fingerprint, for example to flag logins from a device you haven’t seen before. That’s fine, as long as you treat it with care:
- Store a hash, not the raw signals.
- Remember that a hash still counts as pseudonymous personal data, so privacy rules still apply.
- Keep it for a short time.
- Mention it in your privacy policy.
- Give users a way to reset it.
And please don’t write “we don’t use cookies” in your privacy policy if you fingerprint instead. Users and regulators are wise to that one.
6. Test in privacy-focused browsers
Before you ship, open your site in Firefox with Enhanced Tracking Protection set to Strict, and in Brave with fingerprinting protection turned on. If something breaks, it was relying on a signal browsers are trying to get rid of.
Fix the feature. Don’t ask users to turn their protection down. Browsers are only going to get stricter from here.
What users can do, and what doesn’t really help
A lot of common privacy advice misses the mark on fingerprinting, so it’s worth clearing up.
A VPN changes your IP address, but your canvas output, fonts, and screen size look exactly the same to the site. So it does very little against fingerprinting. Clearing cookies doesn’t help either, because there’s no cookie involved. Private windows help a bit in some browsers, but in most of them, the fingerprint barely changes.
What works better is a browser with fingerprinting protection built in, such as Brave, Firefox on strict settings, Safari, or Tor Browser. These either add noise to the signals or make everyone look the same. Extensions that block canvas and font reads can help too. So can simply updating your browser, since each release tends to remove a few more leaky details.
If you want to point non-technical readers somewhere for a plain-English breakdown of which privacy tools actually help against tracking, and which ones just hide your IP, the guides from the VPNOverview team are a good place to start.
No single tool will stop fingerprinting completely. The good news is that it doesn’t have to. Fingerprinting works on probabilities, so making the signals noisier is often enough to break the match.
Checklist for your next project
- Review every third-party script and note which fingerprinting APIs it can reach.
- Replace User-Agent parsing with Client Hints and feature detection. Ask only for what you need.
- Sandbox widgets in iframes, use a strict CSP, and set a Permissions-Policy for features you don’t use.
- If you store fingerprints for security, hash them, set a retention limit, and disclose it.
- Test in Firefox Strict and Brave before every release.
- Repeat the audit every six months or so. Browsers keep removing signals, and libraries keep adding new ones.
Fingerprinting exists because the web gives scripts a lot of information about the device they’re running on. There isn’t one header or API that fixes it. What helps is a habit: collect as little as you can, have a reason for everything you keep, and assume anything you expose could be used to identify someone. Your users get better privacy, and you get fewer nasty surprises when the next browser update takes away something your code was quietly relying on.
