BRev Latency & jitter test — in your browser
An online ping test for latency and jitter, from your browser to Cloudflare, Google DNS or your own server — live median, jitter and loss. Browsers can't send ICMP ping, so it times small HTTPS requests and says so.
What this latency test actually measuresRead
Web pages are not allowed to send ICMP, so no ping test that runs in a browser can send real ping packets. This one says so and measures the nearest thing it can: the HTTPS round-trip time of a small request, timed with performance.now() from the moment fetch() sends it until the response headers come back. The first request to each target also pays for the DNS lookup, TCP connection and TLS handshake, so it is shown separately as connection setup and left out of the statistics; later samples reuse the warm connection. Three targets are built in: the nearest Cloudflare edge, which returns a zero-byte response made for timing, the ipify IP-address API, and Google Public DNS answering a query. You can add your own URL as well. Run 10, 25 or 50 rounds, or continuously, at 250 ms, 500 ms or 1 s intervals, and watch median, jitter and loss update as each sample lands. A sample that fails or takes longer than 5 seconds counts as loss.
What you can do
- HTTPS round-trip timing with fetch() and performance.now(), labelled as such rather than presented as ICMP ping
- Three built-in targets, Cloudflare edge, ipify API and Google DNS, each with a line saying what its number measures
- A custom target for your own URL, with “Retry in opaque mode” for servers that do not send CORS headers
- 10, 25 or 50 rounds, or ∞ continuous, at intervals of 250 ms, 500 ms or 1 s
- Median, min, max, jitter, loss and success streak per target, plus p95 in the Summary table
- A sparkline of the last 50 samples per target, shaded at 80 ms and 150 ms, with a red tick for every lost sample
- The first request reported as connection setup and excluded, so DNS, TCP and TLS setup cannot inflate the median
How to use ping & latency test
- Pick your “Targets”Cloudflare edge, ipify API and Google DNS are all selected at the start; press one to leave it out. Targets are locked while a test is running.
- Add your own server with “Add target”Type an address in “Custom target — https://your-server.example” and press Add target; an address without http:// or https:// gets https:// in front. The new target joins the list already selected.
- Choose “Rounds” and “Interval”The default is 25 rounds at 500 ms. ∞ continuous keeps sampling until you press Stop.
- Press “Start test”Every selected target is sampled in parallel. The large figure is the Cloudflare edge median, or the first selected target's when Cloudflare is off.
- Press “Copy results”The button on the Summary table copies a plain-text report with each target's median, min, max, jitter, p95, loss and connection-setup time.
FAQ
Is this a real ping test?
Not in the ICMP sense, because web pages cannot send ICMP packets. It times small HTTPS requests instead, which read slightly higher than an ICMP ping because each request adds a little HTTP work. On a warm connection the figure tracks network latency closely without ever reading below it, and it is the delay web apps actually experience.
What is a good ping for gaming and video calls?
The tool grades the median: under 30 ms is Excellent, under 80 ms Good, under 150 ms Fair and 150 ms or more Poor. The bands describe how interactive use feels, not a technical standard. Check which target you are reading, too: the Cloudflare edge is the path to the nearest Cloudflare data centre and usually reads lowest, while ipify and Google DNS cross more of the internet.
How is jitter calculated?
Jitter here is the average absolute difference between successive successful samples, in the style of RFC 3550, rather than a standard deviation. That is the sample-to-sample variation calls and games feel: 40 ms with 2 ms of jitter feels better than 25 ms with 30 ms of jitter. High jitter usually points to a congested link or busy Wi-Fi.
How does the packet loss figure work?
A sample counts as lost when the request fails, returns an HTTP error status or runs past its 5-second budget. So the figure counts failed requests, not dropped ICMP packets. Lost samples show as red ticks on the sparkline, and the warm-up request is never counted.
Why is the first request so much slower?
The first request to a target has to set up the connection: a DNS lookup, a TCP connection and a TLS handshake. The tool marks it as a warm-up, shows its time as connection setup and leaves it out of every statistic. If the test pauses because you switched to another tool in the workspace, it takes a fresh warm-up sample when it resumes, excluded in the same way.
Can I test the latency to my own server?
Yes: enter its address under Custom target and press Add target. The browser lets the page read the response only if the server sends CORS headers; if every sample comes back blocked, the tool offers Retry in opaque mode. Opaque mode still times the round trip but cannot see the response, so it cannot confirm the request succeeded, and even an error page counts as a sample.
Does BRev see my results?
No. Requests go from your browser straight to the targets you pick: speed.cloudflare.com, api.ipify.org, dns.google and any custom URL, each of which receives an ordinary web request from your connection. BRev has no server in that flow and never receives your results. Like every page on the site, this page loads Google Analytics.