Pull to refresh
clikit.pro
Detecting your network…
Finding measurement servers…
Internet provider
Detecting…
The live graph appears when the test starts
This measures real data transfer between this device and the test server — not the speed printed on your plan. Wi-Fi, your device, VPNs, other traffic and the route to the server all affect it, so a result a little under your plan is normal. A test uses real data: about 2.5 MB for every 1 Mbps of speed (roughly 100 MB at 40 Mbps).
Run a test to see latency under load, jitter, stability and the other diagnostics here.
Comparison needs at least two available measurement servers. Only none are reachable from your network right now.
Privacy. Your results and history stay in this browser — clikit.pro does not store them. To show your provider, our server looks up your IP address with an IP registry service; that lookup is not logged or saved. Test data is exchanged with the server shown above; like any server it sees your IP address while the test runs. Cloudflare-edge tests are not published. Tests that run on Measurement Lab are different: M-Lab is a public research platform and publishes every test, including your IP address, as open data. We never ask for your precise location or fingerprint your device.
Saved only in this browser. Nothing is uploaded.
No tests yet. Your results will appear here after your first test.
Available servers are probed from your device and one is chosen by measured latency and reliability — not by map distance. It is checked again right before any bulk data is sent, and the test moves to another server if it fails.
A series of small probes is timed on a quiet connection. From them we report ping (median) and jitter.
Random, uncacheable data is streamed to your browser. Connections are added only while they increase throughput. After a short warm-up, bytes received divided by elapsed time gives your download speed.
The same process in reverse, over several connections. Only bytes the server confirms it received are counted — never what the browser merely queued to send.
Latency probes keep running during both transfers. The difference from idle latency shows how your connection behaves under load.
We check how steady the transfer was, how long the measured window lasted and whether anything interrupted it, and state how confident we are in the result.
No single browser test is a definitive measurement of your ISP’s service. Treat each result as one observation of the path between this device and our server.
Download speed is how fast data travels from the internet to your device, in megabits per second (Mbps). It decides how quickly pages load, videos buffer and files arrive.
Upload speed is how fast data travels from your device to the internet. It matters for video calls, sending files, cloud backups and live streaming. On many home plans it is much lower than download speed.
Ping (latency) is the time a small message takes to reach the server and come back, in milliseconds. Lower is better. We send a series of probes and report the median, with the minimum, average and maximum in the details.
Jitter is how much latency changes from one moment to the next. We calculate it as the average absolute difference between consecutive latency samples. High jitter makes calls and games feel uneven even when average ping is low.
It is your latency while the connection is busy downloading or uploading. If it rises a lot compared with idle latency, your router or modem is queueing too much data (often called bufferbloat), and calls or games will lag whenever someone else is using the connection heavily.
Each test is a snapshot. Wi-Fi signal, other devices on your network, background downloads, your device and browser, VPNs, time of day, the route to the measurement server and how busy that server is all change the result. Two tests a minute apart can legitimately differ.
It should be close, but not identical. The test measures real data between this device and a nearby internet server; your plan speed describes the line itself. Wi-Fi, device limits and routing sit in between, so a result a little under your plan is normal even when the line is fine.
Use a wired Ethernet connection if you can, or stay close to the router. Pause downloads, cloud backups and streaming on every device, turn off your VPN if appropriate, close other tabs, and run the test several times at different times of day.
A single upload connection from a browser can be held back by the sender's own buffer limits — in our testing Chrome and Edge on Windows sometimes reached only a fifth of the real line speed over one connection. Sending over several connections at once lets the upload reliably reach what your line can carry.
Every server you connect to sees your public IP address. We look that address up in a public IP registry to find which network it belongs to (for example Airtel or Jio) and roughly where it is registered. The city is approximate and can be wrong. If you use a VPN, you will see the VPN provider instead.
Web pages talk over TCP, which quietly re-sends lost packets, so a browser cannot count them. Real packet loss can only be measured through a WebRTC relay next to the measurement server. Where that is not available we say so instead of estimating a number.
It depends on your speed, because the test sends real data for a fixed time. A slow connection uses a few megabytes; a very fast one can use several hundred. Avoid repeated tests on a metered or mobile plan.
clikit.pro does not. Results and history are saved only in your browser, the IP lookup is not logged, and share links carry just the headline numbers. The test server you measure against sees your IP address while the test runs, as any server does. One exception is stated before you start: tests that run on Measurement Lab are published by M-Lab, with the IP address, as open research data.