A browser can become recognizable without storing a traditional cookie. A site can observe ordinary details such as language, screen size, browser settings, and graphics behavior, then combine them into a browser fingerprint. None of those details is usually enough to identify a person by itself. Together, they can make a browser easier to recognize when it returns, even after its cookies are cleared.
Canvas and WebGL are the clearest examples because they expose small differences in how a device draws a controlled scene. The result is not a secret identity number and it is not a perfect identity check. It is a collection of signals whose value depends on how distinctive they are, how long they remain stable, and what the site combines with them.
A fingerprint becomes useful only after a site combines observations, stores or transmits the result, and compares it with later visits. The privacy risk comes from that full process, not from the mere existence of one browser API.
What a browser fingerprint contains
Browser fingerprinting combines characteristics exposed by a browser, operating system, device, and network context. A site might observe the browser version, time zone, preferred language, display and viewport dimensions, installed fonts, media codecs, touch support, device pixel ratio, and selected settings. The site does not need your name. It needs a set of observations that separates one browser from others.
The World Wide Web Consortium describes fingerprinting as identifying or re-identifying a visiting user, user agent, or device through observable characteristics. Its guidance distinguishes passive signals, which arrive in requests, from active signals, which a script collects on the client. An HTTP header and an IP address are passive. Testing a graphics API is active.
A fingerprint is built from many small observations. A device with a common browser, common screen size, and common language may blend into a large anonymity set. A rare font list or unusual graphics stack can make a browser easier to distinguish. That is why privacy discussions use terms such as uniqueness and linkability instead of treating every fingerprint as a permanent personal identifier.
How Canvas fingerprinting works
The HTML canvas element gives a page a drawing surface. JavaScript can draw text, shapes, gradients, and other objects, then read the resulting pixels. Rendering can vary with the browser engine, operating system, font rasterization, graphics driver, color handling, and hardware acceleration path. A script can derive a short hash from those pixels and send the value to a server.
The site does not have to keep the entire picture. A derived value is enough to compare one rendering with another. Small differences can help distinguish browsers when they are combined with other observations, but a canvas hash is not a password or identity document. It can change after a browser update, a font change, a graphics setting change, or a move to another device.
Canvas also has ordinary jobs. Websites use it for charts, editors, games, signatures, maps, and image tools. Canvas code alone does not prove tracking. The privacy question is whether the page exports the result, combines it with other identifiers, and explains that collection clearly.
Some browsers restrict or alter canvas readback in privacy-sensitive contexts. They may add noise, require permission, or standardize output so more users look alike. Those defenses can reduce a fingerprint's value, while also affecting applications that need pixel-accurate output. Blocking every canvas read would break legitimate pages, so browsers use a mix of controls.
How WebGL fingerprinting works
WebGL is a JavaScript API for accelerated two- and three-dimensional graphics inside a canvas. It lets a page use a graphics processor through a web-safe interface, which is why it powers games, maps, product previews, and data visualizations. The same graphics path can reveal characteristics that differ between devices.
A page can query supported features, limits, extensions, shader behavior, and rendering output. In some contexts, the WEBGL_debug_renderer_info extension can expose vendor and renderer strings describing a graphics driver or GPU family. Browser privacy settings can restrict the extension. Firefox disables it when its resist fingerprinting preference is enabled.
WebGL output is not a universal device serial number. Driver updates, browser changes, virtual machines, remote desktops, and privacy protections can change what a site sees. The signal becomes more useful when paired with screen dimensions or user agent details. The privacy concern comes from the combined surface, not from one API call.
Other signals used in browser fingerprinting
Canvas and WebGL are only two sources. A site may observe the user agent, language, time zone, screen and viewport sizes, device pixel ratio, touch capabilities, supported features, audio behavior, media codecs, WebRTC behavior, CSS features, or timing characteristics. Font detection has also been studied because unusual fonts can narrow the set of possible devices.
Passive signals arrive with normal network requests. The IP address, HTTP headers, and connection characteristics add context before JavaScript runs. Active signals come from scripts that query APIs or measure browser behavior. Cookie-like techniques use local state that survives across sessions. A service may combine any of these signals with an account login or another identifier.
The same collection can serve different purposes. A fingerprint may help a security team spot a suspicious change between logins, identify automated traffic, or support fraud prevention. Those uses do not remove the privacy concern. The combined record can correlate visits across sessions or sites, so purpose, retention, sharing, and access rules matter as much as collection.
Why clearing cookies does not clear a fingerprint
Cookies are a storage mechanism. Fingerprinting is an observation method. Clearing cookies removes one form of local state, but it does not make your browser look like every other browser. A site can run the same tests again and compare a new result with an earlier record.
Fingerprinting also differs from an IP address. An IP address may change when you switch networks, while a fingerprint can remain similar. A VPN can hide the network address, but it does not normalize fonts, screen settings, JavaScript behavior, or graphics output. The W3C notes that onion routing can limit network-level linkability while web fingerprinting remains possible.
That does not mean a fingerprint always follows one person. Shared computers, browser updates, privacy settings, and changing networks can make records ambiguous. A fingerprint is a probability signal, not proof. Services should not treat it as the sole basis for decisions that affect people.
How browsers reduce fingerprinting
Browser defenses follow two ideas: expose less detail, or make many browsers look more alike. A browser can disable a high-entropy feature, standardize a value, round a measurement, or add controlled variation. It can also isolate state by site so one origin cannot reuse another origin's data.
Tor Browser tries to make users blend into a larger group by standardizing common browser characteristics. Firefox includes a resist fingerprinting preference that changes or limits several signals. Other browsers use tracking protection, partitioned storage, permission prompts, or anti-fingerprinting interventions. No setting erases every signal, and aggressive changes can make a browser unusual in a different way.
Extensions that block scripts can reduce active tests, but they may break site functions. Private windows remove local history and session state when closed, yet they do not promise a unique or invisible fingerprint. The practical goal is to reduce unnecessary exposure while keeping the browser stable and common enough to avoid becoming an obvious outlier.
Practical ways to reduce fingerprinting
Start with built-in privacy controls. Keep the browser current, review site permissions, and use tracking protection where available. Avoid installing many extensions with overlapping access because extensions can change browser behavior and add their own data practices. If you use a privacy-focused configuration, keep it consistent instead of changing rare settings that make the profile more distinctive.
You can test a setup with a reputable tool such as the Electronic Frontier Foundation's Cover Your Tracks. Treat the result as a snapshot, not a guarantee. It can show which information a site may observe, including canvas and WebGL hashes, but it cannot tell you how every site will use those signals.
Separate browser profiles or devices can limit mixing between work, personal accounts, and sensitive research. That does not make either profile anonymous. A privacy tool should explain what it blocks, what it changes, and what data it sends. Claims that a product makes you completely anonymous deserve skepticism.
How websites should limit fingerprinting
Developers can reduce risk by asking only for data a feature needs. If a page needs canvas for drawing, it does not automatically need to export a canvas hash. Avoid detailed hardware or font data when a coarser capability check works. Document fingerprinting surfaces in privacy notices, provide controls where practical, and set retention limits.
Security teams should test whether a fingerprint is being used as a hidden identifier. If a service combines it with an account, IP history, or third-party analytics, the combined profile can be more sensitive than any field. Restrict access, protect the data like other user information, and avoid high-impact decisions based on a probabilistic signal alone.
