Why Multilogin doesn’t mask every browser fingerprint value
Seeing a value marked "real", "shared", or “not masked” doesn’t automatically mean your browser profile is leaking information or set up incorrectly.
Not every fingerprint value needs to be unique, and some values don’t come from the browser profile at all.
➡️ Don’t change a setting just because a checker highlights it. First, check what the value actually is and whether Multilogin is supposed to mask it.
📱 Working with Android apps? Browser masking is only relevant to browser profiles. Cloud phones give you a genuine Android environment on a real cloud-hosted device for native app workflows – no need to turn a desktop browser into a phone. Learn about Android cloud phones.
Why isn’t everything masked?
Because more masking isn’t automatically better.
A browser fingerprint is made from lots of signals that need to make sense together. If you change one value without keeping the rest of the setup consistent, you can create an unusual combination.
And some shared values are completely normal. Two real users can have the same browser version, graphics card, fonts, or other device details.
What do common checker results mean?
MAC address
Websites can’t read your computer’s MAC address through normal browser APIs.
A MAC address is used on your local network – it isn’t a regular browser fingerprint value sent to websites.
So if a checker mentions MAC addresses, that doesn’t mean the website can see your computer’s real MAC address.
SIM card ID
Websites opened in a normal browser can’t read your SIM card ID through standard web APIs.
Using a 4G or other cellular connection may expose some general network information, but it doesn’t give the website your SIM identifier.
Native apps are different – they can have different permissions and access to device features.
Font and glyph hashes
Two profiles can have the same font or glyph hash, and that can be perfectly normal.
A checker might test only a small set of fonts, characters, or text measurements. If two profiles give the same answers, they can get the same hash.
For example, adding another font won’t change the result if the checker never tests that font.
Plugin hash
A shared plugin hash is also common.
Modern browsers largely expose a standardized plugin list for built-in PDF viewing. If inline PDF viewing is supported, current browser specifications return a fixed set of standard plugin entries.
So different profiles can naturally produce the same plugin result.
ClientRects
ClientRects tells a website about the size and position of elements on the page.
A checker can turn those measurements into a hash. The result can depend on things like layout, window size, fonts, and rendering.
If two profiles get the same result, that alone doesn’t mean they’re the same browser.
JA3, JA4, and TLS fingerprints
JA3 and JA4 look at characteristics of the TLS connection a client makes to a website. They’re used by security systems to group and analyze similar traffic.
Several profiles can share the same result – and that isn’t automatically unusual. Cloudflare notes that groups of similar requests can share a JA3 fingerprint, while JA4 reduces unnecessary variation to make similar clients easier to group.
So a shared JA3, JA4, or TLS value isn’t something you need to make unique just for the sake of it.
What should I do if a checker says “real” or “not masked”?
Start with the value itself – not the warning label.
- Shared value? It may simply be common across normal browsers
- Network value? Browser fingerprint settings may not control it
- Something a website can’t normally access? There may be nothing to mask in the first place
- Actual mismatch? Check whether several related signals contradict each other
Simple rule: don’t change unrelated settings just to get a different score or hash.
If a checker reports a real inconsistency, see How to fix browser fingerprint inconsistencies.