BrowserScan, IPHey and Pixelscan Explained: What Each Browser Check Measures

Browser checkers are popular because they turn an invisible thing, everything your browser tells a website about itself, into a page you can read. BrowserScan, IPHey and Pixelscan are three of the best known. They look similar from a distance: you load a page and get a list of values and some friendly labels. Underneath, they measure different things.

This post explains what each tool is looking at and how to read the output. It is written for QA testers, privacy-minded users and teams who run several client or storefront accounts they are entitled to hold, and who want to confirm that each browser profile is set up as intended. It is not a guide to scoring well. A checker is a mirror, not an exam.

See your own values first. We built a public checker at justbrowser.app/fingerprint-checker, client-side with no signup. It compares the WebRTC candidates against your public IP, and it checks whether the IP's location has a UTC offset that agrees with your browser's timezone. Worth running before you read the rest, so the signals below have your own values attached.

The short version

• BrowserScan leans toward the network side: IP and proxy information, WebRTC addresses, DNS and timezone agreement.
• IPHey leans toward the IP: what is known about the address, how it is classified, and a quick look at basic browser values.
• Pixelscan leans toward the device: whether canvas, WebGL, audio, fonts and navigator values describe one coherent machine.

None of them can tell you what a particular website will do. They show what your browser exposes.

Side-by-side: what each one shows

The table shows coverage. The sections below explain what each signal means.

What the network signals are

The IP address and its context

Every request reveals an IP address, and from it a rough location, an internet provider and sometimes a classification such as residential, business, hosting or mobile. IPHey puts this front and centre. It reports what is publicly known about the address, including whether it appears on common blocklists and how it is classified. That is useful for anyone choosing a proxy provider, because a datacenter address and a home connection are treated differently by plenty of ordinary websites, such as streaming services with regional rules.

WebRTC

WebRTC is the browser technology behind video calls. To set up a connection it can gather the machine's network addresses, including a local address such as 192.168.x.x and, in some configurations, the public address. If you route a browser through a proxy, the page should not be able to read a different public address through WebRTC. BrowserScan shows these candidates clearly, which makes it a handy way to confirm that a proxy setting covers WebRTC as well as ordinary requests. JustBrowser includes WebRTC protection per profile for exactly this reason: it is a privacy matter, since the profile's WebRTC does not expose the real IP.

DNS and timezone

If a browser's timezone says Tokyo, its language says German and its IP resolves to Frankfurt, the values disagree. For a QA tester that is a bug to find. For someone configuring a profile it is a setting to align. BrowserScan and IPHey compare the timezone with the IP's location, and a mismatch tells you which setting to fix. JustBrowser supports DNS-over-HTTPS per profile as well, so DNS lookups can follow the profile's own configuration rather than the host machine's.

The TLS handshake

Below the IP address sits the TLS handshake every HTTPS connection starts with, which describes the browser software at the network layer before a page loads. Our explainer on JA4 and TLS fingerprints covers what it reveals and why a proxy does not change it.

What the device signals are

Canvas and WebGL

Canvas and WebGL are graphics APIs. When a page asks the browser to draw something, tiny differences in the graphics stack, driver and hardware make the output slightly different from machine to machine. That is why these values are used as fingerprinting signals. A checker such as Pixelscan looks at whether the pieces fit together: if the WebGL renderer string names one GPU but the drawn output behaves like another, the values describe a machine that does not exist.

Audio context

The audio API works the same way. Processing a test tone produces output that depends on the audio stack. Pixelscan reads it as another device-level value.

Fonts

Installed fonts differ by operating system. A font list typical of one platform alongside a navigator that claims another is a contradiction. In JustBrowser the font list is restricted at the engine level to the set for the profile's platform identity.

Navigator and screen values

The navigator object carries the user agent, language, platform and hardware hints. Screen size, colour depth and pixel ratio describe the display. Pixelscan cross-checks these against each other. In a headless session the screen and viewport follow headless defaults, which is one reason a visible window and a headless one can report different values.

Reading the results

Look at individual signals, not the overall label. A friendly or alarming summary compresses many measurements into one word. The useful information is in the rows.

When two tools disagree, find the row. If one tool shows a WebRTC address and another does not mention it, you are looking at a difference in emphasis, not a contradiction. Open the detail and read the actual value.

Compare values with what you configured. If you set a profile to a Berlin proxy, German language and a Berlin timezone, those three rows should say so. If one does not, the setting has not been applied the way you meant.

Remember what a checker cannot know. It does not know a website's rules, its risk models or its policies. A tidy page here is not a prediction of how any site will behave, and it is not a reason to do anything a site's terms forbid. If a platform restricts an account, the right route is that platform's own appeal process.

Re-check after changes. A change to the proxy, timezone, language or identity settings is the moment to look again.

Where this is useful

• QA and testing. Confirm that a test profile for a given market reports the locale, timezone and screen you intended before you run a test pass against your own site.
• Privacy. See what your everyday browser exposes, and whether your VPN or proxy setup leaks a WebRTC address.
• Agencies and storefront teams. Confirm that each client profile has its own proxy and identity settings applied, so accounts you are allowed to hold stay separate. JustBrowser gives each profile its own cookies, storage, proxy and 40+ identity parameters, and team members can run profiles shared with them.
• Ad verification. Check that a profile set to a geography really presents that geography before you check how ads render. A pairing with ClickzProtect can help with click-quality questions on the traffic you verify.

For the GPU side in detail, the WebGL fingerprinting guide covers how rendering differences arise.

Cost and automation

All three tools are free to use and none requires an account. If you want to fold checks into a routine, JustBrowser's local REST API lets you start a profile and attach Playwright or Puppeteer to its CDP endpoint, but reading the checker pages is a manual step unless you build your own automation around them. The API is bound to 127.0.0.1 and authenticates with a Bearer token from the app's AI page. If you track the effect of your own sites' changes, JustAnalytics offers cookieless, privacy-first analytics.

Frequently Asked Questions

Why do BrowserScan and Pixelscan show different information for the same browser?

Each tool collects a different set of signals and presents them its own way. BrowserScan puts the network side first: IP, proxy hints and WebRTC. Pixelscan puts the hardware side first: canvas, WebGL, audio context and fonts. The same browser can look quite different through each lens because each one is showing different measurements.

How do I read the results when two tools disagree?

Treat each result as a list of measurements rather than a verdict. Find the individual signal that differs, such as the WebRTC address, the reported timezone or the WebGL renderer, and ask whether the value is what you configured. A disagreement usually points to one specific setting.

Do these tools tell me how a website will treat my browser?

No. They show what a browser exposes. What a given site does with those signals is its own decision, and the checkers do not know it. Use them to confirm your settings are applied as intended, not to predict anyone's reaction.

How often should I re-check a profile?

After any change to its proxy, timezone, language or identity settings, and whenever a profile starts behaving differently. Checking after a change is a quick way to confirm the configuration took effect.

---

Try JustBrowser

A multi-account browser for teams, built on a custom Chromium engine, not an extension. Real C++ engine patches at the canvas / WebGL / audio / font / screen layer, across 40+ identity parameters. REST API for Playwright, Puppeteer, Selenium. $9.99/month or $99.99/year. 7-day free trial, card required — cancel any time in the seven days and you are not charged. Unlimited profiles.

Get started → · How it differs from Multilogin / GoLogin / AdsPower