Every support conversation about a broken connection starts the same way: what browser, what version, what operating system, what screen, are you on Wi-Fi, who is your provider. Most people cannot answer, and the ones who can answer wrongly. This page runs every check at once and gives you one plain-text block to paste into the ticket — network, browser and device together, measured in your browser, uploaded nowhere.
What the report actually contains
Three groups, because a support agent is usually trying to decide which one is at fault.
Network— your public IP and its version, the organisation that owns it and its ASN, the reverse hostname, an approximate location, whether the address sits in carrier-grade NAT space, whether a VPN or proxy looks likely, the connection type the browser reports, a median latency taken from a short burst rather than a single sample, and the TLS version and cipher this connection actually negotiated — which the browser cannot tell you about itself, because it is the edge that terminates the handshake and reports what was agreed.
Browser — name and version, rendering engine, operating system, accepted languages, timezone, whether cookies are enabled, whether local storage can actually be written, and the Do Not Track header. The storage check matters more than it looks: storage being blockedis a common cause of "the site keeps logging me out", and it is invisible unless something tries to write.
Device — device class, physical screen size and its common name, the viewport, pixel ratio, colour depth, GPU string, CPU cores and reported memory. Physical resolution and viewport are different numbers and both matter; a layout bug that only appears at one pixel ratio is otherwise very hard to reproduce.
Why one page instead of ten
Each of these checks exists on its own elsewhere on this site, and each is better on its own page if that is the one question you have. The reason to run them together is that a support ticket needs all of them and a person collecting them by hand will miss half and mistype the rest. One pass, one block of text, one paste.
It also makes the answers consistent with each other. Latency measured at the same moment as the connection type tells you something; the same two numbers gathered ten minutes apart on a link that fluctuates tell you very little.
Reading a value marked unavailable
Some rows will say unavailable, and that is a real answer rather than a failure. Browsers deliberately withhold several of these. The GPU string is hidden or generic in Safari and in Firefox with resistFingerprinting enabled. Device memory and CPU cores are not exposed everywhere. Do Not Track has been removed from some browsers entirely. The report counts how many checks resolved so you can see the gaps rather than assume a blank means zero.
What it deliberately cannot see
A web page has no access to your router, your local IP, your DNS server, the other devices on your network, or anything outside plain HTTPS. If a support agent needs your router's WAN address — for a port-forwarding problem, say — you have to read it off the router yourself; the CGNAT test walks through that. Throughput is also not included here on purpose: a proper speed test takes fifteen seconds of saturated link and belongs on the speed test, not in a summary you want to run quickly.
Related tools
For one answer rather than all of them: IP address, ISP lookup, browser details, screen resolution, ping and latency, and VPN leak test.
Privacy note
Every value is read in your browser. The only request that leaves is the one that asks our server what public IP your connection presents — which it can see anyway, because you are connected to it. The report is never transmitted or stored; the copy button puts it on your clipboard and nowhere else. Your IP is masked in the copied text by default, because a ticket often ends up in a shared inbox. Untick that if the agent needs the full address, and read the text before you send it.