What does this tool do
The Web Service Check tool checks if multiple websites or APIs are live. Enter URLs—one per line—and see status codes, response times, and availability. All checks run in your browser via fetch(); no server-side proxy. Useful for monitoring uptime, debugging connectivity, and quickly verifying that APIs or sites respond.
How to use it
- Enter URLs — Paste or type URLs, one per line (or comma-separated). Add
https://if missing. - Click Check — The tool validates URLs, then fetches each one in batches of 5.
- View results — A table shows URL, HTTP status code, response time (ms), and status (Up, Redirect, Client Error, Server Error, Timeout, Reachable, CORS blocked).
- Interpret status — Green = Up (2xx) or Reachable (CORS restricted), Yellow = Redirect (3xx), Red = error or blocked.
How it works
URLs are parsed from the textarea (split by newline or comma), trimmed, and validated. Invalid or duplicate URLs are skipped. Only http and https are allowed. Each URL is first fetched with mode: "cors" to get full status. If that fails with a CORS-like error, the tool retries with mode: "no-cors" — if the request succeeds, the site is reported as "Reachable" (status unknown). Requests run from your browser; CORS applies to the first attempt. A 5-second cooldown prevents rapid re-checks. Maximum 20 URLs per run.
All computation runs in your browser. No data is sent to our servers.
Use cases & examples
- Uptime check — Verify multiple endpoints are responding.
- API health — Quickly ping several API URLs.
- Connectivity debug — See which URLs respond and which time out.
- CORS check — Identify which sites allow cross-origin requests.
Example
CORS-friendly URLs that work from the browser (click "Try CORS-friendly sample" to load them):
https://httpbin.org/get→ 200, Uphttps://httpbin.org/status/200→ 200, Uphttps://jsonplaceholder.typicode.com/posts/1→ 200, Uphttps://api.github.com→ 200, Uphttps://httpbin.org/status/404→ 404, Client Errorhttps://httpbin.org/delay/10→ Timeout (8 s limit)- Site with strict CORS → Reachable (CORS restricted) if it responds; CORS blocked if it also fails the no-cors fallback
CORS and no-cors fallback
The Web Service Check runs entirely in your browser. It first uses fetch() with mode: "cors" to get full status codes. When that fails due to CORS (the target does not send Access-Control-Allow-Origin), the tool retries with mode: "no-cors". With no-cors, the browser allows the request but returns an opaque response — we cannot read status, headers, or body. If the no-cors request succeeds, we report Reachable (site responded; status unknown). If it also fails (timeout, network error), we report CORS blocked.
This fallback lets you see that many more sites are responding, even when full status is unavailable. CORS still cannot be bypassed to read response data; the fallback only confirms reachability.
Limitations & known constraints
- CORS — Sites that block CORS may show "Reachable" (responded; status unknown) or "CORS blocked" (both CORS and no-cors failed). Full status codes require CORS-enabled targets.
- Max 20 URLs — Per check. Reduce the list if you have more.
- 8 s timeout — Each URL has an 8-second limit.
- 5 s cooldown — Wait 5 seconds before running another check.
- http/https only — Other schemes are rejected.
- Browser limits — Subject to same-origin policy and browser fetch behavior.