How to Reduce Your Browser Fingerprint

How to Reduce Your Browser Fingerprint

You can significantly reduce your fingerprinting exposure by using privacy-focused browsers, enabling built-in anti-fingerprinting features, and installing targeted extensions.¹ No single solution eliminates fingerprinting entirely, but combining several approaches makes you much harder to track.

Start with the browser, not a single setting

Reducing your fingerprint starts with browser choice, which is the single highest-impact decision you can make. A default Chrome window exposes real canvas output, real WebGL renderer strings, real audio processing, hardware concurrency, device memory, screen dimensions, and timezone without any modification. Brave, Firefox with resistFingerprinting, and Tor Browser each change those signals before a site can hash them, and the difference in entropy scores between Chrome and any of those alternatives is dramatic.

Why browser choice matters most

Consequently, switching browsers usually produces a larger privacy improvement than changing one isolated setting, because the browser controls every signal that fingerprinting scripts can reach. Your best setup depends on whether you need normal site compatibility, stronger cross-site unlinkability, or the highest anonymity model available, and that decision should be driven by what you actually do online rather than by a single feature comparison. A practical first step is to test your current browser in the fingerprint inspector, note which signals stand out, and then evaluate which alternative browser addresses those specific rows.

You can test the same set of sites in two different browsers on the same machine to see how dramatically the exposed signals change. The entropy score often drops by a wide margin when you move from a default Chrome profile to Brave or Firefox RFP, because those browsers alter the graphics, audio, and hardware signals together rather than one at a time. CapyToolkit shows the before and after side by side so the impact of the browser itself is clear.

Running the inspector in CapyToolkit before and after you switch browsers makes the change concrete rather than theoretical. The side by side view shows exactly which signal rows changed and by how much, so you can confirm the new browser actually lowers your entropy score instead of only shifting which values a site can read. That evidence is what turns a privacy setting into a verified improvement.

Measure the result before changing more settings

Measuring your fingerprint before changing settings keeps the process practical and repeatable. If you apply several protections at once, you may not know which one improved the result and which one only broke a site or introduced a new detectable anomaly. Start with a baseline in your normal browser using CapyToolkit, record the entropy score and the specific rows that stand out, then test one change at a time so you can attribute every improvement to a specific setting.

How to read the before and after comparison

A useful result is not always a blank value. A stable but less unique value can be better than a missing value if the site still works and the hash no longer links cleanly across origins. Look at the entropy score first, then check individual rows to see which signals changed. CapyToolkit makes this comparison visible, so you can choose protections that reduce tracking without guessing or applying multiple changes at once and losing track of which one helped.

Layer protections by signal type

Layering works because fingerprinting scripts collect several independent signals. Canvas and WebGL expose your graphics stack, AudioContext exposes CPU and audio processing behavior, font probing exposes installed typefaces, and hardware APIs expose CPU and RAM class.¹ Blocking one category leaves the others available, so a complete reduction plan addresses each category.

How each browser addresses signal layers

Brave farbles many high-entropy signals per site, creating per-origin noise that prevents cross-site linking without breaking page functionality.² Firefox RFP freezes or caps several values such as screen dimensions and hardware concurrency, providing uniformity across all RFP users.³ Tor Browser normalizes the whole profile and can windowbox page content to reduce diversity, offering the strongest model at the cost of speed.⁴ This layered view helps you choose the smallest change that still reduces the signals a site can read.

When extensions are useful, and when they are not

Extensions can help when the browser does not provide native protection. uBlock Origin in strict mode blocks many third-party fingerprinting scripts before they run,⁵ and CanvasBlocker can randomize canvas exports.⁶ Yet extensions operate above the page script and cannot always match browser-level farbling. Some extensions also create detectable patterns, such as canvas hashes that change on every access. If you use extensions, test the result in the fingerprint inspector and keep only the tools that change meaningful signals without breaking the sites you need. Start with one extension, verify that it actually alters the targeted signal, and only add another if a specific gap remains. Stacking three or four privacy extensions often produces diminishing returns while increasing the chance of conflicts, detectable extension patterns, and site breakage that sends you back to a default browser anyway.

For everyday privacy without breaking the web

For everyday privacy, aim for a setup that reduces high-entropy signals while keeping normal sites usable and visually consistent. Brave with Standard Shields is the simplest starting point because it protects canvas, WebGL, AudioContext, hardware APIs, and fonts without manual configuration, and it does so without altering the visible behavior of the sites you visit every day.

Firefox with privacy.resistFingerprinting gives you more control, but it can round screen dimensions, freeze timezone to UTC, and break location-sensitive sites. Tor Browser provides the strongest model, yet it is best for high-risk browsing rather than every tab you open. Test your own entropy score after each change, then keep the configuration that balances privacy and usability. The goal is not a perfect score but a practical one: a setup that meaningfully reduces your exposure while still letting you bank, stream, and browse without constant workarounds. Revisit the test every few months because browser updates can change which signals your chosen configuration actually suppresses.

Font enumeration: the overlooked fingerprinting surface

Font fingerprinting scripts probe for installed fonts by rendering text in specific typefaces and measuring the pixel width using CanvasRenderingContext2D.measureText(). If a font is installed, the measured width differs from the fallback font width. If it is absent, the fallback measurement returns. Scripts probe dozens of fonts in a single page load, then combine the presence/absence pattern into a binary string. On a Windows 11 machine with Microsoft Office installed, this pattern can identify the OS, the Office version, and even the language pack, because each installs a distinct set of additional fonts.

Reducing font-based fingerprinting requires limiting which fonts the browser exposes through measureText(). Firefox with privacy.resistFingerprinting restricts font enumeration to a small common set, preventing the script from detecting system-installed fonts beyond the browser's built-in list. Brave with Standard Shields applies similar restriction, randomizing the reported font width measurements with per-site noise. The practical trade-off is that some web typography that relies on system font detection for fallback decisions may not render as intended under these protections.

For sites where font rendering matters, use a dedicated browser profile with protections active rather than disabling them site-by-site. Keeping fonts installed on the system is unavoidable for productivity software, but testing which fonts your browser exposes through CapyToolkit's font fingerprint row shows whether your browser's protection is actually working. A protected browser returns a short, consistent list rather than a detailed enumeration of every typeface you have installed.

Validating your protection: what to look for in CapyToolkit

Testing your actual privacy setup requires running CapyToolkit Browser Fingerprint Inspector both before and after applying each protection. The tool separates signals into those your browser exposes cleanly (visible to trackers), those it modifies or randomizes (partially protected), and those it blocks entirely. Record the entropy score in your default browser as a baseline. Apply one protection at a time: enable Brave Shields, or set privacy.resistFingerprinting in Firefox, or install CanvasBlocker.

Re-run the inspector after each change and compare which rows changed. A canvas hash that now shows a different value on each reload confirms that the canvas is being farbled. A WebGL renderer row that returns empty or null confirms that the extension is blocked. An audio fingerprint that shows "blocked" or a zero value confirms that AudioContext is protected. Without this verification step, you cannot confirm that your privacy setup actually reduces the signals a page can read.

Some protections reduce entropy without eliminating the signal entirely. A canvas hash that changes between sites but stays consistent within a site session is better than a stable hash but not as strong as a completely randomized one. CapyToolkit's per-signal detail lets you see exactly which level of protection each signal receives, so you can decide whether to accept a partial reduction or add another layer of protection for the signals that still expose your hardware accurately.

When to use this

Use these techniques when you want to make your browser harder to track across sites. They are especially useful for journalists, activists, researchers, or anyone concerned about cross-site tracking.

Examples

Default Firefox still exposes screen size, timezone, and User-Agent to every site you visit.

Enable `privacy.resistFingerprinting` = true in `about:config`. This rounds screen dimensions to the nearest 100, reports a fixed timezone (UTC), and masks many other signals.

Chrome-based browsers send full fingerprint signals by default.

Brave blocks third-party fingerprinting by default, randomizes canvas output, and reports a simplified User-Agent string. It also blocks known fingerprinting domains.

Browser Fingerprinting in Incognito Mode

Incognito mode does not prevent browser fingerprinting.¹ Opening a private browsing window creates a fresh session with no cookies, no browsing history, and no form data, but none of these changes affect the hardware signals that fingerprinting scripts collect.² Your canvas hash, WebGL renderer string, audio fingerprint, screen resolution, hardware concurrency, and installed font set are all identical in an incognito window compared to a regular window, because they reflect the underlying browser and hardware configuration rather than stored session data.

Consequently, a site that records your fingerprint in a regular session can re-identify you when you visit in incognito mode, without any cookies or localStorage data.¹ Building on this, many users rely on incognito mode as a privacy tool without understanding that it was designed to prevent local history exposure, not cross-site tracking. The fingerprint persists across private and regular windows because it is computed fresh from hardware on every page load.

What incognito mode clears versus what fingerprinting uses

Incognito mode performs a defined set of session isolation operations. It starts a fresh cookie jar, clears any localStorage and sessionStorage from previous sessions, discards the browser history for the session, and prevents form autofill data from being saved. These protections are effective against attacks that rely on reading previously stored data, tracking pixels that set a first-party cookie, or scripts that read a user ID from localStorage. Yet fingerprinting scripts do not read stored data.

Why incognito does not erase live signals

They call browser APIs to retrieve live hardware and software characteristics: HTMLCanvasElement.toDataURL() to get the GPU-rendered pixel hash, navigator.userAgentData to get the browser version, OfflineAudioContext to hash the audio processing output, and screen.width to get the display dimensions.² Consequently, none of the values these APIs return change between a regular window and an incognito window on the same machine. Building on this, the fingerprint computed in incognito mode is byte-for-byte identical to the fingerprint from the previous regular session.

You can confirm this for yourself by opening the inspector in a normal window, recording the entropy score, then opening an incognito window on the same machine and running the same check. The score and the individual signal rows stay the same, which shows that private browsing changes nothing about what a script can read. The only way to alter the result is to switch to a browser with built-in anti-fingerprinting or to enable a protection setting that changes the underlying values.

How a fingerprint persists across regular and incognito windows

The mechanism of fingerprint persistence across window modes is structural rather than a design flaw in the browser's implementation of private browsing. Fingerprinting works by computing a deterministic function of stable hardware and software inputs that remain identical regardless of which window mode is active.³ The GPU model does not change between windows, the font rasterizer does not change, the CPU core count does not change, and the audio driver behavior does not change because none of these are session-level properties.

When private browsing still helps

Consequently, identical inputs produce identical outputs on every computation, regardless of which browsing mode the window uses. Building on this, a site that records a fingerprint hash during a regular session will see the same hash when the user visits in an incognito window the next day. There is no session boundary that separates these computations because no session data is involved in generating the hash. Furthermore, the fingerprint is stable even across browser restarts, VPN connections, and IP address changes, none of which alter the hardware configuration that produces the hash.

What actually reduces fingerprinting in private browsing

Adding meaningful fingerprint protection to a private browsing session requires browser-level changes that go well beyond the standard incognito implementation found in most browsers. Brave's farbling defenses randomize canvas and Web Audio output so the values differ from site to site,⁴ Firefox's private windows do not apply RFP protections unless privacy.resistFingerprinting is manually enabled in about:config, which then affects all windows globally rather than being scoped to private mode only.⁵

Tor Browser's private mode eliminates high-entropy signals by normalizing all fingerprint surfaces across all Tor users, providing the strongest protection at the cost of browsing speed, since every Tor user appears to share identical hardware characteristics regardless of their actual device configuration.⁶ Conversely, Chrome's Incognito mode and Safari's Private Browsing mode provide no fingerprint protection beyond standard session isolation, leaving every hardware signal fully exposed to any script that runs in the private window.⁷

Which private mode is actually safer

For users who want private browsing that also resists fingerprinting, the choice of browser matters more than which browsing mode is selected. Brave private windows apply canvas farbling, WebGL suppression, and audio randomization on top of standard session isolation, making them meaningfully more resistant than Chrome Incognito or Safari Private Browsing, which provide no fingerprint protection at all. Firefox private windows with privacy.resistFingerprinting enabled also reduce high-entropy signals, though the setting applies globally rather than being scoped to private mode. Test the exact fingerprint before trusting the mode label, because the name "private" or "incognito" tells you nothing about whether the browser actually modifies the hardware signals that fingerprinting scripts collect.

When to use this

Use this guide when checking whether incognito mode changes your fingerprint before relying on private browsing, or when explaining why a fingerprint score is identical between private and regular browser windows on the same machine.

Examples

Open CapyToolkit Browser Fingerprint Inspector in a regular Chrome window. Record the canvas hash value shown under the Canvas row.

Open the same tool in a Chrome Incognito window. The canvas hash is identical to the regular window value. Incognito cleared cookies; it did not change the GPU rendering behavior that produces the hash.

Chrome Incognito: canvas hash = c84efb8e... (identical to regular Chrome window, no protection)

Brave Private Window: canvas hash = 7a1df3c9... (different from regular Chrome baseline, changes per origin, farbling active)

Does a VPN Hide Your Browser Fingerprint

A VPN hides your IP address, not your browser fingerprint.¹ This distinction matters because most tracking systems combine network-layer and browser-layer signals: your IP address identifies your approximate location and ISP, while your fingerprint identifies your specific browser and hardware combination.² Connecting through a VPN changes the first but leaves the second completely intact. Consequently, a tracker that collects both your VPN exit node address and your canvas hash can still link your sessions across visits, even as your apparent IP address rotates between providers. Building on this, some users assume that a VPN resolves all tracking concerns, a misconception that leaves fingerprinting exposure unaddressed. Understanding where a VPN's protection ends is the prerequisite for deciding which browser-level measures your privacy setup actually needs.

What a VPN changes and what it leaves intact

A VPN tunnels your network traffic through an intermediary server, replacing your real IP address with the server's exit IP in every outbound request that passes through the encrypted tunnel. From a tracking perspective, this prevents IP-based geolocation, makes IP-linked session stitching harder, and hides your traffic content from your local network observer or ISP. Yet the VPN has absolutely no access to your browser's JavaScript execution environment, where fingerprinting scripts collect canvas hashes, WebGL renderer strings, and audio fingerprints directly from local hardware APIs.

Why browser signals pass through a VPN untouched

Your canvas hash, WebGL renderer string, installed font list, screen dimensions, and hardware concurrency values are collected directly from browser APIs without any network request that a VPN could intercept. The VPN provider cannot normalize those values because they are produced inside your browser before the page sends its normal HTTPS requests. Consequently, those signals remain identical whether you connect from home, a coffee shop, or a VPN exit node in a different country, because the VPN only operates at the network layer and has no access to the JavaScript environment where fingerprinting scripts execute.

WebRTC is a specific exception where the VPN boundary can fail: some browsers expose your real LAN IP address through WebRTC ICE candidates even when a VPN is active, because WebRTC opens its own UDP socket outside the VPN tunnel, bypassing the encrypted route that all other traffic follows, and this leak persists regardless of which VPN provider or protocol you have configured.³

How trackers combine network and fingerprint signals

Tracking systems that use both signals operate in two tiers. The network tier records which IP addresses a fingerprint has been seen from, building a map of VPN exit nodes associated with specific fingerprints. The fingerprint tier matches the canvas hash, audio fingerprint, and WebGL renderer string regardless of what IP sent the request.

Why fingerprint databases make IP rotation irrelevant

Consequently, a VPN that changes your IP address every hour provides no additional protection once a site has observed your fingerprint on a previous visit without a VPN. Ad networks and fraud prevention services share fingerprint databases across websites, meaning your fingerprint can link visits to entirely different domains even if you switch VPN providers between sessions.⁴ The IP address becomes a low-confidence signal when fingerprinting is available; sites that rely primarily on fingerprinting effectively ignore IP rotation as a privacy measure. To pair a VPN with fingerprint protection, use a browser that actively resists fingerprinting such as Brave with Shields or Firefox with privacy.resistFingerprinting, so that the network layer and browser layer are both addressed.

Fingerprint protection options that work alongside a VPN

Effective fingerprint protection operates at the browser level, independent of whatever network-layer tool you use. Brave with Standard Shields active randomizes canvas output, WebGL parameters, AudioContext processing, and hardware API values per site, making cross-site linking through fingerprinting impractical.⁵ Firefox with privacy.resistFingerprinting enabled freezes several high-entropy signals and rounds screen dimensions.

Tor Browser goes furthest by normalizing all fingerprint signals to match every other Tor user, at the cost of slower browsing through the Tor network. Conversely, browser extensions that spoof only the User-Agent string provide minimal protection, since the User-Agent is one of the least-entropy signals in a modern fingerprint. Combining a VPN with a fingerprint-resistant browser addresses both the network-layer and browser-layer components of the tracking problem simultaneously. For sensitive sessions, test the result after each change so the setup protects the signals the page can actually read.

The WebRTC exception: when a VPN still leaks your real IP

WebRTC creates a specific case where a VPN can fail to hide your real IP address even when fingerprinting is not involved. RTCPeerConnection's ICE candidate gathering process opens UDP sockets on all available network interfaces and sends STUN requests to discover the public IP address. Because most VPN clients tunnel TCP traffic but do not route all UDP traffic through the VPN interface, the STUN server receives the request on the physical network interface and returns your real home IP address in the STUN response. The browser includes this real IP in the ICE candidate list, which any script on the page can read by listening for onicecandidate events.

The practical consequence is that a user connected through a VPN may have their real IP exposed through WebRTC even when the HTTP layer is fully tunneled. Brave prevents this by default: when Shields are active, Brave restricts ICE candidates to the active network interface, which is the VPN interface when a VPN is connected. Firefox allows you to disable WebRTC entirely by setting media.peerconnection.enabled to false in about:config, which stops the IP leak but also stops browser-based video conferencing.⁶

Testing for WebRTC leaks before relying on your VPN

Open CapyToolkit's WebRTC row while connected to your VPN. If you see an IP address in the local or public candidate sections that matches your real home IP rather than the VPN exit IP, your VPN is leaking through WebRTC. This test takes 30 seconds and is more reliable than self-reported VPN documentation about UDP routing behavior. Address the leak by choosing Brave as your VPN browser, enabling Firefox's WebRTC restrictions, or installing a browser extension specifically for WebRTC leak prevention.

What anti-detect browsers offer that a VPN cannot

Anti-detect browsers are commercial tools designed to spoof or replace the browser signals that fingerprinting scripts collect. Products like Multilogin and Linken Sphere allow users to configure custom browser profiles with specific canvas hashes, WebGL renderer strings, User-Agent strings, and hardware concurrency values, then maintain those profiles persistently across sessions. The primary market for these tools is multi-account management, where operators need each browser session to appear as a distinct device to avoid platform-level account linking.

For general privacy use, anti-detect browsers are more complex and expensive than the protection Brave or Firefox provides. They also introduce a different risk: a perfectly spoofed fingerprint that does not match any real browser hardware combination creates a distinctive anomaly in fingerprinting systems that maintain device databases. A canvas hash claiming to come from a Mac GPU attached to a Windows OS version is internally inconsistent and potentially more identifiable than an authentic but protected fingerprint.

For everyday privacy, Brave with Standard Shields provides practical fingerprint reduction without the complexity of configuring custom browser profiles. For multi-account operations, an anti-detect browser's profile management features provide capabilities that Brave does not. If you already use a VPN for IP masking, adding Brave on top addresses the fingerprint gap that the VPN leaves entirely unprotected. Testing your actual setup with CapyToolkit confirms which signals remain exposed after combining both tools.

When to use this

Use this guide when testing whether your VPN actually hides your browser fingerprint, or when deciding which browser-level settings to add on top of any VPN connection for users who want comprehensive tracking resistance.

Examples

You connect through a VPN and open CapyToolkit Browser Fingerprint Inspector. Your canvas hash, WebGL renderer, and audio fingerprint appear unchanged compared to your last visit without the VPN.

The entropy score is identical. The VPN changed your visible IP address; none of the browser signals changed. A site that recorded your fingerprint before the VPN connection can still re-identify your browser.

Standard browser through VPN: IP hidden, fingerprint fully exposed. The tracking system uses the fingerprint to link your sessions across IP rotations.

Brave with Shields enabled through VPN: IP hidden, canvas hash randomized per site, WebGL renderer not reported, audio fingerprint randomized. Cross-site and cross-session linking through fingerprinting becomes impractical.