Why can't in-browser tools read exact HTTP status codes (e.g. 404 or 500) for all sites?

The web browser's Same-Origin Policy (SOP) restricts client-side scripts from reading HTTP headers or exact response status codes from third-party domains unless the destination server explicitly returns Access-Control-Allow-Origin headers. Tools claiming to read status codes client-side for arbitrary sites without a backend proxy fabricate those values.

Are my tested domains or diagnostic results stored permanently?

No. All network requests originate directly from your local browser sandbox. Target URLs and test results are not transmitted to or stored on MicroToolStack servers.

Real-Time Network Telemetry

Website Reachability & Server Latency Probe

Q: How does a client-side network probe test website reachability?

The probe dispatches a cross-origin network request with strict cache-busting parameters. By measuring the duration between the initial socket handshake and the arrival of response headers, it calculates client-to-server round-trip time (RTT) and confirms host connectivity.

Q: What causes a destination server to appear unreachable?

A server may appear unreachable due to DNS lookup failures, expired TLS certificates, firewall blocks (such as Cloudflare or WAF rate-limiting), server downtime, or network connection timeouts exceeding 8 seconds.

Verify host connectivity and test client-to-server handshake latency in real time directly from your browser session.

🌐 Server Handshake Probe

Sample Domain Targets:

Target Website or API URL *

🟢 REACHABLE (Handshake Succeeded)

Target Host: https://www.google.com

Network Reachability

Connected

Handshake Round-Trip (RTT)

-- ms

Probe Timestamp

--:--:--

1. The Mechanics of Client-Side Network Probing

A client-side reachability probe evaluates whether an origin web server or Content Delivery Network (CDN) is actively listening and completing network handshakes from your geographic location and ISP.

When you initiate a check, this tool dispatches an asynchronous network probe configured with unique cache-busting query strings. Measuring the exact time elapsed between request dispatch and response acknowledgment reveals the true client-to-server Round-Trip Time (RTT), reflecting local routing and remote server responsiveness.

2. Handshake Latency Benchmarks

Round-Trip Latency	Performance Tier	Operational Implication
< 150 ms	High Performance	Optimal network routing, edge CDN termination, and low connection overhead
150 ms – 450 ms	Moderate	Acceptable latency for intercontinental requests or direct origin handshakes
> 450 ms	High Latency	Signifies network congestion, missing CDN acceleration, or geographic distance
Timeout (> 8000 ms)	Unreachable / Dropped	Server down, packet drop, firewall block, or unreachable DNS resolution

3. Technical Limitations & Browser Security Constraints

Same-Origin Policy (SOP) & Opaque Responses: Due to fundamental browser security models, JavaScript running in a web page cannot inspect HTTP response headers, response bodies, or 3-digit status codes (like 404 or 500) for cross-origin domains unless the destination server explicitly returns permissive CORS headers.
Reachability vs. Application State: This probe verifies whether the destination host completes network handshakes without dropping connections. It does not verify internal application errors that may occur behind a functioning web server proxy.
Client Firewalls & Ad Blockers: Aggressive browser extensions or local network firewalls blocking third-party requests may cause false-negative unreachable readings.

4. Execution Architecture & Privacy Transparency

All network probes execute directly within your local web browser session using client-side JavaScript APIs. Target domains and test latencies are never routed through or stored on MicroToolStack servers.

Standard analytics (Google Analytics) and display advertising scripts (Google AdSense) operate on this site for operational metrics and ad delivery in accordance with our Privacy Policy.

5. Explore Related Developer Utilities

6. Frequently Asked Questions

How does a client-side network probe test website reachability?

The probe dispatches a network request with cache-busting tokens, calculating the elapsed round-trip time (RTT) between dispatch and handshake acknowledgment.

Why can't in-browser tools read exact HTTP status codes for all sites?

Browsers enforce the Same-Origin Policy (SOP). Cross-origin endpoints that do not supply permissive CORS headers return opaque responses, preventing client scripts from reading HTTP status codes.

What causes a destination server to appear unreachable?

Common causes include DNS resolution failure, expired TLS certificates, firewall rate-limiting, server outages, or connections exceeding the 8-second probe timeout.

Are target domains or latency tests logged on any server?

No. All probes run directly from your local browser. Target URLs and test measurements are not logged on remote infrastructure.