What is a browser fingerprint? What it records about you

What a browser fingerprint actually is

A browser fingerprint is the combination of device and environment characteristics a web page reads through JavaScript. Any single value looks unremarkable on its own — plenty of people run a 1920x1080 screen — but combine twenty or thirty of them and the odds of an exact match drop far enough to identify you reliably among millions of users.

The fundamental difference from cookies: a cookie is data a site **writes** into your browser, which you can delete or refuse. A fingerprint is a set of traits the site **reads** from your browser, and you cannot delete your graphics card model or the fonts installed on your system.

The technique started out in fraud prevention — a bank needs to know whether a device has signed in before. The same technique is now widely used for ad tracking and for deciding whether two accounts belong to the same person.

What it records

Collection goes wider than most people assume. The signals fall into four layers, and the deeper the layer, the more stable it is, the harder it is to change, and the more weight it carries in identification.

• Hardware: GPU model and driver version, logical CPU core count, device memory, screen resolution and colour depth, max touch points
• System: operating system and version, timezone, system language, installed font list (highly distinctive), battery status
• Browser: User-Agent, browser version, supported plugins and MIME types, Do Not Track setting, whether cookies are enabled
• Rendering: hash of Canvas drawing output, WebGL rendering traits and supported extensions, floating-point differences in AudioContext processing
• Network: exit IP, local and public addresses exposed via WebRTC, TLS handshake characteristics (JA3/JA4)

Why Canvas and WebGL matter so much

Canvas fingerprinting works like this: the page asks your browser to draw a specific shape or piece of text off-screen, then hashes the resulting image. Given identical drawing instructions, different graphics cards, driver versions and anti-aliasing settings produce pixel differences invisible to the eye — and those differences are consistent enough to form a stable identifier.

WebGL goes further, exposing the GPU model, driver version and the list of supported extensions outright. What both have in common is that their output is determined by hardware. Clearing browser data does not change them, and neither does switching to a different browser.

Why reinstalling the browser does not help

Reinstalling clears the browser's own data directory — cookies, cache, history, extensions. But the highest-weight parts of your fingerprint were never in that directory to begin with.

Your graphics card is the same card, your system fonts are the same fonts, and your screen resolution and timezone have not moved. After a reinstall, the Canvas hash, WebGL parameters and font list a page reads are exactly the values it read before.

Why incognito mode does not help

This is the most widely misunderstood one. Incognito mode does exactly one thing: data generated during the session — cookies, history, form entries — is not written to disk when you close the window.

It does nothing to stop a page from reading device characteristics. Visit a page in an incognito window and it still reads your GPU model, font list, timezone and resolution, and the values are identical to those from a normal window.

Put differently, incognito protects against leaving traces on your own machine, not against being recognised by the other side. Those two things get conflated constantly.

Why multiple Chrome profiles do not work either

Chrome profiles and guest mode isolate cookies and login state, and at that layer they genuinely work. But they all run on the same browser process model, the same operating system and the same graphics card.

The result: two Chrome profiles have completely separate cookies and near-identical fingerprints. To a platform, that reads as two accounts on one device — not a single signal has been removed.

Installing several different browsers (Chrome plus Firefox plus Edge) helps slightly, since the User-Agent and some implementation details differ, but the hardware and system layers stay identical. And the approach does not scale — you run out of browsers after three or four accounts.

What actually works

Since a fingerprint is a set of traits that get read, the effective approach is not cleaning up afterwards but giving every account its own independent, internally consistent environment from the start.

NexBrowser configures these parameters at the Chrome engine level rather than having an extension rewrite return values on the page. That distinction matters: extension-based approaches patch the return values of JavaScript interfaces, and detection scripts can spot the patching through call stacks and timing. Engine-level configuration returns a complete set of values at the source.

• 20+ fingerprint parameters configured per profile, covering Canvas, WebGL, fonts, AudioContext, timezone, language and hardware traits
• Parameters stay internally consistent — you never get contradictions like a device claiming to be an iPhone with 32 CPU cores
• Each profile has its own cookies, cache and local storage, with no cross-reading
• Each profile binds its own proxy, with timezone and language aligned to the exit region automatically
• WebRTC behaviour is configured per profile so it cannot bypass the proxy and expose your real address
• Built-in parameter templates covering Windows, macOS, Android and iOS

How to check your own fingerprint

To see what you are currently exposing, run a check with NexScan. It reads your browser's fingerprint parameters and produces an environment authenticity report covering exit IP, system and hardware details, Canvas and WebGL rendering traits, and whether DNS or WebRTC are leaking.

When reading the report, the point is not to chase some uniqueness score. Confirm three things instead: that each value matches what you expect, that no two values contradict each other (an IP in Germany paired with a UTC+8 timezone, say), and that WebRTC is not leaking an address outside your proxy.

A common mistake is assuming the more outlandish the values, the safer you are. The opposite holds. A parameter combination that has never existed in the real world is itself a glaring anomaly. The goal is to look like a device that plausibly exists, not to be unique.

Frequently asked questions