In short: what is this API tester?
This is a free, browser-based API testing platform and REST & GraphQL client — a Postman alternative with nothing to install. Send requests with any HTTP method, build URLs, headers, cookies, authentication and bodies visually, then inspect the full response — status, headers, cookies, timing and a formatted body. It also tests WebSocket and Server-Sent Events, decodes JWTs, analyzes CORS and security, generates code in 18 languages, and imports/exports cURL, OpenAPI, Postman and HAR. Everything runs locally; an optional proxy bypasses CORS when you need it.
REST workbench
All HTTP methods, visual builder, headers, cookies, auth and bodies — with instant response inspection.
GraphQL studio
Queries, mutations, variables and one-click schema introspection.
WebSocket & SSE
Connect, send and watch live messages stream into an event log.
Auth hub
Bearer, JWT, API key, Basic and OAuth2 applied automatically.
Code in 18 languages
fetch, Axios, Python, Go, PHP, Java, C#, Rust and more — plus cURL.
Environments & collections
Reusable {{variables}}, saved requests and full local history.
JWT, CORS & security
Decode tokens and score responses for security and CORS issues.
100% private
Runs in your browser. Direct requests never touch our servers.
What is API testing?
An API (Application Programming Interface) is the contract that lets one piece of software talk to another. On the web, that contract is almost always spoken over HTTP: a client sends a request to a URL with a method, headers and maybe a body, and the server answers with a status code, headers and a response body. API testing is the practice of sending those requests deliberately — to confirm an endpoint returns the right data, handles errors correctly, enforces authentication, and performs within budget — before that behaviour ever reaches real users.
Developers test APIs constantly: while building a new endpoint, while integrating a third-party service, while reproducing a bug a user reported, and while writing automated regression suites. The fastest way to do this interactively is with an API client (also called an API tester or REST client) that lets you compose a request visually and read the response without writing throwaway code. That is exactly what this tool is — a complete workbench for exploring, debugging and documenting HTTP APIs, including REST, GraphQL, WebSocket and Server-Sent Events.
Because it runs entirely in your browser, you can paste tokens, internal URLs and confidential payloads with confidence: in direct mode nothing is uploaded to our servers, and your requests, history, collections and environment variables live only in your browser's local storage. The single exception is the optional CORS proxy, which you explicitly toggle on for the endpoints that browsers would otherwise block.
REST API testing guide
REST (Representational State Transfer) is an architectural style in which resources are addressed by URLs and acted upon with HTTP methods. Testing a REST API means choosing the right method, pointing it at the right URL, attaching the right headers and body, and verifying the response. The methods map to operations you perform on a resource:
- GET — read a resource or a collection. Safe and idempotent; never changes server state.
- POST — create a new resource, or trigger an action. Not idempotent: sending it twice usually creates two things.
- PUT — replace a resource entirely with the payload you send. Idempotent.
- PATCH — apply a partial update, changing only the fields you include.
- DELETE — remove a resource. Idempotent: deleting twice has the same end state.
- HEAD — like GET but returns only headers, useful for checking existence, size or caching metadata.
- OPTIONS — ask which methods and CORS policies an endpoint supports; the browser also sends it automatically as a CORS preflight.
A typical REST workflow in this tool looks like: pick GET, paste https://api.example.com/v1/users, add an Authorization header through the Auth tab, send, and read the JSON in the formatted response viewer. To create a user you switch to POST, set the body type to JSON, type the payload, and send. The status code tells you the outcome — 201 Created on success, 400 for a malformed body, 401 when your token is missing or wrong. You can then save the request to a collection and re-run it whenever the API changes.
REST responses are most often JSON, but XML, HTML, plain text and form-encoded payloads are all common. The response viewer detects the content type and pretty-prints JSON and XML automatically, offers an interactive tree for JSON, and lets you search, copy or download any response. For query-driven endpoints, the Params tab manages the ?key=value pairs so you never have to hand-encode a URL, and path segments like /users/{{id}} can be filled from an environment variable.
GraphQL testing guide
GraphQL takes a different approach from REST. Instead of many endpoints that each return a fixed shape, a GraphQL API exposes a single endpoint and a strongly-typed schema, and the client asks for exactly the fields it wants. This eliminates over-fetching and under-fetching, but it changes how you test: every operation is an HTTP POST to one URL, with a JSON body containing a query string and an optional variables object.
To test GraphQL here, set the body type to GraphQL, write your query or mutation in the query editor, and supply variables as JSON. The tool assembles the correct payload and sends it. A query reads data; a mutation writes it; both return a JSON object with a data key and, when something goes wrong, an errors array — note that GraphQL frequently returns 200 OK even for logical errors, so always check the body, not just the status.
The most powerful GraphQL feature for testing is introspection: a built-in query that returns the schema itself. Click Introspect schemaand the tool loads every type, field and argument the API exposes, then renders them as a browsable explorer so you can discover what is available without external documentation. Some production servers disable introspection for security; in that case you will need the schema from the API's docs. Subscriptions— GraphQL's real-time channel — run over WebSocket rather than HTTP, so you can observe their frames in the Realtime tab.
API authentication methods explained
Most real APIs require authentication — proof of who is calling — and often authorization — proof that the caller is allowed to do what they are asking. The Auth tab applies the right credentials to your request automatically, so you never hand-craft an Authorization header. Here is how the common schemes work and when to use each:
| Scheme | How it is sent | Best for |
|---|---|---|
| Bearer token | Authorization: Bearer <token> | OAuth2 access tokens, personal access tokens |
| JWT | Authorization: Bearer <jwt> | Stateless sessions carrying signed claims |
| API key | Header (X-API-Key) or query param | Server-to-server and public data APIs |
| Basic Auth | Authorization: Basic base64(user:pass) | Simple internal tools — HTTPS only |
| OAuth 2.0 | Bearer access token from a provider | Delegated access to user data |
| AWS SigV4 | Signed Authorization header | AWS service APIs (paste a pre-signed value) |
| Digest / OAuth 1.0 | Challenge-response signature | Legacy APIs (paste a computed value) |
A practical tip: store credentials as environment variables like {{token}} rather than pasting them into every request. You then keep separate Local, Staging and Production environments, switch between them with one click, and never leak a production secret into a screenshot or a shared collection. For signed schemes such as AWS Signature v4, computing the signature in a browser would expose your secret key, so the tool asks you to paste a value produced by your SDK instead — an honest limitation that protects you.
When auth fails you will usually see 401 Unauthorized (the credentials are missing or invalid) or 403 Forbidden (the credentials are valid but not allowed). Use the JWT Inspectorin the Inspect tab to decode a bearer token and confirm its claims and expiry — a surprising number of “auth bugs” are simply an expired token.
WebSocket & Server-Sent Events testing
Not every API is request/response. WebSocket opens a persistent, bidirectional channel so the server and client can push messages to each other at any time — ideal for chat, live dashboards, multiplayer games and trading feeds. In the Realtime tab, enter a ws:// or wss:// URL, connect, and you can send messages and watch incoming frames stream into a live event log with connection-state indicators. A public echo server such as wss://echo.websocket.events is a great way to confirm the round trip.
Server-Sent Events (SSE)is a lighter, one-way alternative: the server streams a sequence of events to the client over a single long-lived HTTP connection, and the browser's EventSource automatically reconnects if the link drops. SSE is perfect for notifications, progress updates and live logs. The tool opens the stream and logs each event as it arrives. BecauseEventSource only supports GET and cannot set custom headers, authenticated streams typically pass a token as a query parameter. Both transports are subject to the same cross-origin rules as fetch, so a server that does not allow your origin may refuse the connection.
OpenAPI & Swagger support
OpenAPI (formerly Swagger) is the industry-standard way to describe an HTTP API in a single, machine-readable document. An OpenAPI spec lists every path, the methods it supports, its parameters and request/response schemas, and its security requirements, all in JSON or YAML. Because it is structured data, tools can turn it directly into documentation, client SDKs and — here — runnable requests.
Paste an OpenAPI 3.x or Swagger 2.0 spec into the Import tab and the tool lists every endpoint with its method, path and summary. Click any endpoint to generate a ready-to-edit request pointed at the spec's server URL, with path parameters such as /pets/{petId} converted into editable {{petId}} placeholders. This turns API documentation into a working request in two clicks — perfect for exploring an unfamiliar API or smoke-testing every endpoint after a deployment. YAML specs are parsed with the same engine that powers our YAML validator, so you can drop in a raw openapi.yaml without converting it first.
API security best practices
Testing an API is also a chance to check that it is secure. After every response, the Inspect tab can score the request and response against common security expectations and surface concrete recommendations. The checks include:
- Transport security — is the endpoint served over HTTPS? Tokens and cookies sent over plain HTTP can be intercepted.
- Security headers — is the response setting
Strict-Transport-Security,Content-Security-Policy,X-Content-Type-Options,X-Frame-Options,Referrer-PolicyandPermissions-Policy? - Credential leakage — is a token or API key being sent in the URL, where it ends up in logs and browser history?
- Cookie flags — do
Set-Cookieheaders includeSecure,HttpOnlyandSameSite? - Information disclosure — does a
ServerorX-Powered-Byheader reveal the exact software version? - Sensitive data — does the response body appear to contain secrets, private keys or embedded credentials?
The separate CORS tester reads the Access-Control-Allow-Origin, -Methods, -Headers and -Credentials headers and flags dangerous combinations — most notably a wildcard origin paired with credentials, which browsers reject outright. Treat the security score as a fast heuristic that catches the obvious problems, not a replacement for a proper security review or penetration test. The best defences remain the classics: always use HTTPS, authenticate and authorize every request, validate and sanitize all input, apply least-privilege scopes to tokens, rate-limit aggressively, and never trust data from the client.
API performance testing & debugging
Every response shows the total round-trip time and payload size at a glance, so a slow endpoint is obvious immediately. When a server opts in with a Timing-Allow-Originheader, the Timing tab also breaks the request into DNS, connection, TLS and time-to-first-byte phases via the browser's Resource Timing API. When it does not — which is common for cross-origin requests — browsers deliberately hide that fine-grained timing for privacy, so the tool honestly shows only the total rather than inventing numbers.
For a quick performance read, the benchmark control fires the same request a chosen number of times and reports the minimum, average, 95th-percentile and maximum latency along with the success rate. It is excellent for spotting a flaky or slow endpoint, but it is not a load test: browsers cap how many connections they open and CORS restricts which origins you can hit, so for serious load and stress testing reach for a dedicated server-side tool such as k6, Apache Bench or Gatling.
When a request misbehaves, debug it methodically. Start with the status codeand the response body, which usually carries the server's own error message. Confirm the method, URL, headers and authentication are what you intended by reading the Headers tab. Rule out latency with the Timing tab, and policy issues with the Security and CORS analyzers. Finally, generate the equivalent cURL command — seeing the exact wire request laid out as one line very often makes the mistake jump out, and gives you something reproducible to paste into a bug report or CI pipeline.
Postman alternatives compared
Postman popularised the visual API client, but it is no longer the only option — and for many tasks a fast, install-free browser tool is a better fit. Here is how the common choices compare:
| Tool | Install | Account | Notes |
|---|---|---|---|
| This tool | None — web | No | REST, GraphQL, WS, SSE, code-gen, import/export, free |
| Postman | Desktop app | Yes | Deep team features, cloud sync, mock servers, monitors |
| Insomnia | Desktop app | Optional | Clean REST/GraphQL client, plugin ecosystem |
| Hoppscotch | Web | Optional | Open-source, lightweight, browser-based |
| Thunder Client | VS Code ext. | Optional | Lives inside the editor |
| Bruno | Desktop app | No | Offline-first, files stored in git |
| cURL | CLI | No | Universal, scriptable, no UI |
The honest summary: if you need shared cloud workspaces, hosted mock servers and scheduled monitors, Postman's paid platform earns its place. If you want to fire a request, inspect a response, decode a token, generate a snippet or convert a curl command — right now, with nothing to install and no sign-up — a browser tool like this one is faster, and because it imports and exports Postman, OpenAPI and HAR, you are never locked in.
What runs in your browser (and what needs a backend)
We believe in being straight about a browser tool's limits. The following all run entirely on your device, work offline and never touch our servers: building requests, generating code and cURL, decoding JWTs, analyzing CORS and security, importing and exporting cURL/OpenAPI/Postman/HAR, and storing your history, collections and environments.
Sending requests is subject to the browser's rules. The Same-Origin Policyblocks reading responses from APIs that do not send CORS headers; our optional, SSRF-hardened proxy relays those requests server-side so they work. Browsers also expose only CORS-safelisted response headers to JavaScript in direct mode, hide fine-grained cross-origin timing, and cannot speak native gRPC or perform true high-concurrency load tests. A handful of features in the broader “API platform” category genuinely require a hosted backend and accounts — shared team workspaces, public mock-server endpoints, scheduled monitors and server-side AI generation — so we do not pretend to offer them in a static app. Where there is a real, honest client-side equivalent, we ship it: generate mock-server stub code, benchmark latency locally, and collaborate by exporting collections.
HTTP status code reference
Every response is color-coded by status. Here are the codes you will meet most often:
| Code | Meaning | What it tells you |
|---|---|---|
| 200 OK | Success | The request succeeded and the body holds the result |
| 201 Created | Success | A new resource was created (check the Location header) |
| 204 No Content | Success | Succeeded with no body — common for DELETE |
| 301 / 302 | Redirect | The resource moved; the client follows the Location |
| 304 Not Modified | Redirect | Your cached copy is still valid |
| 400 Bad Request | Client error | The request was malformed — check the body and params |
| 401 Unauthorized | Client error | Missing or invalid credentials |
| 403 Forbidden | Client error | Authenticated but not allowed |
| 404 Not Found | Client error | No resource at that URL |
| 429 Too Many Requests | Client error | You are being rate-limited — back off |
| 500 Internal Server Error | Server error | The server crashed handling the request |
| 502 / 503 / 504 | Server error | Gateway, unavailable or timeout — usually transient |
Frequently asked questions
An API tester is a tool that sends HTTP requests to an API endpoint and shows you the full response — status code, headers, cookies, timing and body — so you can verify that the API behaves correctly. It replaces hand-writing curl commands or throwaway scripts, letting you set the method, URL, query parameters, headers, authentication and request body through a visual builder and inspect the result instantly.
Choose an HTTP method (GET, POST, PUT, PATCH, DELETE, OPTIONS or HEAD), paste the endpoint URL, add any headers or query parameters, attach a request body for write operations, and click Send. The response viewer then shows the status, headers, timing and a pretty-printed body. Everything runs in your browser, so you can start testing immediately without installing anything or signing up.
Yes. It is completely free with no sign-up, no request limits and no watermarks. You can send unlimited requests, build collections, generate code and import or export specs as much as you like.
For day-to-day REST and GraphQL testing it covers the features most developers use in Postman — a visual request builder, authentication helpers, environments and variables, collections, history, code generation and import/export — but it runs entirely in the browser with nothing to install and no account. It does not replace Postman’s cloud team features such as shared workspaces, mock servers and monitors, which require a backend.
By default every request is sent directly from your browser to the target API, and your requests, tokens, history and collections are stored only in your browser’s local storage — nothing is uploaded to our servers. If you enable the optional CORS proxy, those specific requests are relayed through our server to bypass browser restrictions; everything else stays local.
Browsers enforce the Same-Origin Policy, so a page on our domain can only read responses from APIs that explicitly allow cross-origin requests via CORS headers. Many APIs do not send those headers for browser callers, which produces a CORS error even though the API itself is reachable. You can toggle on the built-in proxy to relay the request server-side and bypass CORS, or test the API from a server-side environment using the generated code.
The proxy is an optional server-side relay that forwards your request to the target API and returns the response, sidestepping the browser’s CORS restrictions. Use it when a direct request fails with a CORS or network error. Because proxied requests travel through our server, avoid sending highly sensitive production credentials through it; for those, prefer direct mode or run the generated code locally.
Open the Auth tab, choose Bearer Token, and paste your token. The tool automatically adds an Authorization: Bearer <token> header to the request. You can also store the token as an environment variable such as {{token}} and reference it, so you never paste secrets into individual requests.
In the Auth tab select Basic Auth and enter a username and password. The tool Base64-encodes the credentials and sends them as an Authorization: Basic header, exactly as the HTTP spec requires. Remember that Base64 is encoding, not encryption, so only use Basic Auth over HTTPS.
Select API Key in the Auth tab, then choose whether to send it as a header (for example X-API-Key) or as a query parameter. Enter the key name and value and the tool adds it to the request in the right place automatically.
Bearer tokens, JWT bearer, API keys (header or query), Basic Auth, and OAuth 2.0 access tokens are applied automatically. For schemes that require live signing — AWS Signature v4, OAuth 1.0 and Digest — the tool lets you paste a pre-computed Authorization header, because securely computing those signatures in the browser would expose your secret keys.
A JWT (JSON Web Token) is a compact, signed token with three Base64URL parts — header, payload and signature — used to carry authentication claims. Paste any token into the Inspect tab and the tool decodes the header and payload, lists the claims, and shows the algorithm and expiration. Decoding happens locally and never verifies or transmits the signature.
GraphQL is a query language for APIs that lets the client request exactly the fields it needs from a single endpoint. Switch the body type to GraphQL, write your query or mutation, supply variables as JSON, and send it — the tool wraps everything into the correct POST payload. You can also run an introspection query to load the schema and browse available types and fields.
Yes for queries and mutations, which are sent as standard HTTP POST requests. Subscriptions use a long-lived transport (usually WebSocket); you can open the underlying WebSocket connection in the Realtime tab to observe subscription messages, though the tool does not yet manage the full graphql-ws handshake automatically.
Introspection is a built-in GraphQL feature that lets a client query the schema itself — its types, fields and arguments. The tool sends the standard introspection query and renders the result as a browsable schema explorer, so you can discover what an API supports without external documentation. Note that some production servers disable introspection.
Open the Realtime tab, choose WebSocket, enter a ws:// or wss:// URL and click Connect. You can then send messages, watch incoming messages stream into the event log in real time, and see connection state changes. It is ideal for testing chat servers, live feeds and echo endpoints such as wss://echo.websocket.events.
In the Realtime tab choose SSE and enter the event-stream URL. The tool opens an EventSource connection and logs every event as it arrives, including event names and data, so you can verify streaming endpoints and diagnose reconnection behavior.
Paste any curl command into the Import/Export tab. The tool parses the method, URL, query string, headers, cookies, body and Basic-Auth credentials and loads them into the request builder, ready to send or edit. It understands the common flags including -X, -H, -d, --data-raw, -F, -u and -b.
Every request can be copied as a ready-to-run curl command with one click. The export resolves your environment variables and authentication into a concrete command you can paste into a terminal, a CI pipeline or a bug report.
Yes. Paste an OpenAPI 3.x or Swagger 2.0 specification as JSON or YAML and the tool lists every endpoint with its method, path and summary. Click any endpoint to generate a ready-to-edit request pointed at the spec’s server URL, with path parameters turned into editable {{placeholders}}.
Yes. Paste a Postman collection (schema v2.1) and the tool imports every request — including nested folders, headers, query parameters, body and bearer auth — into your collections so you can run them immediately.
Yes. HAR (HTTP Archive) files exported from your browser’s network panel can be imported, turning each captured request into a runnable, editable request in the tool.
You can export individual requests as curl or as code in 18 languages, and export collections as a Postman v2.1 collection or a HAR archive. This makes it easy to move work between tools, share with teammates or commit reproducible requests to a repository.
A collection is a saved group of requests you can name, organize and re-run. Save any request to a collection, and it persists in your browser so you can come back later, share it via export, or use it as a regression suite for an API.
Environment variables are reusable placeholders such as {{base_url}}, {{token}} and {{user_id}} that the tool substitutes into the URL, headers and body at send time. They let you switch between development, staging and production by changing one environment instead of editing every request, and keep secrets out of individual requests.
Create multiple environments — for example Local, Staging and Production — each with its own variable values, then select the active one from the environment dropdown. Every {{variable}} in your request resolves against the active environment when you send it.
Open the Code tab and pick a language. The tool generates a ready-to-use snippet — fetch, Axios, jQuery, XHR, Node.js, Python requests, PHP cURL, Go, Ruby, Java, C#, Swift, Kotlin, Dart, Rust, PowerShell or HTTPie — that reproduces the current request exactly, including headers, auth and body. Copy it straight into your project.
Eighteen targets: cURL, JavaScript (Fetch, Axios, jQuery AJAX and XHR), Node.js, Python (Requests), PHP (cURL), Go, Ruby, Java, C#, Swift, Kotlin, Dart, Rust, PowerShell and HTTPie.
The response viewer shows the status code and message, total time and response size at a glance, then lets you switch between a Pretty (formatted) view, the Raw body, an interactive JSON Tree, the response Headers, parsed Cookies and a Timing breakdown. You can search, copy or download the body from any view.
Status codes are grouped: 1xx informational, 2xx success (200 OK, 201 Created, 204 No Content), 3xx redirection (301, 302, 304), 4xx client errors (400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 429 Too Many Requests) and 5xx server errors (500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable). The tool color-codes the status so you can tell success from failure at a glance.
Yes. Every response shows the total round-trip time and payload size. Where the browser exposes it (via the Resource Timing API, when the server sends a Timing-Allow-Origin header), the Timing tab also breaks down DNS, connection and transfer phases. Otherwise only the total is available, because browsers deliberately hide fine-grained cross-origin timing for privacy.
There is a lightweight benchmark mode that fires the same request a chosen number of times and reports min, average, p95 and max latency plus the success rate. It is great for spotting a slow endpoint, but it is not a substitute for a dedicated load-testing tool — browsers cap concurrent connections and CORS limits which origins you can hit, so use server-side tools like k6 or Apache Bench for serious load tests.
After a response arrives, the analyzer inspects the request and response for common issues — missing security headers (HSTS, CSP, X-Content-Type-Options and more), credentials sent in the URL, Basic Auth over HTTP, insecure cookies, version-disclosing Server headers and possible secrets in the body — and produces a 0–100 score with prioritized recommendations. It is a heuristic helper, not a full penetration test.
It reads the response’s CORS headers — Access-Control-Allow-Origin, -Methods, -Headers and -Credentials — and flags problems such as a wildcard origin combined with credentials (which browsers reject), a missing allow-origin, or an overly permissive policy on an authenticated endpoint.
Set the body type to JSON and type or paste your payload into the editor. The tool sends a Content-Type: application/json header automatically and pretty-prints and validates the JSON as you type, so malformed payloads are caught before you send.
Choose the Form URL-encoded body type to send application/x-www-form-urlencoded key/value pairs, or Multipart to send multipart/form-data fields. The tool sets the correct Content-Type and encodes the fields for you.
Yes. Set the body type to XML, paste your XML or SOAP envelope, and add any required headers such as SOAPAction. The response viewer pretty-prints XML responses so they are easy to read.
You can build multipart/form-data requests with text fields in the browser. True binary file uploads are limited by the browser sandbox and CORS; for production file-upload testing, generate the equivalent code and run it from your server or a desktop client.
PUT replaces an entire resource with the payload you send, so omitted fields are typically cleared. PATCH applies a partial update, changing only the fields you include. Both are supported, and the tool sends your chosen method exactly so you can verify how the API treats each one.
An idempotent request produces the same result no matter how many times it is sent. GET, PUT, DELETE, HEAD and OPTIONS are expected to be idempotent; POST usually is not. This matters for retries: it is safe to automatically retry idempotent requests but not non-idempotent ones.
Yes. Every request in your history can be re-sent with one click, and you can duplicate the current request to branch off a variation without losing the original. Combined with collections, this makes iterating on an endpoint fast.
Yes. Each request you send is recorded in your local history with its method, URL, status and time, so you can re-open, re-run or save it to a collection later. History lives only in your browser and can be cleared at any time.
An endpoint is a specific URL that an API exposes to perform an operation — for example GET /users/42 to fetch a user or POST /orders to create an order. An API is the collection of all its endpoints together with the rules for calling them.
Headers are key/value metadata sent with a request or response. Request headers carry things like Content-Type, Accept and Authorization; response headers carry things like Content-Type, Cache-Control and Set-Cookie. The tool lets you set request headers as editable rows and shows every response header.
Path parameters are part of the URL path that identify a resource, such as the 42 in /users/42. Query parameters come after the ? and refine a request, such as ?page=2&limit=20. The builder has dedicated sections for both so you can edit them without hand-encoding the URL.
A webhook is an HTTP callback: a server sends a POST request to a URL you control when an event happens. You can use this tool to simulate the sender by crafting and sending the webhook payload to your endpoint, and to verify signatures by generating the expected hash with the Hash Generator. Receiving live webhooks requires a public URL from a tunneling service.
OpenAPI (formerly Swagger) is a standard, language-agnostic specification that describes an API’s endpoints, parameters, request and response schemas and authentication in a single JSON or YAML document. The tool imports these specs so you can turn documentation directly into runnable requests.
You can set cookies explicitly in the Cookies tab and the tool sends them as a Cookie header. Because the browser controls automatic cookie handling for cross-origin requests, session flows that rely on Set-Cookie may be easier to test through the proxy or by copying the session cookie into the Cookies tab manually.
Add the relevant query parameters such as page, limit, offset or cursor in the Params tab, send the request, then adjust the values and re-send to walk through pages. Saving the request to a collection lets you keep a parameterized version that uses {{page}} so you can iterate quickly.
Rate limiting caps how many requests you can make in a time window. APIs usually advertise it through response headers such as X-RateLimit-Limit, X-RateLimit-Remaining and Retry-After, and return a 429 status when you exceed it. The response Headers tab surfaces these so you can monitor your remaining quota.
Not directly. gRPC uses HTTP/2 with binary Protocol Buffers, which browsers cannot speak natively. If a service exposes gRPC-Web or a REST/JSON transcoding gateway, you can test that HTTP surface here. For native gRPC, use a dedicated gRPC client.
The interface, code generation, cURL conversion, JWT decoding and import/export all work offline because they run entirely in your browser. Actually sending requests obviously needs a network connection to reach the target API.
Direct browser requests follow the browser’s own timeout behavior. Proxied requests are capped at a server-side timeout (around 15 seconds) and a response-size limit to keep the relay fast and abuse-resistant. If you need longer-running calls, run the generated code locally.
Start with the status code and response body for the server’s error message, then check that your method, URL, headers and auth are correct. Use the Headers tab to confirm what was actually sent and returned, the Timing tab to rule out slowness, and the Security and CORS analyzers to catch policy issues. Generating the equivalent curl command often makes the problem obvious.
Store tokens and keys as environment variables rather than pasting them into individual requests, and mark sensitive variables so they are masked in the UI. Variables are stored in your browser’s local storage and never uploaded, but treat any shared computer with care and clear them when finished.
The terms are largely interchangeable. A REST client is software for composing and sending HTTP requests to REST APIs; an API tester emphasizes inspecting and validating the responses. This tool is both: a full REST and GraphQL client plus response inspection, security analysis and code generation.
Yes. Import an OpenAPI spec to browse endpoints, run real requests to capture example responses, and generate code snippets that you can paste into your docs. It pairs well with the JSON Formatter for cleaning up example payloads.
You can paste an OAuth 2.0 access token and the tool applies it as a Bearer token. The full authorization-code redirect flow needs a registered client and a backend callback, so obtain the token through your provider and bring it here, or store it as an environment variable.
The total time is measured around the actual fetch call, so it reflects real round-trip latency including network and server processing. Sub-phase timing (DNS, TLS, TTFB) is only available when the server opts in with a Timing-Allow-Origin header; otherwise the browser hides it and the tool shows the total only, honestly labeled.
You can test http://localhost and private network APIs in direct mode straight from your browser, since the request originates locally. The optional server-side proxy deliberately blocks private, loopback and link-local addresses to prevent server-side request forgery, so use direct mode for internal endpoints.
It combines a polished, privacy-first browser client with features usually split across several tools: REST and GraphQL, WebSocket and SSE, an authentication hub, environments and collections, 18-language code generation, cURL/OpenAPI/Postman/HAR import-export, a JWT inspector, and built-in CORS and security analyzers — all free, with no install and no account, and with an optional proxy for the CORS cases that defeat other in-browser testers.
No. It is a web app that runs in any modern browser. There is nothing to download, no extension to add and no account to create — open the page and start sending requests.
Real-time shared workspaces require a backend and account system, which this browser-based tool does not provide. You can still collaborate asynchronously by exporting collections as Postman or HAR files, or sharing generated curl commands and code snippets, which teammates import in one click.
Related Tools
Explore More Tools
Go ad-free & unlock power features
- Zero ads, faster focused workflow
- Upload 50MB+ files & batch process
- Priority AI type & schema generation