Browser Fingerprint & Privacy Leak Inspector Reference

Canvas Fingerprint

Your GPU and browser driver silently produce a different pixel pattern on every machine. Canvas fingerprinting exploits this by drawing styled text onto an offscreen canvas, exporting the pixel buffer, and hashing it into an identifier that survives cookie clears, VPN switches, and private browsing sessions. The mechanism is HTMLCanvasElement.toDataURL(): a script draws styled text and shapes onto an offscreen canvas, exports the raw pixel buffer, and hashes it. The hash captures every rendering difference introduced by the GPU model, graphics driver, OS compositor, and font rasterizer.¹

Researchers documented this technique in 2012; it remains one of the highest-entropy passive signals available without any user interaction.² The W3C fingerprinting guidance classifies canvas renders as active fingerprinting surfaces, noting that scripts deliberately draw shapes and text to elicit hardware-specific rendering differences that browsers cannot easily normalize.³

What is Canvas?

How the browser generates the canvas hash

Generating a canvas fingerprint takes three steps. First, a script creates an offscreen HTMLCanvasElement and calls getContext('2d') to obtain a drawing context. Second, it draws a fixed test composition: styled text in multiple font sizes, filled rectangles with specific alpha values, shadow effects, and Unicode emoji characters. Third, it calls toDataURL('image/png') to export the raw pixel buffer as a Base64 string, then hashes that string. Consequently, the hash captures every rendering difference the GPU, driver, OS, and font system introduced during the draw pass.

Building on this, even two machines running the same browser version on the same OS frequently produce different hashes when their GPU drivers differ, because the ANGLE graphics translation layer on Windows produces driver-dependent pixel values for anti-aliased text and sub-pixel gradient rendering that no browser-level normalization step can eliminate.⁶

Why canvas hashing resists conventional spoofing

Spoofing a canvas fingerprint requires either randomizing the pixel buffer on every access or replacing the entire rendering pipeline with a fixed output. Extensions like CanvasBlocker add small amounts of random noise to the exported pixel data, which changes the hash on every page load.⁷ Yet this approach introduces a detectable anomaly: a canvas hash that changes on every access is itself a fingerprinting signal, because real browsers on real hardware produce consistent hashes across calls within a session.

Furthermore, fully blocking toDataURL() breaks legitimate applications including data URI exports, image editors, and some CAPTCHA systems, which makes total suppression impractical for general-purpose browsers. Brave solves this by injecting per-site random noise that is consistent within a session but differs across origins, which passes site functionality checks while preventing cross-site linking through a stable hash.

Detecting and blocking canvas fingerprinting in practice

Detecting a canvas fingerprint attempt requires monitoring calls to HTMLCanvasElement.toDataURL() and toBlob() for unusual behavioral patterns: a short test string rendered in multiple fonts, followed by an immediate data URI export with no visible output to the user. Chromium-based browsers expose a Canvas debugger panel in DevTools that logs every draw call and pixel export. Conversely, not all canvas exports indicate fingerprinting; games, chart libraries, image editors, and video processing tools call the same APIs for legitimate purposes.

How to choose the right blocking level

Effective blocking therefore targets the behavioral pattern rather than the API call itself. Firefox's privacy.resistFingerprinting intercepts toDataURL() at the engine level and injects a randomized modification to the pixel buffer before returning it to the script, making it more robust than extension-based approaches because it operates below the JavaScript layer and cannot be detected by checking whether the API responds normally.

You can test whether a blocking level is too aggressive by loading a site that depends on canvas rendering and watching for distorted charts or broken images. The goal is to add just enough noise to reduce the hash's uniqueness without making the page unusable. CapyToolkit lets you compare the exported value before and after each change so the trade-off stays visible.⁴

Emoji and Unicode as entropy amplifiers in canvas fingerprinting

Canvas fingerprinting scripts draw text rather than shapes because text rendering exposes more hardware-specific variance. Simple geometric shapes like filled rectangles and solid-color gradients produce pixel-perfect output across most hardware, because no font rasterizer or sub-pixel hinting algorithm is involved. Text rendering involves the OS font stack, the browser's text layout engine, the GPU's anti-aliasing pipeline, and the display's sub-pixel order, each introducing a layer of hardware-specific variation.

Emoji characters amplify this effect further. Emoji rendering calls platform-specific image compositing pathways: Apple's Core Text stack on macOS, DirectWrite on Windows, and FreeType with HarfBuzz on Linux each composite emoji differently. A script that includes a skin-tone emoji or a flag sequence in its canvas draw call exposes platform-specific rendering differences that purely ASCII text cannot produce. The combination of a Latin character string, a Unicode symbol, and an emoji creates a multi-layer rendering test that distinguishes hardware combinations that produce identical hashes for simpler inputs.

How gradient and shadow rendering add additional signal

Shadow blur radius calculations also vary by rendering backend. A script that draws text with a specified shadow blur using CanvasRenderingContext2D.shadowBlur exposes how each GPU and compositor handles Gaussian blur approximations. Chrome on Windows applies ANGLE's blur algorithm, which differs from Skia's algorithm used in Firefox. A canvas composition that combines emoji, shadow blur, and a semi-transparent gradient overlay creates a compound test that produces highly distinct output across GPU and browser combinations.

OffscreenCanvas and cross-origin isolation effects

OffscreenCanvas is a newer browser API that allows canvas rendering to happen in a Web Worker, off the main thread. Fingerprinting scripts use OffscreenCanvas because Web Worker execution is less visible to browser extensions that monitor main-thread canvas API calls. An extension that intercepts HTMLCanvasElement.toDataURL() on the main thread may not intercept the equivalent OffscreenCanvas call in a worker, depending on the extension's architecture.

The same GPU and rendering stack produces the same pixel output regardless of whether the script uses a standard HTMLCanvasElement or an OffscreenCanvas. Consequently, the fingerprint value collected through OffscreenCanvas is identical to the standard canvas fingerprint on the same machine, but the collection path is less accessible to content-script-based blocking. Firefox with privacy.resistFingerprinting applies its canvas modification at the rendering engine level, which applies consistently to both HTMLCanvasElement and OffscreenCanvas regardless of which thread initiates the draw call.

How cross-origin isolation changes canvas access permissions

Cross-origin isolation (achieved through Cross-Origin-Opener-Policy and Cross-Origin-Embedder-Policy response headers) grants access to high-resolution timing APIs but does not restrict canvas fingerprinting. A cross-origin isolated page can use SharedArrayBuffer and high-precision performance.now(), which may help fingerprinting scripts time rendering operations more precisely. However, canvas access restrictions under cross-origin isolation apply to cross-origin iframes reading canvas contents from a parent frame, not to first-party canvas fingerprinting scripts operating within the same origin. The isolation boundary affects canvas data sharing between origins, not canvas data collection within a single origin.

Try in the tool

WebGL Fingerprint

When a page needs graphics details, WebGL can reveal your GPU model directly from the graphics driver. The WEBGL_debug_renderer_info WebGL extension exposes two high-value parameters: UNMASKED_VENDOR_WEBGL, which returns the GPU manufacturer, and UNMASKED_RENDERER_WEBGL, which returns the full GPU model name, driver series, and rendering backend identifier¹. Scripts retrieve these values by calling getParameter(ext.UNMASKED_VENDOR_WEBGL) and getParameter(ext.UNMASKED_RENDERER_WEBGL) after obtaining the extension object from a WebGL context. Consequently, a single pair of API calls returns a string like "ANGLE (NVIDIA GeForce RTX 4070 Direct3D11 vs_5_0 ps_5_0)" that directly identifies the GPU model, the Windows Direct3D version, and the shader model², a triple of values that narrows a browser population dramatically. Furthermore, WebGL exposes dozens of additional parameters beyond the renderer string, each reflecting hardware capability limits that vary across GPU generations and vendor implementations.

What is WebGL?

What the WEBGL_debug_renderer_info extension exposes

The WEBGL_debug_renderer_info extension is optional in the WebGL specification, meaning browsers choose whether to expose it⁴. Chrome and Firefox expose it by default; querying it requires calling canvas.getContext('webgl').getExtension('WEBGL_debug_renderer_info') and checking that the return value is not null. Calling getParameter(ext.UNMASKED_RENDERER_WEBGL) then returns a string that, on Windows Chrome, takes the form "ANGLE (NVIDIA GeForce RTX 4070 Direct3D11 vs_5_0 ps_5_0)"³. This string simultaneously identifies the GPU model, the rendering API (Direct3D11), the vertex shader model, and the pixel shader model, packing four distinct hardware identifiers into a single return value that any script can read without special permissions.

Why WebGL exposes so much

Consequently, each GPU generation and driver family produces a distinct renderer string. Furthermore, different operating systems produce different string formats for the same GPU: macOS reports Metal-based strings, Linux reports Mesa-based strings, and Windows reports ANGLE-based strings, making the renderer string an OS indicator as well as a GPU identifier. This level of detail is what makes WebGL fingerprinting so much more precise than simpler signals like screen resolution or timezone, which only narrow the population to thousands of browsers rather than pinpointing a specific hardware configuration that can single out one user among millions with a single API call.

The renderer string is worth checking because it reveals more than most users expect, including the GPU model and the operating system build in a single value. Running the inspector shows whether your browser returns a detailed string or a generic one, and whether the WebGL surface is present at all. That visibility helps you judge how much a given protection actually changes what a script can read.

Testing the WebGL row in CapyToolkit makes this concrete rather than theoretical. The inspector reports the exact renderer string your browser returns, so you can see whether a protection has replaced it with a generic value or removed the WebGL surface entirely. That direct read is the fastest way to confirm whether a privacy setting is actually reducing what scripts can collect.

Parameter fingerprinting beyond vendor strings

Beyond the renderer string, WebGL exposes more than 50 queryable parameters that reflect hardware capability limits specific to each GPU model, driver generation, and browser implementation⁴. gl.MAX_TEXTURE_SIZE indicates the maximum texture dimension the GPU supports; entry-level mobile GPUs typically report 4096, while desktop GPUs report 16384 or higher, and this single value alone can distinguish mobile from desktop hardware. gl.MAX_VERTEX_ATTRIBS reports how many vertex attributes the shader can handle simultaneously, and the list of supported WebGL extensions varies between GPU vendors, driver versions, and browser implementations in ways that create a distinctive multi-parameter signature. Yet the renderer string alone is not always sufficient for precise identification; two machines with the same GPU model but different driver versions may report identical renderer strings, which is why scripts query multiple parameters.

Building on this, combining the renderer string, the MAX_TEXTURE_SIZE limit, the supported extension list, and the shader precision format values produces a multi-dimensional hardware profile that reaches higher entropy than the renderer string alone, because each parameter adds an independent dimension that narrows the candidate hardware population in a way that no single value could achieve on its own. Fingerprinting scripts typically query 10 to 15 parameters in a single WebGL context initialization, building a profile that is substantially more identifying than any individual signal.

Mitigation options across browsers

Browser vendors have adopted different strategies for limiting WebGL fingerprinting exposure. Brave blocks the WEBGL_debug_renderer_info extension entirely when Shields are active; getExtension('WEBGL_debug_renderer_info') returns null, making the vendor and renderer strings unavailable⁵. Furthermore, Brave randomizes additional WebGL parameters at the extension level when Shields are on, so even parameters accessible without WEBGL_debug_renderer_info carry per-site noise.

When WebGL masking helps

Firefox with privacy.resistFingerprinting enabled spoofs the renderer string to a generic value and limits several capability parameters to prevent hardware-level profiling⁶. Tor Browser disables WebGL by default at the Safer security level, which eliminates the entire attack surface but prevents WebGL-dependent applications like 3D maps, games, and data visualizations from running⁷. Conversely, Chrome exposes the full WebGL surface without modification; users who want protection on Chrome must rely on third-party extensions, none of which replicate Brave's depth of coverage.

What protection costs in compatibility

If you use WebGL-heavy sites, test the exact page after changing browser settings because a protected browser may keep the application running while reducing the detail fingerprinting scripts can collect. That practical check is better than assuming every WebGL block is either safe or broken. Disabling WebGL entirely, as Tor Browser does at higher security levels, eliminates the fingerprinting surface but also breaks 3D maps, browser games, and data visualizations that depend on hardware-accelerated rendering. A more measured approach is to use Brave or Firefox with spoofing, which preserves WebGL functionality while limiting the specificity of the signals that scripts can read.

Try in the tool

AudioContext Fingerprint

For silent audio tracking, AudioContext fingerprinting hashes the output of a test audio signal¹. A script creates an OfflineAudioContext, attaches an OscillatorNode set to a fixed frequency, connects the output to a DynamicsCompressorNode, and renders the result offline². The rendered audio buffer is then passed to an AnalyserNode, and getFloatFrequencyData() exports the frequency response as a Float32Array. Hashing this array produces a value that reflects the floating-point arithmetic behavior of the CPU, the audio driver stack, and the OS audio subsystem. Chalise and Vadrevu documented this technique in their arXiv 2021 paper, noting that even machines with identical hardware can produce different audio fingerprints when their audio drivers differ¹. Consequently, the audio hash is independent of the canvas hash, making them complementary signals: a tracker that collects both has higher confidence even when one hash is blocked or modified by the browser.

What is AudioContext?

How the audio hash is generated

Generating an audio fingerprint requires four steps. First, a script instantiates an OfflineAudioContext with a fixed sample rate and buffer length, typically OfflineAudioContext(1, 44100, 44100). Second, it creates an OscillatorNode set to a frequency like 10000 Hz and connects it through a DynamicsCompressorNode to the OfflineAudioContext destination. Third, it calls startRendering(), which executes the entire audio graph in memory without producing any audible output. Fourth, it creates an AnalyserNode, pipes the rendered buffer through it, and calls AnalyserNode.getFloatFrequencyData() to export the frequency response values. Hashing the resulting Float32Array produces a stable identifier.

Why AudioContext reveals hardware differences

Consequently, this entire process runs silently in the main JavaScript thread with no user interaction and no visible output, making it undetectable without specialized monitoring tools. Building on this, the computation completes in under 50 milliseconds on most hardware, adding negligible page load overhead². The frequency response curve captures subtle variations in how each CPU handles the DynamicsCompressorNode's gain reduction algorithm, which involves iterative floating-point operations that produce slightly different rounding results across processor architectures and driver implementations

Running the same audio test on two physical machines with different CPUs shows how distinct the curves can be, even when the rest of the browser looks identical. The inspector reports the frequency response so you can see whether your browser randomizes it or leaves the hardware signature exposed. That single check reveals a signal most users never realize their device is broadcasting on every page load.⁴.

Testing the AudioContext row in CapyToolkit turns that invisible process into something you can see. The inspector shows the frequency response curve your device produces, so you can tell whether a protection is randomizing it or leaving the hardware signature fully exposed. Running the same test before and after enabling a protection is the clearest way to confirm the change actually took effect.

Why hardware differences appear in audio processing

The audio fingerprint varies across machines because floating-point arithmetic is not perfectly uniform across CPU architectures, DAC implementations, and audio driver stacks. The IEEE 754 floating-point standard permits implementations to apply extended precision in intermediate calculations, which means two CPUs can produce slightly different results for the same sequence of floating-point operations even when running identical code⁴. Consequently, the DynamicsCompressorNode's gain reduction calculations, which involve iterative floating-point operations on the audio buffer, produce subtly different output values on different hardware.

How protections change the audio curve

Furthermore, the audio driver stack introduces variation because the OS mixes signals at the driver level, and different audio API implementations, CoreAudio on macOS, WASAPI on Windows, and ALSA on Linux, apply different processing chains before the data reaches the JavaScript environment⁵. Building on this, even two machines with the same CPU model can produce different audio fingerprints when their audio drivers differ.

Blocking AudioContext fingerprinting

Blocking the AudioContext fingerprint is harder than blocking canvas because the same OfflineAudioContext API powers legitimate audio applications; synthesizers, audio worklets, and Web Audio-based games all depend on it. Brave injects per-site noise into the frequency response values exported by AnalyserNode.getFloatFrequencyData(), similar to its canvas farbling approach⁶. Firefox with privacy.resistFingerprinting enabled replaces the system math library in Web Audio with fdlibm, producing bit-identical audio output across platforms and preventing fingerprinters from exploiting cross-platform floating-point differences⁷.

Why a total block is rarely practical

Yet no universal browser block exists for the base AudioContext API; completely disabling the Web Audio API would break too many legitimate audio applications. Conversely, some extensions can intercept AudioContext calls and return spoofed values, but extension-based blocking operates at the JavaScript layer and can be bypassed by scripts that check for consistent API behavior. Combining Brave's built-in noise injection with uBlock Origin in strict mode provides the most practical level of protection currently available.

Try in the tool

User-Agent Fingerprint

The User-Agent string was the first fingerprinting signal in browsers. Every HTTP request carries a User-Agent header, and navigator.userAgent exposes the same string to JavaScript. The original purpose was content negotiation; servers needed to know which browser version to serve compatible content for. Consequently, the UA string evolved into a detailed identifier including the browser engine, version number, OS name, OS version, and architecture. Chrome 107 began the UA Reduction initiative, freezing the minor, build, and patch version numbers to "0.0.0"¹, which reduces the entropy of the UA string component². Building on this, navigator.userAgentData provides a structured replacement through the User-Agent Client Hints API, where Sec-CH-UA sends a low-entropy brand list by default and high-entropy values like platform version and architecture require explicit server requests via Accept-CH headers. The UA string alone provides moderate entropy; its tracking value increases when combined with other hardware signals.

What is User-Agent?

What the legacy User-Agent string contains

The User-Agent string began as a simple identifier but grew into a multi-field browser descriptor. A typical Chrome 124 User-Agent on Windows reads: "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36"⁴. Parsing this string reveals the Windows NT 10.0 version, the 64-bit architecture, the WebKit compatibility marker, and the Chrome major version. Firefox on macOS reports a different structure that includes the Gecko rendering engine version, and Safari on both iOS and macOS uses a WebKit-based format that omits the Chrome-style compatibility tokens entirely, producing a shorter but equally identifying string.

Why the User-Agent still matters

Consequently, the UA string simultaneously encodes the browser type, the OS family, and the platform architecture, three separate signals in a single header. Building on this, before Chrome 107's UA Reduction initiative, the full build version was included, making even minor browser updates detectable from the UA string alone without any JavaScript execution required on the page. The practical consequence is that a single HTTP request fingerprint could identify a specific browser build among millions of users, amplifying the tracking value of every other signal collected during the session because the UA string was available before any JavaScript even executed on the page.

You can see the exact value your browser sends by opening the inspector and checking the User-Agent row, then compare it with the Client Hints values the same browser exposes. A browser with UA Reduction active shows a frozen build number, while one without it reveals the full version string on every request. Testing both side by side shows how much the reduction step actually removes from what a server can read.

UA Reduction and the Client Hints replacement

Chrome 107 introduced UA Reduction, which freezes the minor, build, and patch version components of the Chrome UA string to "0.0.0"¹. The UA string still reports the major version and OS information, but the full build identifier is no longer exposed. The User-Agent Client Hints API (navigator.userAgentData) provides a structured, permission-gated replacement².

How client hints change the fingerprint

By default, every request from a Chromium browser sends three low-entropy hints: Sec-CH-UA (the browser brand and major version), Sec-CH-UA-Mobile (whether it is a mobile browser), and Sec-CH-UA-Platform (the OS name). Yet servers that respond with an Accept-CH header listing Sec-CH-UA-Arch, Sec-CH-UA-Platform-Version, or Sec-CH-UA-Model can request the higher-entropy values that UA Reduction removed from the legacy string. Furthermore, JavaScript can call navigator.userAgentData.getHighEntropyValues() directly³, which returns the same high-entropy values without requiring a server round-trip.

Spoofing UA strings and why it rarely reduces entropy

Changing the User-Agent string through browser settings, extensions, or developer tools is straightforward, but it rarely reduces overall fingerprint entropy because the other signals remain unchanged. A browser reporting a Firefox UA string while still exposing a Chrome-specific canvas hash, ANGLE WebGL renderer, and Chrome extension list creates an internally inconsistent fingerprint profile. Fingerprinting systems score consistency across signals; an inconsistent profile is itself a distinctive signal, potentially easier to re-identify than an unmodified fingerprint.

Furthermore, spoofing the UA string on Chromium does not change the Sec-CH-UA header, which reports the real browser brand unless the server specifically targets Client Hints. Conversely, browsers like Brave take a different approach; they report a realistic UA for a generic version of the browser rather than attempting to impersonate a completely different engine, which avoids the consistency mismatch that UA spoofing creates.

Legacy navigator properties that accompany the User-Agent string

Beyond navigator.userAgent, the browser exposes several related properties that fingerprinting scripts collect alongside the UA string. navigator.platform returns a short OS identifier such as "Win32", "MacIntel", or "Linux x86_64"; this string is reduced by Chrome's UA Reduction but still distinguishes OS families. navigator.language returns the browser's primary language setting, such as "en-US" or "fr-FR". navigator.languages returns the full ordered language preference list set in the browser's language settings.

Taken together, navigator.userAgent, navigator.platform, navigator.language, and navigator.languages form a four-signal language and OS cluster. The combination of "Win32" platform plus "en-US" language plus a Chrome UA string narrows the browser population to English-speaking Windows Chrome users; adding navigator.languages that includes "es" or "zh-CN" narrows it further. Firefox with privacy.resistFingerprinting spoofs navigator.platform to a platform-dependent value ("Win32" on Windows, "MacIntel" on macOS, "Linux x86_64" on Linux) rather than using a single universal string, because a platform_value that mismatches other signals would itself be a detectable fingerprint⁵.

Chrome's UA Reduction program includes navigator.platform alongside navigator.userAgent and navigator.appVersion as one of the three primary reduced APIs⁶. The property now returns a frozen generic value based on the OS family rather than the real hardware identifier. A Chrome 124 browser on a 64-bit Windows machine reports "Win32" from navigator.platform while the UA string reports "Windows NT 10.0; Win64; x64", creating a subtle mismatch between the two signals that persists even after UA Reduction shipped.

How Brave and Firefox handle User-Agent differently

Brave and Firefox take opposite approaches to User-Agent privacy. Brave reports a realistic User-Agent string for a generic Chrome version rather than attempting to impersonate a different browser engine. When Shields are active, Brave's reported UA matches a recent but non-specific Chrome version on a generic Windows platform, which places the browser within the large population of Chrome users without creating a detectable spoofing pattern. This approach avoids the consistency mismatch that arises when a browser reports a Firefox UA while its canvas hash and WebGL renderer string are clearly Chrome-specific.

Firefox with privacy.resistFingerprinting takes a stricter approach. RFP spoofs the User-Agent to a specific pinned string that all Firefox RFP users share, freezing both the browser version and the OS platform. Consequently, all Firefox RFP users appear to have the same browser version and platform, which provides herd anonymity at the cost of potentially misrepresenting the browser version to sites that use the UA for compatibility decisions.

What Sec-CH-UA exposes that the legacy UA string cannot be changed to hide

Sec-CH-UA sends the browser brand list on every request from Chromium browsers, including Brave. Brave's UA string may report a generic Chrome version, but the Sec-CH-UA header sends the "Brave" brand alongside the Chromium brand, because the Client Hints API was designed to be accurate rather than privacy-preserving⁷. You can verify which brands your browser sends in Sec-CH-UA by opening DevTools, checking a request's headers, and looking for the Sec-CH-UA field. The brand list identifies the real browser even when the legacy UA string is spoofed.

Try in the tool

Timezone Fingerprint

Timezone is a low-entropy signal that narrows geographic location. Intl.DateTimeFormat().resolvedOptions().timeZone returns the IANA timezone identifier such as "America/New_York" or "Europe/Berlin", while Date.prototype.getTimezoneOffset() returns the UTC offset in minutes.¹ Neither API requires any user permission, and both execute synchronously in any JavaScript context.

Taken alone, a timezone identifier narrows a user to one of roughly 400 IANA zones, representing modest entropy.² Yet timezone becomes meaningful when combined with other low-entropy signals: the browser language, the Accept-Language header, and the installed font set. Consequently, the combination of UTC-5 offset plus en-US language plus a Windows-specific font set collapses to a much smaller population than any of those signals individually.

Furthermore, a VPN does not change the reported timezone; a user connecting through a Japanese exit node who reports "America/New_York" creates a detectable mismatch that fingerprinting systems flag as a VPN indicator.³ This makes timezone one of the simplest signals to collect yet one of the hardest to spoof without also changing the underlying operating system locale settings.

What is Timezone?

How timezone is detected through two API paths

Two separate JavaScript APIs expose timezone information, each with different characteristics. Intl.DateTimeFormat().resolvedOptions().timeZone returns the full IANA timezone identifier, "America/Los_Angeles", "Asia/Tokyo", or "Europe/London", which encodes both the UTC offset and the daylight saving time transition rules specific to that zone. Date.prototype.getTimezoneOffset() returns the current UTC offset in minutes as a signed integer; -300 represents UTC-5 and 330 represents UTC+5:30.

Why timezone is a quiet identifier

Consequently, a script that calls both APIs gets complementary data: the IANA string identifies the exact zone while the offset confirms the current UTC difference. Furthermore, the IANA timezone changes when the user adjusts their OS regional settings, but it does not change when they connect through a VPN, use a private browsing window, or clear cookies. Building on this, the getTimezoneOffset() value fluctuates by an hour during daylight saving time transitions, which means two readings taken months apart can differ for zones that observe DST.

You can check what your browser reports by opening the inspector and reading the timezone row, then compare it with your actual system setting to see whether they match. A browser with resistFingerprinting enabled reports UTC regardless of where you are, which removes the geographic clue entirely. Running the same check on a VPN connection shows the mismatch that fingerprinting services look for when they try to spot tunneled traffic.

Timezone combined with language and locale

Timezone achieves its highest tracking value when correlated with other geographic and cultural signals. UTC-5 combined with Accept-Language: en-US reduces the candidate pool to English speakers in the US Eastern timezone, tens of millions of users. Yet adding Windows-specific system fonts, a 1920x1080 screen, and a mid-range NVIDIA GPU further narrows this pool to a specific socioeconomic segment.

When timezone becomes meaningful

Building on this, unusual timezone-language combinations are particularly distinctive. A browser reporting "Asia/Tokyo" while setting Accept-Language to "en-US" is statistically rare and may indicate a traveler, expat, or VPN user. Conversely, a user reporting "Europe/Paris" plus "fr-FR" language is less distinctive because many millions share that combination. Furthermore, multiple-timezone environments, a user who frequently travels and changes their system clock, produce inconsistent timezone histories across sites that record and compare timezone reports over time.

Spoofing timezone and the VPN mismatch problem

Firefox with privacy.resistFingerprinting enabled freezes the reported timezone to UTC regardless of the system locale setting, which eliminates geographic information from the timezone signal entirely.⁵ Scripts that call Intl.DateTimeFormat().resolvedOptions().timeZone receive "UTC", and Date.prototype.getTimezoneOffset() returns 0 for every Firefox RFP user worldwide. Consequently, the timezone signal contributes zero geographic information when RFP is active, making all Firefox RFP users appear to share the same global location.

How privacy browsers handle timezone

Brave does not randomize the timezone by default; Standard Shields focuses on higher-entropy signals like canvas and WebGL rather than low-entropy locale indicators. Yet the most significant timezone spoofing problem occurs with VPN users who do not also adjust their system timezone. A browser reporting "America/Chicago" while connecting from a European VPN exit node creates a geographic inconsistency that fingerprinting services actively check. Building on this, some privacy tools offer automatic timezone adjustment to match the VPN's apparent location, which eliminates the mismatch signal but requires additional configuration beyond basic VPN setup.

Try in the tool

Screen Resolution Fingerprint

The pixel dimensions your browser reports are more identifying than they appear. A raw 1920x1080 resolution is shared by hundreds of millions of users, yet fingerprinting scripts combine screen.width, screen.height, window.devicePixelRatio, and screen.colorDepth into a multi-value profile that is far less common than any single number suggests.

Unusual combinations, a 3840x2160 resolution at devicePixelRatio 1.75, or a setup that produces a screen.width larger than any standard single monitor, dramatically narrow the candidate pool. HiDPI and non-integer-scaling setups that are common among developers and design professionals create distinctive device signatures as a result.

Furthermore, iOS normalizes the reported CSS resolution independently of the physical display resolution, which means mobile device fingerprinting based on screen resolution differs fundamentally from desktop fingerprinting approaches.¹

What is Screen Resolution?

What resolution and DPI reveal about your hardware

The four screen APIs together describe the display hardware class with considerably more precision than any single signal alone suggests, because the combination of resolution, pixel density, color depth, and available area creates a multi-dimensional profile. screen.width at 3840 and screen.height at 2160 identifies a 4K monitor, a configuration shared by a much smaller user population than the hundreds of millions using 1920x1080. window.devicePixelRatio at 2.0 indicates a Retina display typical on Mac hardware, while a value of 1.5 indicates a specific display scaling setting in Windows that is significantly less common in the global browser population.³

Why screen size is more specific than it looks

Consequently, a 4K monitor at 1.75 scaling (devicePixelRatio: 1.75) is a statistically unusual combination that narrows the population more than either value alone. Building on this, screen.colorDepth at 24 bits is near-universal, but some displays report 30 bits for HDR content, which is distinctive. Furthermore, screen.availWidth smaller than screen.width by more than 30 pixels may indicate a visible taskbar of a specific height, which correlates with OS identity on platforms where taskbar height is standardized.

You can see the exact values your display reports by opening the inspector and reading the screen resolution, devicePixelRatio, and color depth rows together. A standard 1920x1080 monitor at ratio 1.0 looks ordinary, while a 4K panel at a non-integer scaling stands out immediately. Comparing two of your own devices side by side shows how much the combination narrows the pool compared with any single dimension on its own.

HiDPI and multi-monitor setups as entropy amplifiers

High-DPI displays significantly amplify the fingerprinting contribution of screen signals because the combination of physical resolution and scaling factor creates distinctive CSS pixel dimensions that are shared by fewer users. A macOS user with a 2560x1440 external monitor at devicePixelRatio 2.0 reports screen.width 1280 and screen.height 720 in CSS pixels, a combination that signals the exact display model class when combined with the macOS-specific User-Agent string. Windows users who set display scaling to 150% report devicePixelRatio 1.5, and those at 175% report 1.75; these non-integer values are considerably less common than 1.0 or 2.0, which narrows the candidate pool from hundreds of millions to tens of millions of browsers worldwide.

How browser protections change the view

Conversely, multi-monitor setups typically appear only as the primary monitor's dimensions in screen.width and screen.height, which means a user with two monitors appears no different from a user with one unless the secondary monitor has a different devicePixelRatio. Building on this, screen resolution combined with GPU model from WebGL identifies the display hardware tier with high precision. Firefox with privacy.resistFingerprinting rounds the reported dimensions to the nearest 200px increment, masking the true monitor resolution while keeping the values plausible enough that most layout scripts continue to function normally.⁴

Why resolution matters less on mobile than desktop

iOS deliberately normalizes the CSS resolution reported to the browser, independent of the physical screen resolution. An iPhone 15 Pro with a physical resolution of 2556x1179 reports screen.width 430 and screen.height 932, the logical resolution at 3x device pixel ratio. Consequently, many iPhone models with different physical screens report similar CSS dimensions, which reduces the tracking value of screen resolution on iOS. Android does not apply the same normalization; Android Chrome reports the actual CSS pixel dimensions, which vary more widely across the fragmented Android device ecosystem.⁵

What to compare before changing settings

Furthermore, desktop browsers report different values at different monitor zoom levels; a user who sets Chrome to 90% zoom changes the effective screen.width reported to scripts, which can cause session-to-session inconsistency. Building on this, iOS 26 AFP normalizes screen dimensions further as part of its fingerprinting protection suite, making iOS 26 Safari report less distinctive screen information than earlier iOS versions.

Try in the tool

Hardware Concurrency Fingerprint

For device-tier tracking, hardware concurrency exposes your CPU core count to any script. navigator.hardwareConcurrency returns the number of logical CPU cores available to the browser, which on modern hardware typically ranges from 2 to 32 depending on the processor and hyperthreading configuration.¹ The companion API, navigator.deviceMemory, reports the device's approximate RAM in gigabytes rounded to a small set of values: 0.25, 0.5, 1, 2, 4, or 8.² Together, these two values describe the performance tier of the device, a combination that correlates with device price, purchase year, and user segment. Consequently, a 16-core machine with 8 GB reported memory identifies a mid-range to high-end desktop or workstation class. Building on this, these signals alone produce lower entropy than canvas or WebGL fingerprinting, but they function as strong corroborating signals when combined with screen resolution and GPU renderer to classify devices by tier and vintage.

What is Hardware Concurrency?

What these values reveal about CPU and RAM class

The combination of navigator.hardwareConcurrency and navigator.deviceMemory enables device tier classification. An entry-level Android phone reports hardwareConcurrency 4 or 8 with deviceMemory 1 or 2. A mid-range laptop reports hardwareConcurrency 8 to 16 with deviceMemory 8. A workstation with a 24-core processor reports hardwareConcurrency 24 or 48 (with hyperthreading) paired with deviceMemory 8 (the maximum reported value).

Why CPU and memory hints matter

Consequently, the specific combination narrows the device class significantly within any site's audience. Building on this, high hardwareConcurrency values are increasingly common as consumer CPUs ship with more cores, which reduces the uniqueness of the high end. Yet specific combinations like hardwareConcurrency 12 (a 6-core hyperthreaded mobile CPU) remain distinctive because they identify a specific generation of mid-range notebook processors. Furthermore, these values are stable across sessions and do not change when the user switches networks, browsers, or VPN providers.

You can read both values directly by opening the inspector and checking the hardware concurrency and device memory rows, then compare them with the specifications of your actual machine. A browser with resistFingerprinting enabled reports a frozen core count, while one with farbling shows a value that shifts between sessions. Running the check on two different browsers on the same computer makes the difference in how each vendor handles the signal obvious.

How browsers handle these APIs differently

Browser vendors have diverged on how much accuracy to provide for these hardware APIs. Chrome exposes the real hardwareConcurrency value and the real deviceMemory in the permitted range. Firefox with privacy.resistFingerprinting enabled freezes hardwareConcurrency to 2 regardless of actual CPU count, which makes Firefox RFP users appear to have a 2-core machine, rare on modern hardware but consistent across all Firefox RFP users, providing herd anonymity.⁴

Brave randomizes hardwareConcurrency to a value between 2 and the true value on default protection, or between 2 and 8 on max protection, changing per session when Shields are active to prevent stable cross-site linking without completely misrepresenting the hardware.⁵ Conversely, Safari reports the real hardwareConcurrency value and does not farble it in current releases. Building on this, the discrepancy between what browsers report creates a secondary signal: a machine that always reports hardwareConcurrency 2 is likely running Firefox RFP, which is itself an identifier within the global browser population.

Using these signals to distinguish device tiers

Combining hardwareConcurrency and deviceMemory with screen resolution and GPU renderer produces a robust device tier classifier that fingerprinting services use for fraud detection and audience segmentation. A device reporting hardwareConcurrency 4, deviceMemory 2, screen.width 360, and a Mali GPU renderer is almost certainly an entry-level Android phone. A device reporting hardwareConcurrency 16, deviceMemory 8, screen.width 2560, and an NVIDIA RTX renderer is a high-end desktop workstation.

How protections change hardware signals

Consequently, these classifications are useful for fraud detection because bots and automation environments frequently misreport or cannot access accurate hardware values; headless Chrome in a cloud container typically reports hardwareConcurrency matching the container CPU allocation, which may be 2 or 4 rather than a value characteristic of a real consumer device. Firefox with privacy.resistFingerprinting freezes the reported value to 2, which collapses all RFP users into a single herd and prevents device tier classification entirely. Brave randomizes within the set {2, 4, 8} per session, which preserves plausible device profiles while preventing stable cross-site tracking of the hardware tier signal.

Why corroborating signals matter

Building on this, device tier signals also help ad networks apply audience segmentation based on inferred purchasing power correlated with device class. A user with hardwareConcurrency 16, deviceMemory 8, and an NVIDIA RTX renderer is classified as a high-value audience segment, while a user reporting hardwareConcurrency 2 and deviceMemory 1 falls into a budget-device category. The combination of multiple low-entropy signals produces a more reliable classification than any single API call, which is why fingerprinting scripts collect hardware concurrency alongside screen resolution, GPU renderer, and installed fonts rather than relying on any one value alone.

Try in the tool

WebRTC IP Leak

WebRTC is the browser API most likely to expose the real network path, especially when you rely on a VPN. RTCPeerConnection uses ICE (Interactive Connectivity Establishment) to discover candidate network paths for peer-to-peer connections. During this process, it calls STUN servers to discover the public IP address and enumerates local network interfaces to discover LAN IP addresses.

Critically, it creates its own UDP socket outside the VPN tunnel for these discovery requests, which means the public IP returned by a STUN server reflects the real network interface, not the VPN exit node.¹ Consequently, a user connected through a VPN who opens a site that triggers `RTCPeerConnection.createOffer() may expose their real home IP address even though all HTTP traffic routes through the VPN. Building on this, the leak is not limited to the public IP; local LAN addresses like 192.168.x.x are also exposed in ICE` candidates, which can identify the router subnet and confirm that the user is on a private network.

What is WebRTC?

How WebRTC discovers local and public IPs

The ICE candidate gathering process runs automatically when a script creates an RTCPeerConnection and calls createOffer(), without any user permission or visible browser notification to alert the person browsing the page. The browser opens UDP sockets on each available network interface and sends STUN binding requests to a configured STUN server, which then replies with the public IP address that the request arrived from. Simultaneously, the browser enumerates all local network interfaces and includes each discovered LAN IP address as a host candidate in the ICE candidate list.

Why WebRTC can leak network clues

Consequently, a site that triggers this process receives both the real public IP from the STUN response and the LAN IP from the local interface enumeration, even if the user is connected through a VPN. Building on this, the LAN IP leak reveals the router subnet and confirms the presence of a private network; a 10.0.0.x LAN address pattern identifies a corporate network more specifically than a 192.168.1.x pattern that is typical of home routers.³ The entire ICE candidate gathering sequence completes within a few seconds of page load.

You can check whether your setup leaks by opening the inspector and running the WebRTC test, which gathers ICE candidates and shows the IP addresses your browser exposes. A VPN that tunnels UDP correctly hides your public address, while one that does not leaves the real IP visible in the candidate list. Running the test with the VPN both off and on makes the difference immediately clear and shows whether your configuration actually protects you.

Why VPNs don't block WebRTC by default

Most VPN implementations tunnel TCP connections through the virtual network interface, which causes HTTP traffic to appear to come from the VPN exit node. Yet WebRTC uses UDP for its ICE candidate discovery requests, and many VPN clients on Windows and macOS do not route UDP traffic through the VPN tunnel by default. The OS-level routing table determines which interface handles each UDP packet; if the VPN client does not insert a catch-all UDP route for all traffic, the STUN request travels over the physical network interface rather than the VPN interface.

How browser controls change WebRTC exposure

Consequently, the STUN server sees the real public IP rather than the VPN exit IP and returns it in the STUN binding response, which the browser includes as a server-reflexive ICE candidate. Firefox lets you disable WebRTC entirely through about:config by setting media.peerconnection.enabled to false, which stops all ICE candidate gathering at the cost of breaking video conferencing.⁴ Brave takes a more targeted approach by restricting ICE candidates to the active network interface, which prevents the physical interface from leaking when a VPN is active while keeping WebRTC functional for peer-to-peer applications.

Why connection order matters

Furthermore, the timing of VPN connection setup matters: if the VPN connects after the browser has already initialized a WebRTC session, the already-discovered candidates retain the real IP even after the VPN connects. This means that opening a WebRTC-enabled page before activating your VPN can expose your real public IP for the entire browsing session. The safest practice is to connect to the VPN first, then open the browser, ensuring that all ICE candidate gathering happens through the tunneled interface from the start.

Disabling WebRTC by browser

Browser vendors have adopted widely different approaches to WebRTC IP leak prevention, ranging from complete disabling to targeted candidate restriction depending on the vendor's assessment of the compatibility trade-off. Firefox allows complete disabling of WebRTC through about:config by setting media.peerconnection.enabled to false, which prevents all ICE candidate gathering at the cost of also disabling WebRTC-dependent features like browser-based video conferencing and peer-to-peer file sharing.

Brave blocks WebRTC from leaking non-VPN IP addresses by default; it still allows WebRTC functionality but restricts ICE candidates to addresses associated with the active network interface, preventing the physical interface from being exposed when a VPN is active. Safari and iOS Safari have blocked the WebRTC local IP leak since iOS 14 by using mDNS tokens instead of real IP addresses for host candidates, so sites see a token like a3f4b5c6.local rather than 192.168.1.x.⁵ Conversely, Chrome on desktop and Android does not restrict WebRTC IP exposure by default; users who want protection must install an extension like WebRTC Network Limiter or uBlock Origin with WebRTC leak prevention enabled.

Try in the tool