How to Test Your Antidetect Browser Setup (Complete Checklist)

Alright, real talk. I've seen way too many people set up an antidetect browser, run one quick test on browserleaks, see green checkmarks, and call it a day. Then three weeks later they're wondering why their accounts got linked.

Testing properly takes maybe 20 minutes. I'm gonna walk through everything I check when I set up a new profile. Some of this is obvious, some of it isn't. Learned most of it the hard way.

Before you start

You need at least two profiles configured with different fingerprint settings. The whole point is to verify they actually look different to websites. One profile tells you nothing - you need comparison.

Also, keep a notepad open. You'll want to write down hashes and values so you can compare across profiles without switching back and forth like a maniac.

Step 1: Basic fingerprint check

Open browserleaks.com/javascript in your profile.

What to look at:

• navigator.userAgent - does it match your spoofed config?
• navigator.platform - if you set macOS, does it say MacIntel?
• navigator.hardwareConcurrency - should match your config, not your real CPU
• navigator.deviceMemory - same deal
• screen.width and screen.height - match the spoofed resolution?

Common failure: userAgent says Chrome 120 on Windows but platform says "MacIntel". That's an instant flag. Your antidetect setup should keep these consistent.

How to fix: Make sure your fingerprint config generates matching values. Platform, userAgent, and Client Hints all need to agree on the same OS.

Step 2: Canvas fingerprint comparison

Go to browserleaks.com/canvas in Profile 1. Copy the canvas hash.

Open the same page in Profile 2. Compare the hash.

Pass: Different hashes between profiles. Neither matches your real browser's hash.

Fail: Same hash across profiles, or hash matches what you get in a regular Chrome window.

This is the single most important test. Canvas fingerprinting is the backbone of most detection systems. If your canvas isn't properly spoofed, nothing else really matters.

How to fix: Check that canvas noise injection is enabled and using different seeds per profile. A common mistake - setting the same seed for all profiles. That gives you spoofed but identical fingerprints. Defeats the whole purpose.

Step 3: WebGL consistency

Still on browserleaks, go to the WebGL section. Check:

• WebGL Vendor - should show your spoofed GPU vendor
• WebGL Renderer - should match the spoofed GPU model
• Unmasked Vendor / Renderer - this is the critical one

Pass: Vendor and renderer match your spoofed config. Different between profiles (if you configured different GPUs).

Fail: Shows your real GPU. "ANGLE (NVIDIA GeForce RTX 4090 Direct3D11)" when your config says Intel HD 630.

Tricky part: the spoofed GPU needs to be realistic. Claiming an Intel Iris Xe GPU with a 4K resolution and 32GB device memory doesn't make sense. Detection systems check for consistency between hardware parameters.

How to fix: Use fingerprint configs where GPU, screen resolution, and device memory are internally consistent. A laptop GPU shouldn't be paired with a 3840x2160 screen and 32GB RAM.

Step 4: WebRTC leak test

This one catches people all the time. Go to browserleaks.com/webrtc.

Pass: Either WebRTC is disabled (no IP shown) or it shows your proxy IP only.

Fail: Your real local IP (192.168.x.x or 10.x.x.x) or your real public IP appears alongside or instead of the proxy IP.

I wrote about this in more detail here, but the short version: WebRTC can bypass your proxy and reveal your real IP through STUN requests. Most antidetect browsers let you set WebRTC to "disable" or "fake." Use one of those.

How to fix: Set WebRTC mode to "disable" in your profile config. If you need WebRTC for video calls or whatever, use "fake" mode - but test it carefully.

Step 5: Client Hints verification

This one's newer and lots of setups miss it. Open DevTools (F12), go to Console, type:

navigator.userAgentData.getHighEntropyValues([
  "platform", "platformVersion", "architecture",
  "model", "bitness", "fullVersionList"
]).then(v => console.log(v));

Pass: Values match your spoofed config. Platform says "Windows" if your UA says Windows. Architecture says "x86" if you're spoofing an x86 machine.

Fail: Client Hints say "Windows" but your userAgent says macOS. Or architecture says "arm" when everything else says x86.

Websites are moving from userAgent parsing to Client Hints. Chrome has been pushing this for a while. If your antidetect handles the old userAgent string but ignores Client Hints, newer detection code will catch you.

How to fix: Make sure your antidetect tool spoofs navigator.userAgentData including brands, platform, architecture, and bitness. All of it needs to match.

Step 6: Worker fingerprint test

This is the one most people skip. Also the one that catches the most setups.

Go to creepjs.com or abrahamjuliot.github.io/creepjs/. Scroll down to the Web Worker section.

What to compare:

• Worker hardwareConcurrency vs main thread value
• Worker platform vs main thread platform
• Worker canvas hash (via OffscreenCanvas) vs main thread canvas hash

Pass: All Worker values match the main thread spoofed values.

Fail: Worker shows your real hardware (e.g., 16 cores when main thread says 4).

I wrote a whole article about this because it's that important. Blob URL Workers and ServiceWorker fingerprinting are where most antidetect tools completely fall apart. If your tool doesn't intercept Worker/Blob constructors at document_start, you're leaking.

How to fix: This is hard to fix manually. Your antidetect tool either handles it or it doesn't. If Workers are leaking, you probably need a different tool.

Step 7: Timezone and language consistency

Sounds basic. It's not.

Check browserleaks.com/javascript for:

• Date().getTimezoneOffset() - should match your spoofed timezone
• Intl.DateTimeFormat().resolvedOptions().timeZone - should match
• navigator.language - should be plausible for your timezone

Pass: Timezone says "America/New_York", offset is 300 (or 240 in DST), language is "en-US".

Fail: Timezone says "Asia/Tokyo" but language is "en-US" and your IP is in Germany. Three different stories.

People overlook this combo more than anything. Your IP location, timezone, and language all need to tell the same geographic story. A Japanese timezone with English language and a German IP is suspicious as hell.

How to fix: When setting up profiles, pick a location and make everything match. IP (proxy), timezone, language, locale. If your proxy is in the US, use a US timezone and English language.

Step 8: Extension detection

Some sites try to detect installed extensions. Check z0ccc.github.io/extension-fingerprints/.

Pass: No unexpected extensions detected.

Fail: Your antidetect extension shows up, or common extensions (MetaMask, password managers) are visible across profiles.

This is mostly relevant if you're using browser extensions that expose web-accessible resources. MetaMask, for example, used to be trivially detectable. Less so now, but still possible.

How to fix: Minimize extensions per profile. Don't install the same set of extensions in every profile - that creates a linkable pattern. If you need MetaMask in all profiles, at least make sure other extensions differ.

Step 9: IP reputation and DNS

Almost done. Check your proxy IP:

• ipinfo.io or ipqualityscore.com - is it flagged as datacenter/proxy?
• browserleaks.com/dns - DNS servers should match your proxy location, not your real ISP

Pass: IP shows as residential, location matches your timezone/language config, DNS resolves through the proxy.

Fail: IP flagged as "datacenter" or "VPN", DNS leaks to your real ISP.

A perfect fingerprint with a datacenter IP is like wearing a disguise but driving your own car. The proxy vs VPN decision matters here - residential proxies score better than datacenter ones for most use cases.

How to fix: Use residential proxies for sensitive profiles. Check that DNS isn't leaking through your real connection. Some proxy setups only tunnel HTTP traffic and let DNS go through your ISP.

The comparison test

After running all profiles through these checks, put your results side by side. What you want to see:

• Different canvas hashes per profile
• Different WebGL renderers per profile (if configured)
• Different hardware values per profile
• Consistent values within each profile (main thread = Worker = Client Hints)
• Each profile's IP/timezone/language telling the same geographic story

What's a red flag:

• Identical values across profiles (especially canvas, audio)
• Mismatched values within a profile (main thread vs Worker)
• Geographic inconsistency (Tokyo timezone, German IP, English language)

How often to test

I test after initial setup, obviously. But also after:

• Browser or extension updates (updates can reset spoofing)
• Adding new extensions to a profile
• Changing proxy providers
• Any time something "feels off" (accounts getting flagged, captchas increasing)

Every couple of weeks at minimum if you're running profiles for anything that matters.

The "good enough" question

Look, perfection isn't realistic. ServiceWorker fingerprinting is hard. Some edge cases will leak. CreepJS will always find something to complain about.

The goal isn't a perfect score on every test site. It's making your profiles look like plausible, distinct devices that can't be linked to each other or to your real machine. If your canvas is different, WebGL is consistent, WebRTC isn't leaking, Workers match the main thread, and your IP/timezone/language all agree - you're ahead of 95% of setups out there.

But skip any of these checks and you're just hoping. And hope is not an opsec strategy.

Grab a coffee, spend 20 minutes, test properly. Your accounts will thank you.