Application Programming Interface (API) Testing Tool

Request snapshot

Request target:

Enter a full https:// URL or paste cURL; query rows below are merged into the final request.

Browser-side runner CORS must allow your origin or the browser will block the response. Paste a full URL or cURL command to seed the request builder.

Request options

Tabbed builder

5 tabs

Query parameters:

Use one row per query pair, e.g. limit=10; switch rows off to keep them without sending.

On	Key	Value	Remove

Headers:

Use one row per header, e.g. Accept: application/json; leave browser-managed headers out.

On	Header	Value	Remove

Auth type:

Choose Basic or Bearer only when this endpoint expects Authorization.

Basic credentials:

Credentials apply to this run and stay out of saved presets unless you opt in.

Username:

Example: alice or sandbox-client.

Password:

Paste the secret value only; it is not displayed in the field.

{{ showBasicPassword ? 'Password is visible.' : 'Password is hidden.' }}

Bearer token:

Paste only the token; do not include the Bearer prefix.

{{ showBearerToken ? 'Bearer token is visible.' : 'Bearer token is hidden.' }}

Body mode:

GET/HEAD ignore body; JSON, form, and multipart prepare different payload shapes.

Request body:

Use JSON text such as {"name":"Ada"}, or raw content for custom media types.

Form fields:

Use field names such as email with values such as ada@example.com; disabled rows are not sent.

On	Key	Value	Remove

Multipart parts:

Use file rows for uploads; saved presets remember names but files must be reattached.

On	Key	Type	Value / File	Remove
			Selected: {{ row.file.name }} Reattach file: {{ row.savedFileName }}

GET and HEAD send no body; JSON/form set Content-Type when needed, multipart lets the browser set the boundary.

Timeout:

Use 9000 for normal tests; raise for slow APIs or set 0 to wait indefinitely.

Redirects:

Use manual when checking Location headers; follow matches normal browser fetch behavior.

Credentials:

same-origin is safest; include sends cookies when CORS allows credentials.

Cache:

Use no-store for fresh API debugging; default follows browser cache rules.

Parse cURL:

Paste one cURL command, then Parse to populate the request builder.

The Request target box also accepts cURL when you paste a full command there.

Metric	Value	Copy
{{ row.label }}	{{ row.value }}
No response metrics.

{{ formattedBody }}

Preview is available only for HTML responses.

Provide a URL or parse an incoming cURL command to populate the request trace.

Send a request to capture the response trace with status line, headers, body, and timing.

Header	Value	Copy
{{ h.key }}	{{ h.value }}
No headers returned.

Recent runs

Browser-local request history

Only the method, target, status, timing, and content-type are retained here. Load any target back into the editor to retry it.

Captured	Method	URL	Result	Actions
	{{ entry.method }}	{{ entry.url }}	· {{ entry.elapsedMs }} ms · {{ entry.responseType }}
No recent runs yet.

Saved requests

Stored request presets

Requests stay in your browser. Blank request names auto-label from the current method and target.

Save label:

Example: Sandbox POST users.

Include auth in presets:

Keep off for shareable presets; turn on only for private browser-local reuse.

Import JSON

Name	Method	URL	Actions
{{ entry.name }}	{{ entry.method }}	{{ entry.url }}
No saved requests yet.

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

API testing is the habit of turning a request into evidence. A useful test records the method, target URL, query string, headers, credentials, payload, redirect behavior, timeout, response status, response headers, response body, final URL, size, and timing. Without that record, a failed endpoint can look like a vague application bug instead of a specific HTTP exchange that can be repeated.

Browser-based API testing has one important boundary: it shows what page code can send and read from the current browser origin. That is different from a server-side client or a terminal command. A request can work in cURL while failing in a browser because Cross-Origin Resource Sharing (CORS), credential rules, redirect handling, cache behavior, or exposed-header rules change what JavaScript is allowed to see.

A browser request may reach a server even when browser policy prevents page code from reading the response.

Most API debugging starts with a practical question: did the server reject the request, did the browser stop the exchange, or did the response succeed but carry the wrong data? A 401 points toward credentials, a 422 usually points toward request validation, a 5xx needs server-side review, and a browser-visible status of 0 means the page did not receive a normal exposed HTTP response.

Request target: The full URL that receives the method, query string, headers, and optional body.
Representation: The body plus metadata such as Content-Type, which tells the receiver how to interpret JSON, form data, HTML, text, or binary content.
Browser visibility: The subset of status, headers, and body data that JavaScript is allowed to inspect after CORS, redirect, cache, and credential rules are applied.

Good test records also protect teams from false confidence. A green HTTP status does not prove that the business operation succeeded, a fast response does not prove that the right endpoint was reached, and a copied request is only safe to share after tokens, cookies, API keys, and private payload fields have been removed.

How to Use This Tool:

Build the request first, then send it and read the response tabs as a reproducible exchange record.

Choose a starter recipe or keep a blank request. Set the HTTP method and Request target; the request snapshot should show the intended method, host, parameter count, header count, body state, timeout, and redirect mode before you send anything.
Add enabled Query rows for parameters you want merged into the final URL. Existing query pairs in the URL are preserved, and matching key-value pairs from the table are not duplicated.
Use Headers for request headers such as Accept or Content-Type. Leave browser-managed headers out, and remember that CORS can still prevent the response from being readable.
Select Auth only when the endpoint expects an Authorization header. Basic builds a Basic credential header from username and password, while Bearer adds the bearer prefix for the token you paste.
Pick the correct Body mode for methods that can send a payload. JSON validates before sending, x-www-form-urlencoded sends enabled form rows, multipart/form-data can include text or attached files, and Raw sends the text as written. GET and HEAD send no body here.
Open Transport when timeout, redirect, credential, cache, cURL import, or copyable request snippets matter. A pasted cURL command can populate method, URL, headers, Basic or Bearer auth, and common body formats.
Send the request and start with Response Metrics. Check Status, Success flag, Elapsed time, Body size, Content-Type, Final URL, and Body classification before trusting the body.
Use the detailed tabs for the handoff artifact you need: Response Body for raw text, Response JSON for parsed JSON, HTML Preview for HTML-like replies, Request Trace and Response Trace for ticket notes, Response Headers for exposed metadata, and Exchange JSON for a structured request-response record.

Interpreting Results:

Treat the status code as the first clue, not the final verdict. The most useful pass starts with Status and Success flag, then checks Final URL, Content-Type, Body classification, and the actual response body against the API contract.

API response status cues and follow-up checks
Cue	Likely meaning	What to verify
`2xx`	The browser received an HTTP success response.	Confirm the response body has the expected fields, the content type is correct, and the final URL did not change unexpectedly.
`3xx`	Redirect behavior affected the result.	Use the redirect mode deliberately, and compare the final URL or exposed redirect evidence with the expected route.
`4xx`	The server rejected the request because of authorization, route, format, validation, or other client-side input.	Check the request trace, auth mode, headers, query values, and body syntax before changing response parsing code.
`5xx`	The server reported a failure while handling the request.	Keep the method, URL, body, status, response trace, and timing together for server-log review.
`HTTP 0`	The browser did not expose a normal HTTP response because of timeout, cancellation, transport failure, or CORS blocking.	Read `Failure class` and the response body message, then compare with a known CORS-enabled endpoint or a terminal request when reachability is uncertain.

Body classification is a convenience, not a contract. JSON appears when the content type is JSON or the readable body parses as JSON. HTML preview is available only for HTML-like responses, and binary-looking responses are summarized by size rather than forced into a text view.

Recent runs keep a compact browser-local history of method, target, status, timing, and content type. Saved requests store reusable presets in this browser, with credentials omitted unless Include auth in presets is turned on.

Technical Details:

HTTP request semantics start with the method and target resource. GET and HEAD are treated here as no-body methods, while POST, PUT, PATCH, DELETE, and OPTIONS can carry a payload when the server contract allows it. The method does not decide the response format on its own; headers, route rules, authentication, and server validation shape the final response.

Browser Fetch adds a policy boundary around the HTTP exchange. The browser controls whether cookies are sent, how redirects are handled, which cache mode is used, whether a request is aborted after the timeout, and whether cross-origin response details are exposed to page code. A CORS preflight can fail before the intended request is visible as an ordinary response, and a successful server-side exchange can still be unreadable to the page if the response does not allow the current origin.

Formula Core:

Elapsed time is measured as one browser-observed attempt. It includes browser scheduling, network travel, server handling, redirect behavior when followed, response-body reading, and timeout or failure handling. It is not the same as server processing time.

t_{elapsed} = t_{finish} - t_{start}

t_start is the browser timestamp just before the request attempt. t_finish is the timestamp after a readable response is processed or after the attempt ends through timeout, cancellation, or transport failure. For example, a start timestamp of 12,000 ms and finish timestamp of 12,384 ms gives an Elapsed time of 384 ms.

Request Assembly Rules:

How request settings affect the browser API request
Part	Rule	Why it matters
URL and query rows	The target URL is parsed first, then enabled query rows are appended unless the same key-value pair already exists.	A repeated test keeps visible filters such as page, limit, search, or feature flags in one final URL.
Headers and auth	Enabled headers are included, then Basic or Bearer auth can add an `Authorization` header.	Authentication failures should be debugged from the request trace before assuming the response parser is wrong.
JSON body	Valid JSON is normalized before sending and receives `application/json` when no content type is already set.	Invalid JSON stops the run before the endpoint receives the request.
Form body	Enabled key-value rows are encoded as `application/x-www-form-urlencoded`.	This matches many token, login, and legacy form endpoints that do not accept JSON.
Multipart body	Enabled text and attached file parts are sent as browser-built multipart form data.	The browser supplies the multipart boundary, so a manual boundary header is usually a mistake.
Text body file	A local JSON, TXT, CSV, XML, YAML, ENV, INI, TOML, MD, LOG, or text-like file can load into the request-body editor up to 2 MB.	This helps reproduce payload bugs without typing large request bodies by hand.

Browser Visibility Rules:

Browser visibility rules for API response testing
Condition	Visible result	Practical consequence
CORS allows the origin and exposes the needed response details	Status, permitted response headers, body text or bytes, final URL, and timing can appear in the result tabs.	The browser result is a useful proxy for what frontend code can read.
CORS blocks the response or preflight	The run fails without a normal exposed status, headers, or body.	The endpoint may still be reachable from cURL, a backend service, or an API client outside the browser.
Timeout expires	The request is aborted and marked with a timeout failure class.	Raise the timeout only after confirming the URL, method, body size, and expected server latency.
Manual redirect mode is selected	Redirect evidence can be limited by browser security rules.	Use a terminal comparison when complete redirect headers are required.
Credentials mode is `include`	Browser cookies may be sent when the target and CORS policy allow credentials.	Use it only when cookie-based auth is part of the test, because it changes what the server receives.

Response Classification:

The response body is read as bytes first when the browser exposes it. Text-like content is decoded using the declared charset when available, falling back to UTF-8. JSON is parsed when the content type declares JSON or when the body text itself parses as JSON. HTML preview uses a sandboxed preview for HTML-like content, while non-text content is summarized as a binary response with its size.

The exchange JSON combines the request snapshot and the exposed response record. It is useful for debugging, but it should be reviewed before sharing because headers, URLs, query values, and bodies can contain secrets or private data.

Privacy and Safety Notes:

Your browser sends the API request directly to the target URL you enter. The target server can receive the method, URL, query string, request headers, credentials, cookies allowed by the selected credentials mode, body text, and attached files. Do not use production secrets in shared examples unless the endpoint and browser profile are controlled for that purpose.

Saved requests and recent runs are stored in this browser, not as a shared project account.
Saved presets omit Basic and Bearer auth unless Include auth in presets is switched on.
Multipart saved presets remember file names for convenience, but the actual files must be reattached before sending.
Copy request traces, response traces, and exchange JSON only after removing tokens, cookies, personal data, and private payload fields.

Worked Examples:

Check a JSON list endpoint

Set the method to GET, enter a list endpoint, add query rows such as limit=10 and active=true, and keep Accept: application/json enabled. A healthy browser-visible result shows Status as an HTTP 2xx value, Success flag as true, Body classification as JSON, and Final URL with the expected query values.

If the JSON body is an application-level error object, the HTTP exchange succeeded but the API contract still needs review.

Rebuild a failing POST from cURL

Paste a cURL command with -X POST, a JSON content type, a bearer token, and a JSON body into Parse cURL. Confirm that Auth changed to Bearer, Body mode changed to JSON, and Request Trace shows the expected method, path, headers, and body before sending.

If the JSON is malformed, the run stops with Body JSON is invalid. before any request is sent. If the response returns 401, compare the trace against the API docs before rewriting the payload.

Test a browser file upload

Choose multipart/form-data, add a text part such as purpose=test, add a file part, and attach the sample file. A useful response shows Body size, Content-Type, and a response body or JSON echo that confirms the server received the multipart fields.

If you save this request for later, the preset remembers the file part name but not the file itself. Reattach the file before rerunning the upload.

Separate CORS from server failure

A private endpoint can work from cURL and still show HTTP 0 in a browser test. Check Failure class and the response body message, then try a known CORS-enabled recipe from the same browser. If the known endpoint works, the likely problem is browser visibility policy, not a completely unreachable network route.

FAQ:

Why does the request work in cURL but fail here?

cURL is not restricted by browser CORS, credentials, redirect, and exposed-header rules. This browser-side test shows what page code can send and read from the current origin.

Why is my JSON body rejected before sending?

JSON body mode requires valid JSON. Fix the syntax, use Pretty JSON after it parses, or switch to Raw when the endpoint intentionally expects non-JSON text.

Can I test file uploads?

Yes. Use multipart/form-data, add a file part, choose the file, and let the browser set the multipart boundary. Saved presets require the file to be reattached.

Does a successful status mean the API did the right thing?

No. Success flag follows the HTTP success range. Check Response JSON, Response Body, Final URL, and Content-Type against the endpoint contract.

Are saved requests safe for credentials?

Credentials stay out of saved presets unless Include auth in presets is on. Keep that switch off for shareable examples and remove secrets before exporting saved requests.

What should I copy into a bug report?

Copy the request trace, response trace, status, final URL, content type, elapsed time, and the smallest response body excerpt needed to reproduce the issue. Remove tokens and private data first.

Glossary:

CORS: Cross-Origin Resource Sharing, the browser protocol that decides whether page code can read a cross-origin response.
Preflight: A browser check sent before some cross-origin requests to ask whether the real method, headers, or credentials are allowed.
Bearer token: An access token sent in an Authorization: Bearer header and accepted by the server if it is still valid.
Content-Type: The header that identifies the request or response media type, such as JSON, HTML, form data, text, or binary content.
Redirect mode: The browser fetch setting that controls whether redirects are followed, rejected, or handled manually.
Response trace: A readable record of exposed response status, headers, body, timing, final URL, and success state.

References:

RFC 9110: HTTP Semantics, RFC Editor, June 2022.
Fetch Standard, WHATWG.
Cross-Origin Resource Sharing (CORS), MDN Web Docs.
Using the Fetch API, MDN Web Docs.
RFC 7617: The Basic HTTP Authentication Scheme, RFC Editor, September 2015.
RFC 6750: Bearer Token Usage, RFC Editor, October 2012.
How to authenticate with an API key in cURL, simplified.guide.
How to authenticate with a bearer token in cURL, simplified.guide.
How to show HTTP response headers with cURL, simplified.guide.
How to capture response metrics with cURL write-out, simplified.guide.