Android Chrome Browser Fingerprint

Android Chrome Browser Fingerprint

Compared with iOS Safari, Android Chrome exposes hardware signals that Apple deliberately obscures. On Android, navigator.deviceMemory returns the actual device RAM class, navigator.hardwareConcurrency returns the real CPU core count, and screen.width and screen.height report physical CSS pixel dimensions without the normalization that iOS applies.

The WebGL renderer string includes the full GPU model, "Adreno (TM) 750" or "Mali-G715 MC6", which identifies both the chip manufacturer and the device tier.¹ Consequently, two Android phones with identical model names but different hardware configurations can produce different WebGL renderer strings, narrowing the identification pool further than device model alone would suggest.

Building on this, Google's 2025 Privacy Sandbox update did not restrict JavaScript hardware APIs, leaving Android Chrome with the same hardware exposure profile as desktop Chrome. Samsung Internet on Galaxy devices applies its own content blocking but still exposes the same fingerprinting APIs as Chrome, producing different canvas hashes but equivalent hardware signals.

What Android Chrome reveals beyond iOS

The most significant difference between Android Chrome and iOS Safari fingerprinting is the exposure of real hardware values. navigator.deviceMemory on Android returns the device's actual RAM class: 1 for entry-level phones, 2 or 4 for mid-range devices, 8 for flagships.² iOS does not implement navigator.deviceMemory, returning undefined. navigator.hardwareConcurrency on Android returns the real logical core count, typically 4, 6, or 8 for current phones.

Why Android Chrome exposes more hardware detail

The WebGL renderer string on Android Chrome includes the full GPU model name from the hardware vendor: Qualcomm's Adreno series, ARM's Mali series, or Apple's unnamed GPU (on iPhones, where the WebGL renderer string is blocked by default).¹ Consequently, the Android Chrome fingerprint contains direct hardware classification data that allows scripts to determine whether the device is entry-level, mid-range, or flagship tier. Building on this, screen.width and screen.height on Android report the CSS pixel dimensions computed from physical pixels divided by devicePixelRatio, which vary by screen resolution and density setting across the fragmented Android device ecosystem.

These exposed values matter because they let a script distinguish between devices that share the same marketing name. Two phones sold as the same model can ship with different chipsets, and the WebGL renderer string reveals that difference directly. You can see the effect by running the fingerprint inspector on two identical-looking handsets and comparing the GPU model each one reports.

Samsung Internet vs. Chrome on Galaxy devices

Samsung Internet is the pre-installed browser on Samsung Galaxy devices and ships with distinct content blocking and user agent behavior compared to Chrome on the same hardware. Samsung Internet includes Samsung's built-in ad blocker and smart anti-tracking features, which block some third-party fingerprinting scripts by domain. The canvas hash produced by Samsung Internet differs from Chrome's canvas hash on the same device because the two browsers use different rendering pipelines; Samsung Internet's Blink-based renderer applies different canvas anti-aliasing settings.³

How Android differs from iOS Safari

Consequently, a device running both Samsung Internet and Chrome on the same Galaxy phone will produce different canvas hashes, which means fingerprinting via canvas alone cannot link sessions across the two browsers on the same device. Yet the hardware signals, WebGL renderer, deviceMemory, hardwareConcurrency, and screen dimensions, are identical between the two browsers because they query the same hardware. Building on this, Samsung Internet's User-Agent string includes "SamsungBrowser" rather than "Chrome", which itself identifies the browser family as a distinct segment.

Reducing Android browser fingerprint exposure

Chrome on Android provides no built-in fingerprinting protection whatsoever, exposing the same complete hardware signal set as desktop Chrome including real deviceMemory, hardwareConcurrency, and full WebGL renderer strings. Brave for Android applies the same farbling protections as desktop Brave: canvas hash is randomized per site, WebGL renderer is blocked, hardwareConcurrency is randomized to a value from {2, 4, 8}, and audio context fingerprinting receives per-site noise that prevents stable cross-session linking.⁴⁵ Firefox Focus for Android, although limited in extension support compared to the desktop version, enables a meaningful subset of privacy protections that reduce fingerprinting exposure relative to default Chrome.

Conversely, installing a privacy extension in Chrome for Android is more limited than on desktop because Chrome Android enforces stricter extension API restrictions under Manifest V3, which prevents extensions from intercepting the same low-level API calls that desktop extensions can modify. Consequently, switching browsers on Android provides substantially more fingerprint protection than adding extensions to Chrome, since a different browser with built-in farbling modifies the signals before JavaScript ever executes rather than trying to patch them after the fact.

What to test on your phone

Furthermore, enabling Brave Shields on Android produces a measurable reduction in the entropy score shown in CapyToolkit Browser Fingerprint Inspector; the WebGL renderer and canvas hash both change to indicate Brave's protections are active. You should also compare the hardwareConcurrency value before and after enabling Shields, since Brave randomizes it to a value from the set {2, 4, 8} per session. Testing with CapyToolkit on your specific device is the most reliable way to confirm which signals change and which remain exposed, because the exact fingerprint profile varies by device model, Android version, and browser configuration.

When to use this

Use this guide when comparing what Android Chrome exposes against iOS Safari on matching hardware, or when evaluating whether Brave for Android provides meaningful protection on a specific Android device.

Examples

Android Chrome (mid-range device): `navigator.deviceMemory` → 4 (real RAM class returned)

iOS Safari (any device): `navigator.deviceMemory` → undefined (API not implemented in Safari; iOS does not expose RAM class to scripts)

Android Chrome: `UNMASKED_RENDERER_WEBGL` → "Adreno (TM) 750" (full Qualcomm GPU model exposed)

iOS Safari: `UNMASKED_RENDERER_WEBGL` → "" (`WEBGL_debug_renderer_info` blocked since Safari 12; GPU model not exposed)

Browser Fingerprinting on Samsung Galaxy (Chrome)

Chrome on this Galaxy phone sends a frozen, generic User-Agent header on every request by default, part of Google's User-Agent Reduction rollout meant to cut down on passive fingerprinting from server logs.¹ That header reduction covers what a server sees automatically; it says nothing about what a page's own JavaScript can still ask for. This device already exposes real hardware values through other APIs regardless: navigator.deviceMemory returns this phone's actual RAM tier and the WebGL renderer string names its exact GPU chipset, both untouched by the User-Agent change.

Specifications

The User-Agent header looks generic, but this Galaxy still hands over its model

Chrome's User-Agent Reduction effort replaced the old, detailed User-Agent string with a standardized format that omits the exact Android build and device model by default.¹ On paper that sounds like a meaningful privacy improvement, and for passive server-side header logging, it is one. What it does not do is stop a page's own script from asking for the same information through a different, still-available API, which is exactly what this Galaxy phone's Chrome build allows.

The frozen header only covers passive logging

A server that only inspects the raw User-Agent request header on this device sees a generic Android and Chrome version string with no mention of "Galaxy" or a specific model number. That is a genuine improvement over the pre-reduction format, which used to spell out the device model directly in every request. But the reduction is a change to what gets sent automatically by default, not a restriction on what a page is permitted to ask for once it has loaded and started running its own JavaScript.

Sec-CH-UA-Model is one JS call away, no prompt required

Calling navigator.userAgentData.getHighEntropyValues(['model', 'platformVersion']) from any script running on this page returns the real device model and platform version.² Access is governed by a Permissions-Policy header the site itself sets, not by a permission dialog shown to you the way camera or microphone access would be. In practice, a site that wants this Galaxy's exact model just asks for it in a single async call, and the reduced default header never enters the picture at all.

Why the hardware APIs matter more here than the header ever did

Even setting Client Hints aside entirely, this Galaxy's Chrome already exposes real hardware values through separate JavaScript APIs that the User-Agent reduction never touched. navigator.deviceMemory returns this phone's actual RAM class rather than a randomized placeholder, and the WebGL renderer string names the exact GPU chipset driving the display.³⁴ Neither API reads from the User-Agent header, so reducing that header has no effect on either one.

The GPU renderer string alone narrows this phone's population

Querying UNMASKED_RENDERER_WEBGL on this device returns a string in the form "Adreno (TM) 750," directly naming the Qualcomm chipset inside it, the same behavior CapyToolkit's own Android Chrome guide documents for Galaxy hardware generally.³ Combined with the real RAM tier from deviceMemory, a script can classify this phone's performance tier and chipset family without ever touching the frozen User-Agent string or asking for a single Client Hint, which is why the header reduction alone is a smaller privacy win on this specific configuration than it might first appear.⁵

Two phones marketed under the same Galaxy model name can still ship with different chipset revisions across regions or production runs, and the renderer string reveals that difference directly where a rounded model name would not. That is a meaningful narrowing signal on top of whatever the model string itself already provides, independent of anything the User-Agent header does or doesn't send. Combining the renderer string with the RAM tier from deviceMemory and the screen dimensions reported through screen.width and screen.height gives a script three independently sourced hardware values to cross-reference, none of which the User-Agent reduction was ever designed to touch in the first place.