Load Tester
See how your own API behaves under load: send many requests with virtual users or at a steady rate, and watch requests per second, latency percentiles and errors in real time. It runs against apps on your own machine or local network (localhost and private addresses). For a full stress test, export a ready-to-run k6, JMeter, Artillery, autocannon, hey or vegeta script from the same settings.
Placeholders are replaced in each request: {{uuid}}, {{randomInt}} (or {{randomInt:1:100}}), {{randomString}}, {{timestamp}}, {{index}} (request number). They work in the URL, headers and body.
Results
Requests / second & errors
Response time over test (ms)
Run a bigger test elsewhere
The browser can only push so many requests, and it can't reach APIs that block cross-origin calls. For a real stress test, copy a script for a dedicated tool. It uses the request and settings above.
What this load tester is for
It answers questions like “does my API stay fast with 50 users hitting it?”, “which endpoint slows down first?” and “does it start returning errors or leaking memory under steady traffic?”. It sends real HTTP requests from your browser and measures how long each one takes, then shows the throughput, the latency percentiles and every status code it saw.
Because it runs in a browser tab, it is meant for your own services during development, reached at localhost, 127.0.0.1 or a private network address. Requests to public sites are blocked, both because browsers stop a page from reading responses from other origins and because hammering someone else's server without permission isn't OK.
Load profiles
| Profile | What it does |
|---|---|
| Fixed virtual users | A set number of “users” each send a request, wait for the reply (plus any think time), then send the next, for the whole duration. This is a closed model: a slow server means fewer requests, like real users waiting. |
| Ramping virtual users | Step the number of users up and down over several stages, for example 0→20 over 30s, hold at 20 for a minute, then down to 0. Good for finding the point where latency climbs. |
| Target requests/second | Fire a fixed rate regardless of how fast replies come back (an open model), up to a ceiling of in-flight requests. Good for checking a throughput target. |
Reading the numbers
- Requests/second (throughput) is how many completed per second.
- p95 / p99 latency is the time under which 95% / 99% of responses came back. These matter far more than the average: a good average can still hide a slow tail that real users feel.
- Error rate counts failed requests: a non-2xx/3xx status, a timeout, or a dropped connection.
Why your numbers are lower than a real tool's
A browser limits how many connections it opens to one server (around 6 on HTTP/1.1, more on HTTP/2) and adds its own per-request overhead, so expect roughly hundreds to a few thousand requests per second at most. That is plenty to compare endpoints and spot regressions, but it is not your server's true ceiling. For that, run one of the exported scripts — k6, autocannon and the others generate the real load from your machine or CI, using the same request and settings.
Letting the browser reach your app (CORS)
Your app has to allow requests from this page. In development that is usually one line (Express app.use(require('cors')()), FastAPI's CORSMiddleware, Spring's @CrossOrigin, and so on). The Check connection button tells you whether your server is reachable and whether CORS is on before you start. Note that the browser also sends a GET/HEAD/POST “preflight” for anything with a JSON body or custom headers; that is normal and the exported scripts don't have the restriction.
Is anything sent to DevToolbox?
No. The requests go straight from your browser to your own server, and the results stay in the page. Nothing is uploaded.