What every modern browser exposes about your device (and what it doesn't)

A fresh Chrome opens a site. Within milliseconds, before the page has even finished rendering, that site can know your GPU, your screen size, your timezone, your approximate memory, your logical CPU count, and roughly which country you're connecting from. No prompt, no click, no permission. The information is in the first JavaScript event loop tick, available to every script the page loads.

None of this was sneaked in by a tracker. Every one of those signals exists for a legitimate reason — adaptive layout, codec selection, performance budgeting, accessibility. Most of it is sitting in browser APIs because once it shipped, taking it away breaks things. The result is a sensor surface that's grown more or less continuously since 2008.

The browser as a sensor

The browser exposes hundreds of properties via JavaScript APIs. They fall into three broad categories based on how a site gets at them:

• Direct globals. navigator.platform, screen.width, Intl.DateTimeFormat().resolvedOptions().timeZone. Available immediately, no user interaction required.
• User-activation gated. Geolocation, clipboard read, some payment APIs. Require the user to click something before the browser will let the API run, but no explicit prompt.
• Permission gated. Camera, microphone, push notifications, persistent storage. Trigger a visible prompt; the user has to actively click Allow.

The distinction matters. Anything in the first category is fair game for any site you visit — no audit trail, no indication to you that it was read. The second and third categories at least leave fingerprints (a click, a prompt).

Sensors — what's available without permission

• Screen. Width, height, colour depth, pixel ratio, available area (excluding the OS taskbar).
• Window. Inner width and height, devicePixelRatio, scrollbar size.
• Timezone and locale. Via Intl.DateTimeFormat(). Reveals approximate geographic region — and inferring country from timezone is reliable for non-overlapping zones.
• Hardware. navigator.hardwareConcurrency (logical core count), navigator.deviceMemory (RAM rounded down to the nearest power of two, capped at 8 GB).
• GPU. Vendor and renderer string via the WebGL WEBGL_debug_renderer_info extension. Reveals the GPU make and model in Chrome and unmasked Firefox; locked down in Safari and resistFingerprinting Firefox.
• Network. Connection type (wifi, cellular, etc.) and downlink estimate via the Network Information API. Chrome and Edge only — Firefox and Safari don't ship it.

Every one of these is available the moment a script runs. No permission prompt, no indicator. The diagnostic on this site reads them and displays them so you can see exactly what your browser is volunteering.

APIs and feature flags — what tells you the platform

Beyond the direct properties, the presence or absence of an API is a fingerprint on its own. WebGPU exists? You're on Chrome 113+, Edge 113+, or Safari 18+. AVIF decoded? Not Safari before 16, not older Firefox. The Media Source Extensions support matrix — which codecs the browser claims it can play — is a reliable browser-version detector even with the user agent spoofed.

This is what the diagnostic on this site does. Rather than parsing the user-agent string (which is increasingly meaningless — Chrome on iOS is actually Safari WebKit with a Chrome wrapper), it feature-detects which APIs answer to typeof window.X !== 'undefined' queries. That tells you the truth about what the browser can do, regardless of what the UA string claims.

Anti-fingerprinting in Safari and Firefox

Apple's Intelligent Tracking Prevention (ITP) has rolled out incremental restrictions since 2017. Notable: third-party cookie restrictions, partial canvas-rendering randomisation, locked-down high-entropy User-Agent Client Hints, and capped screen values that round to common buckets so two iPhones look identical even if one is in landscape and the other portrait.

Firefox's Enhanced Tracking Protection plus the deeper Resist Fingerprinting mode (privacy.resistFingerprinting in about:config) goes further: rounded screen sizes, frozen UA string, restricted hardwareConcurrency (always reports 2), locked timezone (UTC).

The result for a diagnostic tool: it sees less data from Firefox and Safari than from Chrome. The data isn't hidden — it's deliberately quantised or absent. If you run the same diagnostic on Firefox with default settings and Chrome with default settings, the Firefox report will have noticeably more "unknown" and "rounded" entries. That's working as intended.

What is NOT exposed

• CPU model, exact RAM, exact disk capacity, any serial numbers.
• IMEI, MAC address, Bluetooth address.
• Account state for other origins (Gmail login, Twitter session).
• Installed applications — mostly. There are workarounds via custom URL handlers, but they prompt and they're noisy.
• Sensors that require permission: geolocation, camera, microphone, accelerometer (on iOS), persistent storage.

The boundary is "what you can passively know" vs "what requires a prompt". Browsers have generally moved more things into the prompt category over the past five years, occasionally breaking sites that relied on passive access in the process.

How fingerprinting actually combines all of this

None of the individual signals identifies you. Screen size: a few hundred common values. Timezone: 30 or so common zones. Hardware concurrency: maybe ten common values. GPU renderer string: a few thousand. Installed fonts: highly variable.

But the combinations are vastly more specific. The Electronic Frontier Foundation's Panopticlick experiment estimated that the average browser fingerprint is unique among tens of thousands of others, mostly from the combination of UA string, screen size, timezone, plugins, and fonts. Add canvas rendering and WebGL renderer and the surface shrinks to one-in-a-million levels of specificity.

This is why anti-fingerprinting modes target the high-entropy combinations rather than trying to hide any single signal. Round the screen size, freeze the UA, randomise the canvas rendering by one pixel — and the fingerprint that was unique becomes one of thousands of identical fingerprints. The data is still being sent; it just stops being useful for tracking. The same approach informs Apple's Private Relay and Tor Browser's single-resolution window: pull users into the same bucket, and individual signals stop mattering.

What this means for bug reports and compatibility

A browser diagnostic dump is the fastest way to communicate "what I'm seeing" to a developer. Browser, version, OS, permissions, supported APIs, codec support — everything that drives a bug repro, in one paste. The same dump is also a passable fingerprint, but you're sending it deliberately, to one person, with their knowledge, instead of leaking it implicitly to every site you visit.

When to use the browser-diagnostic tool here

The browser diagnostic is for bug reports and compatibility checks. Markdown export pastes cleanly into GitHub issues. Sections are collapsible so a long report doesn't bury the section the developer needs.

Related reading

The what-browser-am-I-using page is the lightweight version — just the identity, no feature surface. The screen resolution checker drills into the screen and viewport details if that's the part of the diagnostic you care about. The user-agent vs client-hints guide explains why the UA string is becoming less useful and what's replacing it.