Browser Check
See what your browser reveals about itself: the automation flags, headless tells and request headers that anti-bot systems read on every visit.
The browser checks run entirely on this page. No fingerprint is sent to CheckNet, stored or logged. The request-header section reads only the headers your browser already sent when it asked for this page, and keeps none of them.
Running browser checks...
The request-header signals are available programmatically. The browser probes are not: they need a real browser, so they only run on this page.
Run these with curl and you will see them score as automated, because curl sends its own User-Agent and none of the metadata a browser does. That is the point.
Request headers
What your browser sent before any JavaScript ran. These headers arrive with the very first request, which makes them the earliest signal a site can act on.
- User-Agent sent↑ Back to result
What it is Whether the request carried a User-Agent header at all.
Why it matters Every browser sends one. Its absence points to a hand-rolled client that did not bother.
- Known automation client↑ Back to result
What it is Whether the User-Agent names a known scripted HTTP client.
Why it matters Most tools identify themselves honestly: curl, python-requests, Playwright. Anything that would rather not be recognised has to lie, which the Client Hints checks then catch.
- Accept-Language sent↑ Back to result
What it is The languages the client asks content to be served in.
Why it matters Browsers always send this because it drives content negotiation. Scripted clients rarely set it.
- Accept is browser-shaped↑ Back to result
What it is The content types the client says it can handle.
Why it matters A browser lists the concrete types it can render. A bare */* is the catch-all default of an HTTP library.
- Sec-Fetch metadata complete↑ Back to result
What it is Metadata the browser attaches describing why it made the request.
Why it matters The browser sets these itself, and page JavaScript cannot change them, though any HTTP client can send them by hand. Scripted clients usually send none at all.
- Client Hints sent↑ Back to result
What it is The Client Hints form of the browser's identity.
Why it matters A request whose User-Agent claims a Chromium browser but sends no usable hints is contradicting itself. This also fires when the header is present but does not list any brands.
- Client Hints version agrees↑ Back to result
What it is The browser version in the User-Agent compared with the version in the hints.
Why it matters The two come from different code paths, so a rewritten User-Agent usually updates one and forgets the other. This is the strongest evidence here of a spoofed identity.
- Client Hints platform agrees↑ Back to result
What it is The operating system named in the User-Agent compared with the one in the hints.
Why it matters Same reasoning as the version check. A request claiming macOS in one place and Windows in the other cannot be genuine.
- Client Hints form factor agrees↑ Back to result
What it is Whether the User-Agent and the hints agree about being a phone.
Why it matters Clients that paste in a mobile User-Agent string often leave this hint at its desktop default.
- Brotli offered↑ Back to result
What it is The compression formats the client is willing to accept.
Why it matters Current browsers all offer Brotli. Minimal HTTP clients tend to offer gzip alone.
- Upgrade-Insecure-Requests sent↑ Back to result
What it is A header browsers send to say they would rather have the secure version of a page.
Why it matters Browsers send it on page navigations. Scripted clients and background fetches do not, including this page's own API calls, so a missing one is weak evidence by itself.