Five things your browser sends to every website you visit (and how to stop them)

Open a fresh browser tab, type a URL, and press enter. Before the first byte of the page even renders, your browser has already had a short, one-sided conversation with the site's server. It has named itself, listed the languages you read, mentioned which compression formats it understands, and admitted where you are connecting from. After the page starts running JavaScript, the conversation gets richer: the site can ask the browser to draw a small invisible image, play a silent audio tone, enumerate the fonts you have installed, and read out the exact model of your GPU. None of this requires a cookie. None of it asks for your permission.

The combined effect is something the privacy community calls a browser fingerprint: a set of signals that, taken together, can pick out an individual visitor across sites and across sessions, even after they have cleared cookies, signed out of accounts, and switched IP addresses. It is not theoretical. The EFF's Cover Your Tracks project has been demonstrating it publicly since 2010, and the technique is used in production by both the fraud-prevention industry (where it is sold as "device identification") and the advertising industry (where it is sold as "cookieless attribution").

Below: the five biggest things a typical browser sends, what each one reveals, why they work as a tracking signal, and the actual settings and tools that shrink the surface. Where a setting trades off something useful, we say so.

1. Your IP address

Every connection to a server includes the IP address the connection came from. This is unavoidable: without it, the server has nowhere to send the response. Your IP is the only signal in this list that exists at the network layer rather than inside the browser, which is why it leaks before any JavaScript runs.

What an IP reveals, with reasonable accuracy:

• Country, region, and often city. Commercial IP-geolocation databases are accurate to the city in most populated areas.
• Your internet service provider. The IP block is allocated to a specific ISP, which is often visible by name.
• The kind of network - home broadband, mobile carrier, corporate, hosting provider, VPN. The same database that tells the site your city tells it whether you are coming from a known VPN exit node.
• Stability over time. Home IPs in many countries change rarely - sometimes every few months, sometimes never. Mobile IPs change more often but still cluster around a handful of carrier-grade-NAT pools.

What shrinks it: a VPN replaces your IP with the VPN exit's IP. Tor replaces it with a Tor exit node, in a different country, that rotates per circuit. A mobile hotspot puts you on a carrier-NAT IP shared with many other people. None of these change the four other signals in this article.

Trade-off: some sites block known VPN and Tor exits outright (banks, streaming services), some show extra captchas, and a few break because the IP geolocation no longer matches the account's stated country. A VPN buys network-layer privacy at the cost of some friction - and at the cost of trusting the VPN provider not to do exactly what your ISP was doing. We have a longer piece on what a VPN actually hides, what it does not, and when Tor is the right tool if you want the full picture before paying for one.

2. Your User-Agent and the modern Client Hints

The User-Agent header is the second-oldest tracking signal on the web, after the IP. It was supposed to be a short label so servers could tell browsers apart for compatibility (Mozilla/5.0, Chrome version, OS version). Over time it became a long, gummed-together string that names your browser, its version, your operating system, your CPU architecture, your phone model on mobile, and sometimes your specific build of WebView.

Recent Chromium versions are slowly replacing User-Agent with User-Agent Client Hints - separate headers like Sec-CH-UA, Sec-CH-UA-Platform, and Sec-CH-UA-Model. The shape is cleaner, the privacy property is not much better: the same information goes to any server that asks for it (and almost all do). Curious what your browser is sending? Our user-agent inspector shows you the live values without making them leave the page.

What a User-Agent reveals:

• Browser family and exact version.
• Operating system, OS version, and CPU architecture.
• On mobile, often the specific device model.
• Whether you are using a WebView inside another app (Facebook, Instagram, Slack), which is a useful signal for ad-tech because it correlates with platform.

On its own, your User-Agent is not unique enough to identify you - millions of people use the same Chrome version on the same OS. Combined with the other signals below, it narrows the field hard.

What shrinks it: Tor Browser ships a deliberately uniform User-Agent for every user. Firefox with privacy.resistFingerprinting enabled does the same. Browsers like Brave randomise some of the values per session. Spoofing the User-Agent via an extension is usually worse than leaving it alone, because the spoof often disagrees with other signals the browser still leaks (the Sec-CH-UA-Platform header, JavaScript's navigator.platform), which is itself a fingerprint.

Trade-off: "resist fingerprinting" modes occasionally break sites that key behavior off the User-Agent. The breakage is rare in 2026 and worth living with.

3. Your fonts, GPU, and rendering quirks (the canvas and WebGL signals)

This is the cluster of signals most people are surprised by, because it does not feel like data the browser should be giving out. It is also, by some distance, the most powerful fingerprint on a typical desktop.

The technique is simple. A site asks JavaScript to draw a small image to an invisible <canvas> element using a specific font and a few graphic primitives. It then reads the pixels back out. Two visitors with slightly different fonts, GPUs, GPU drivers, OS antialiasing settings, or browser versions will produce subtly different pixels - different by only a few bits per pixel, but consistently different. The hash of those pixels becomes a per-device ID.

WebGL is the same idea, harder. A site renders a small 3D scene with specific shaders, reads the result, and includes the WebGL renderer string (which names your GPU, sometimes down to the driver version). Audio fingerprinting plays a silent oscillator through the Web Audio API and hashes the resulting waveform; the result depends on the audio stack and floating-point implementation.

Layered on top: the list of fonts you have installed (probeable by measuring the width of text rendered in a specific font and comparing to the fallback), the list of supported MIME types, the list of plugins (smaller than it used to be), and the exact list of installed extensions (probeable in some cases through web-accessible resources).

Why this is so strong: the underlying signals come from the intersection of your OS, GPU, drivers, browser version, and font set. On a desktop running a non-default combination, the fingerprint is often unique among everyone the site has ever seen. The seminal paper here is Mowery and Shacham's Pixel Perfect from 2012; the EFF's Panopticlick / Cover Your Tracks project has been running the experiment on real visitors for over a decade. The result has not changed: a typical desktop browser is uniquely identifiable from these signals alone.

What shrinks it:

• Firefox with privacy.resistFingerprinting blocks or randomises canvas reads, returns a uniform list of fonts, and clamps a number of related APIs. Set it in about:config.
• Tor Browser does all of the above, plus blocks WebGL and a number of other APIs by default. It is the strongest mainstream option.
• Brave ships farbling: it adds small per-site random noise to canvas, audio, and WebGL outputs, so the hash is unstable across sites. Cheaper performance cost than full blocking.
• uBlock Origin blocks many of the JavaScript fingerprinting scripts at the network layer, which is a different mitigation: the site cannot run the test in the first place. Worth enabling in addition to the browser-level protections.

What does not help much: ad-hoc canvas-spoofing extensions. They often add noise that is itself distinctive, and they fail to spoof the other signals (font list, WebGL renderer) consistently. The cluster has to be addressed together.

4. Your screen, your time zone, and your language

Three smaller signals that combine more powerfully than any of them deserves.

Screen. JavaScript can read your screen's pixel dimensions, the size of the browser window, the device pixel ratio, the available color depth, and the size of the area not occupied by the OS taskbar. On a desktop with a non-default monitor configuration (an external 4K display at a specific scale factor), this is more unique than people expect.

Time zone and clock. The site can read your IANA time-zone identifier (Europe/Copenhagen, America/Los_Angeles), the current offset including daylight-saving state, and indirectly your system clock. The time zone often disagrees with the IP geolocation in useful ways for trackers: a Copenhagen time zone on a Frankfurt VPN exit narrows the user pool considerably.

Language. The Accept-Language HTTP header sends the list of languages you have configured, in priority order, with per-language quality weights. JavaScript also exposes navigator.languages. A multilingual user with a specific ordering (Danish first, then English, then German, with specific regional sub-tags) is rare in a way that matters.

Other small signals that ride along: whether you prefer dark mode, whether you prefer reduced motion, whether you have "Do Not Track" enabled (yes, the DNT signal itself is a fingerprint), the result of a "battery status" query on some browsers, the orientation lock state on mobile, and on permissive browsers the list of MIDI and Bluetooth devices.

What shrinks it:

• Firefox's resistFingerprinting rounds the window size to standard buckets, normalises the time zone to UTC for scripts, and reduces the screen API's precision. It also overrides Accept-Language to a single value.
• Use the default window size where possible. Resizing the window every time you open a tab is itself a signal. Tor Browser opens at a uniform size and discourages resizing.
• Configure a short, common language list. "English (US), English" is more common than "Danish, English (UK), German, French." The right answer is to set whatever you actually read.

Trade-off: spoofing the time zone breaks calendars and anything that converts times for you, and forcing a uniform language list means sites stop respecting your real preferences. resistFingerprinting leans toward "uniform" rather than "accurate," and it does inconvenience some sites.

5. The hundred small things: APIs, headers, and storage

The fifth signal is not one signal - it is the long tail. Modern browsers expose dozens of small APIs and headers that each leak a little. Stacked, they make the four signals above narrower.

• Referer - the page you came from. Often the previous search query, in cleartext.
• Sec-Fetch-* headers - whether this request was a top-level navigation, a fetch from a script, an image load, and so on.
• Accept and Accept-Encoding - which response formats and compression methods the browser supports. The exact list and order varies by browser version.
• The Network Information API - your effective connection type (4G, wifi) and a coarse downlink estimate on some browsers.
• Storage signatures - whether localStorage, sessionStorage, IndexedDB, the Cache API, and several other persistence mechanisms work. Private modes disable some of these in detectable ways.
• The list of supported codecs for video and audio, which subtly varies between Chrome on Linux, Chrome on macOS, and Chrome on Windows.
• The Performance APIs - high-resolution timers can be used to fingerprint your CPU's exact behavior. Most browsers now clamp the precision, but only most.
• The exact order of HTTP headers. Even with identical headers, the order is consistent within a browser version and visible to the server. Several anti-bot vendors use this signal directly.

Cookies are not on this list because they are an identifier rather than a fingerprint - they only work after the site has set one. Third-party cookies are also on the way out across major browsers, which is part of why the fingerprinting techniques above have become more important to the tracking industry: they are the cookieless fallback.

What shrinks it: a privacy-focused browser configuration (Firefox with resistFingerprinting, Brave, or Tor) deals with most of these in one pass. A network-layer blocker like uBlock Origin handles the rest by preventing the tracking scripts from running. Browser-extension fingerprinting can be limited by keeping a small, common extension set; installing a long tail of niche extensions is itself a signal.

What we cannot fix here, and what we can

Two honest notes.

First, on a desktop, you are probably already identifiable. The Cover Your Tracks project's running result has been the same for years: a typical desktop browser is unique among the visitors the site has ever seen, because the combination of OS, GPU, font set, browser version, and the long tail above is rare even for popular configurations. Mobile is a little better because the device population is more uniform. The realistic goal is not "be anonymous" but "make the data collected about you less useful."

Second, the same signals are used by both the parties you want to defend against and the parties you might genuinely want help from. Banks fingerprint your device to detect stolen-card transactions; brokerages do it to spot account takeover. If you turn every protection up to the maximum, expect to see more captchas and the occasional "we don't recognize this device" prompt. Most browsers offer per-site exceptions precisely for this case.

What we can fix is the second-order leak: every time you upload a file to a website to do something to it, you are adding the file - and whatever it contains - to the long list of signals the operator and the infrastructure between you both see. A photo's GPS coordinates, a PDF's author name, an audio file's recording app - all of that is in the file. The argument for local-first tools, and for the rest of Privvert's toolkit, is that the most reliable way to keep something private is to not send it in the first place. The same logic that makes browser fingerprinting hard to escape is the reason file privacy has to be solved on your side of the wire.

A short, practical configuration

If you do nothing else this week, do these four things:

1. Install uBlock Origin in your default browser. It blocks most of the JavaScript fingerprinting scripts at the source.
2. In Firefox, open about:config and set privacy.resistFingerprinting to true. Expect one or two sites to behave oddly; whitelist them per-site.
3. Use Tor Browser for browsing where the consequence of being identified is serious - research, journalism, anything you would not want associated with your real identity in a database.
4. Audit what you upload. Strip EXIF from photos, strip metadata from PDFs before sending, and prefer tools that do the work in your browser instead of on someone else's server.

Behind the scenes, the right reading is our cookies and tracking page for what we set ourselves, and the privacy policy for how the rest of the site is built. The shorter version: the most useful thing we can do for your privacy is to not be in the loop when you process a file. The most useful thing you can do for your own privacy is to assume every site is already drawing an invisible square on a canvas to see who you are, and configure your browser to make that drawing worth less.

Frequently asked questions