Browser fingerprinting: what sites can infer

Published: 2026-09-05

How sites combine canvas, WebGL, audio, fonts, screen, User-Agent, and WebRTC signals into a trackable fingerprint—and how to audit those exposures locally without uploading a report.

Browser fingerprinting is the practice of collecting many small, stable traits from your browser and device, then combining them into an identifier that often survives cookie clears and private windows. No single signal is unique on its own; the power is in the combination. A site that never sets a tracking cookie can still recognize “this looks like the same machine as last week” if enough vectors match.

This guide explains what those vectors are, what they can and cannot prove, and how to inspect them in your own tab—the same privacy model as other local-only developer tools.

Fingerprinting vs cookies vs login

Mechanism	What it stores	Survives cookie clear?
First-party cookies / storage	Site-chosen IDs	No (for that origin)
Third-party cookies	Cross-site IDs (increasingly blocked)	No when cleared / blocked
Login / account	Explicit identity	N/A — you are authenticated
Fingerprinting	Inferred device/browser traits	Often yes — traits live in the browser/OS

Fingerprinting is probabilistic. Two identical corporate laptops with the same image may collide; a heavily customized desktop with rare fonts and a distinct GPU may stand out. Treat fingerprint hashes as “likely same browser config,” not courtroom proof of a person.

Signal categories sites commonly read

Hardware and software

JavaScript can ask for coarse hardware hints and software identity:

User-Agent — browser family, OS hints, sometimes version. Easy to spoof; still widely used as a weak feature. For breaking the string into browser/OS/bot signals, see User-Agent Parser.
CPU cores (navigator.hardwareConcurrency) and device memory (navigator.deviceMemory) — buckets, not serial numbers, but they shrink the anonymity set.
GPU vendor / renderer via WebGL (especially with WEBGL_debug_renderer_info) — often the strongest “hardware” clue on desktops.
Timezone and languages — narrow you to a region and locale preference.
PDF viewer / plugin hints — another small bit in the feature vector.

None of these require cookies. They are available to almost any script that runs in the page.

Canvas, WebGL, and audio fingerprints

These techniques draw or synthesize something, then hash the output. Tiny differences in GPU drivers, anti-aliasing, fonts, and audio stacks make the hash differ across machines:

Vector	Idea
Canvas 2D	Draw text/shapes → `toDataURL()` → hash
WebGL	Combine unmasked vendor/renderer and capability limits → hash
AudioContext	Render a short oscillator + compressor offline → hash samples

The hash is not your name. It is a compact stand-in for “this graphics/audio stack behaves like X.” Trackers store that hash (or a larger composite ID) server-side and look for repeats.

Fonts and screen

Sites probe whether named fonts are installed by measuring text width against fallback families. A longer installed-font list (especially uncommon typefaces) increases uniqueness. Screen size, color depth, device pixel ratio, and available viewport size add more bits—especially on unusual monitor setups.

Network and WebRTC

WebRTC can gather ICE candidates. Depending on browser settings and STUN usage, candidates may include LAN addresses (e.g. 192.168.x.x or 10.x.x.x). That is not a full public IP fingerprint by itself, but it is a privacy leak: a page learns something about your local network topology without asking for geolocation permission.

Do Not Track headers exist but are rarely honored as a hard stop; treat them as a preference signal, not a shield.

What a “privacy score” means (and does not)

Heuristic auditors assign penalties when high-risk vectors are present: WebRTC LAN hints, many detectable fonts, successful canvas/WebGL/audio hashes, and so on. A higher score usually means “fewer of those signals showed up in this scan,” not “you are anonymous on the web.”

Scores do not:

Prove a tracker cannot identify you by other means (accounts, IP reputation, TLS fingerprints outside the page, extensions).
Guarantee two scans will match forever—browser updates, GPU drivers, and zoom levels change hashes.
Replace threat modeling for your threat model (casual ads vs targeted adversaries).

Use them as a checklist and teaching aid: see what this page can read, then change settings or extensions and re-scan.

Why audit locally

Online “fingerprint checkers” often compute the same APIs—and then upload the report so they can demo uniqueness across visitors. That turns a privacy lesson into a data collection event.

A browser-only auditor runs canvas, WebGL, audio, font probes, and optional WebRTC ICE collection in your tab and shows the results to you. On LocalTools, audit results are not sent to the site for processing. Note that WebRTC probing may briefly contact a public STUN server to obtain ICE candidates; that is a network side channel for candidate discovery, separate from uploading a fingerprint report. See also the site Privacy Policy.

Try it on LocalTools

Open the Browser Fingerprint & Privacy Auditor:

Review the privacy score and estimated identifiable data points (higher score is better in this tool’s heuristic).
Inspect hardware & software, network & privacy leaks (including WebRTC / ICE), and fingerprint vectors (canvas, WebGL, audio, screen, fonts).
Change a privacy extension, VPN, or browser setting, then Re-scan to compare.

Nothing in the audit report is uploaded by the tool for storage or cross-user uniqueness scoring.