Free tool · no account

What your browser
gives away.

A proxy changes where your requests come from. It does not change your timezone, your GPU string, or the address your browser hands to a STUN server over UDP. This page measures all three, and everything runs locally — no results are sent to Unblocked.

Not run Verdict

Nothing measured yet

Run the suite to see what this browser gives away. Nothing is sent anywhere — every test below runs locally.

01 Network

Where you
actually are.

The WebRTC test is the one that matters. Everything else on this page describes your device; this one can hand over your real IP address while every request on the page still exits through your proxy.

Exit address

The IP, network and location an ordinary HTTP request arrives from.

Not run

Not measured yet.

WebRTC / STUN leak

Asks public STUN servers over UDP what address your packets came from, then compares that against your HTTP exit.

Not run

Not measured yet.

Timezone vs exit country

A proxy in Frankfurt driven by a browser reporting America/Chicago is the cheapest mismatch there is to catch.

Not run

Not measured yet.

02 Device

The parts that
survive a new IP.

Each surface is read twice and the two reads compared. Identical means you have a stable identity that follows you between sessions. Different means something is injecting noise — which is a finding of its own, because a site can detect it exactly the same way.

Canvas fingerprint

Text and shapes rasterised to a bitmap, then hashed. Differs by GPU, driver and installed fonts.

Not run

Not measured yet.

WebGL & GPU

Your graphics stack, its limits and the unmasked renderer string.

Not run

Not measured yet.

Audio stack

An oscillator rendered offline through a compressor. Nothing is played aloud.

Not run

Not measured yet.

Installed fonts

Which of 100 common fonts are present, detected by measuring text width.

Not run

Not measured yet.

03 Consistency

Contradictions
are the tell.

Anti-bot systems rarely block you for having an unusual fingerprint. They block you for having an impossible one — a Windows User-Agent on a machine whose GPU reports as Apple, or a mobile browser with no touch support.

Automation & consistency

Contradictions between what your browser claims and what it demonstrably is. This is what anti-bot vendors actually grade you on.

Not run

Not measured yet.

04 Server-side

Three things this
page cannot measure.

These are real checks and they matter, but none of them can be done from JavaScript. Rather than omit them quietly or show a plausible-looking hash, they are listed here with what they need in order to work.

TLS fingerprint (JA3 / JA4)

The shape of your TLS ClientHello — cipher order, extensions, curves, ALPN.

Needs server

Requires a server that can observe your raw ClientHello. JavaScript never sees the TLS handshake, so no page can compute this client-side.

Why it matters
A Chrome User-Agent over a Python TLS stack is caught here before a single header is read.
Status
Ships with the /api/echo endpoint.

HTTP header order

The exact order and casing of the headers your client sends.

Needs server

Requires a server that records headers as received. fetch() cannot read back what it sent, and header order is normalised away before JavaScript sees it.

Why it matters
Real browsers emit a fixed header order per version. HTTP libraries rarely reproduce it.
Status
Ships with the /api/echo endpoint.

DNS leak

Which resolvers actually looked up the names your browser requested.

Needs server

Requires authoritative nameservers we control, so a unique subdomain per test can be traced back to the resolver that asked for it.

Why it matters
A proxied HTTP session whose DNS still resolves through your ISP identifies you by resolver.
Status
Needs delegated DNS infrastructure — tracked separately.
05 How it works

How a WebRTC
leak happens.

WebRTC exists so browsers can send video and audio directly to each other without relaying everything through a server. Before two browsers can do that, each has to work out how it is reachable from the outside — which is harder than it sounds, because most machines sit behind a router doing network address translation and have no idea what their public address is.

The solution is STUN. The browser sends a UDP packet to a public STUN server and the server replies with a single useful fact: this is the address your packet arrived from. That reply becomes a srflx — server reflexive — ICE candidate, and JavaScript on the page can read it.

Here is the problem. That exchange is UDP, sent directly from your operating system's network stack. An HTTP or SOCKS proxy configured in your browser only redirects HTTP traffic. A VPN redirects more, but unless it captures all UDP the STUN packet can still take the direct route. So the address the STUN server sees is often your real address, even while every image, script and API call on the page is exiting cleanly through your proxy.

That is why this tool does not simply print the address STUN returns. It fetches your HTTP exit address separately and compares the two. One address means no leak. Two different addresses means the second one is your real connection, and any site you visit can read it in about five lines of JavaScript.

What the candidate types mean

  • host — an address belonging to this machine. Normally a private LAN address, or on a modern browser an mDNS .local hostname, which is the browser deliberately protecting you. A routable address here is the worst case: no STUN server was even needed.
  • srflx — what a STUN server saw. This is the one the leak test turns on.
  • relay — traffic routed through a TURN relay. You will only see these if a TURN server was configured; this page does not use one.

Why five STUN servers

Because one is not safe. If a single STUN server were unreachable — blocked by a firewall, rate limited, temporarily down — the test would gather no reflexive candidate and could report "no leak" when the truth is "no measurement". For a tool whose entire job is to tell you whether you are exposed, that is the most dangerous failure available. Querying five independent servers makes a false all-clear far less likely, and the page tells you how many candidates were gathered and whether gathering finished so you can judge for yourself.

What we do not do

No result on this page is stored, logged or transmitted to Unblocked. There is no account and no rate limit, because there is nothing to rate limit — the tests execute in your browser. The single exception is the exit address lookup, which by definition requires a request to something outside your machine; the page names which third-party provider answered so you can see exactly where that went.

06 FAQ

Questions,
answered properly.

What is a WebRTC leak?

WebRTC lets browsers talk directly to each other for video and voice. To do that, your browser has to discover how it is reachable, so it asks a public STUN server what address your packets appear to come from. That exchange happens over UDP from your own network stack — it does not go through an HTTP proxy, and unless your VPN captures all UDP traffic it does not go through that either. The result is that a website can read your real IP address from JavaScript while every other request on the page still exits through your proxy.

Does a proxy stop a WebRTC leak?

Usually not on its own. An HTTP or SOCKS proxy configured in the browser changes where HTTP requests go, but WebRTC opens its own UDP sockets. Unless the browser is explicitly told not to use non-proxied UDP, STUN traffic bypasses the proxy entirely. This is why the test on this page compares the STUN-reflexive address against your HTTP exit address rather than simply reporting whichever one it finds.

How do I fix a WebRTC leak?

In Firefox, set media.peerconnection.enabled to false in about:config. In Chrome or Edge, use an extension such as WebRTC Network Limiter set to disable non-proxied UDP. If you are using an anti-detect browser, configure it to report the proxy exit address through WebRTC rather than to switch WebRTC off, because a browser with no WebRTC stack at all is itself unusual enough to be a detection signal.

Is a stable canvas or WebGL hash a problem?

Not by itself. A stock browser produces the same canvas, WebGL and audio hashes on every read, and that is what the overwhelming majority of real visitors look like. It only becomes a problem when you need several sessions to look like several different people, because a stable hash links them together regardless of IP address. This page reports whether each surface is stable or randomised so you can tell which situation you are in.

Why does the tool flag randomised fingerprints?

Randomisation is reported as information rather than as a pass. Injecting fresh noise into canvas or audio on every read defeats naive fingerprinting, but the randomisation is itself measurable: this page detects it simply by reading each surface twice and comparing. A site that does the same can tell that noise is being injected, and some treat that as a stronger signal than the fingerprint it was meant to hide.

Why can this page not show my JA3 or JA4 TLS fingerprint?

A TLS fingerprint is derived from the raw ClientHello your client sends when it opens the connection — the cipher list, extensions, elliptic curves and their exact order. That handshake completes before any JavaScript runs, and the browser never exposes it to a page. Computing JA3 or JA4 requires a server that observes the connection itself, so those checks are listed here with an honest status instead of a fabricated hash.

Do you store my results?

No. Every check on this page runs in your browser and the results are never sent to Unblocked. There is no account, no signup and no log. The one exception is the exit address lookup, which necessarily contacts a third-party IP geolocation provider — the page names which provider answered so you can see exactly what happened.

Why does my timezone matter if my IP is clean?

Because it is the cheapest possible contradiction to check. Reading the browser timezone takes one line of JavaScript, and comparing it against the country your IP resolves to takes one more. A proxy exiting in Frankfurt driven by a browser reporting America/Chicago fails that comparison instantly, no matter how good the IP is. The same applies to your language list, screen metrics and GPU strings.

Fixed the leak?

Now get an IP
worth hiding.

Dedicated ISP and residential proxies on real carrier subnets. Run this test again once you're behind one — the exit address should be the only thing that changes.