{{ summaryTitle }}
{{ summaryValue }}

{{ summaryLine }}

Method{{ method }} Transport{{ loading ? 'Sending' : (hasResponse ? 'Complete' : 'Browser fetch') }} CORSEndpoint controlled
{{ summaryAnnouncement }}
API request details
Imported values remain editable before anything is sent.
Credentials stay in this browser session and are never written to the share URL.
{{ curlImportStatus || 'Import fills the request builder without sending.' }}
The shipped example stays idle until you choose Send request.
Example: Accept: application/json
Basic credentials:
API key header:
{{ bodyMode === 'form' ? 'Use one key=value pair per line.' : 'The body is sent exactly after the selected encoding step.' }}
Use 0 for no explicit abort timer.
ms
Follow matches normal browsing; manual exposes only what fetch permits.
Controls browser cookies and ambient HTTP credentials, not the explicit auth field.
Choose how fetch reads from and writes to the browser HTTP cache.
Secrets are intentionally excluded from saved presets.

{{ textExportStatus }}

{{ formattedResponseBody }}
{{ chartExportStatus }}

The chart renderer is unavailable. Timing values remain in the summary and trace.

{{ tableExportStatus }}
HeaderValueCopy
{{ row.name }}{{ row.value }}
No response headers were visible to the browser.
{{ exchangeTrace }}

Introduction:

An API request is a controlled conversation with a server. The method describes the intended action, the URL identifies the resource, headers carry metadata or credentials, and an optional body carries data. The response supplies a status code, headers, and body that must be read together. A successful status can still contain the wrong record, while an error response can contain the exact validation detail needed to fix the request.

Browser testing adds another participant to that conversation. Page code uses the browser's Fetch rules, so Cross-Origin Resource Sharing (CORS), mixed-content protection, cookie policy, redirects, and the HTTP cache affect what can be sent or exposed. A request that succeeds in cURL may fail in a page because cURL is not enforcing the browser's cross-origin visibility rules.

HTTP response
The server returned a status, exposed headers, and a body that browser code was allowed to read.
Browser network error
Fetch did not expose a normal response. CORS, mixed content, DNS, TLS, connectivity, cancellation, or a rejected redirect can all look similar from page code.
Application result
The meaning inside the response body. It may disagree with a broadly successful HTTP status and must be checked against the API contract.

Request bodies also have formats, not just text. JSON must be valid JSON, form data becomes URL-encoded key-value pairs, and raw text is sent as plain text unless a different content type is supplied. GET and HEAD normally carry no body in browser workflows, while methods such as POST, PUT, and PATCH often do.

Timing is evidence about the whole browser-observed attempt, including network travel, redirects, server work, and response-body reading. It is not an isolated server-processing measurement. Compare repeated tests only when endpoint, payload, cache policy, credentials, network conditions, and timeout are similar.

API tests often contain bearer tokens, passwords, keys, cookies, personal records, or internal URLs. Use approved non-production endpoints and short-lived credentials where possible. Before sharing any trace or response, remove secrets and sensitive payload fields even when the visible authorization value has been redacted.

How to Use This Tool:

Build or import one browser request, check its validation state, then send it only when the target and side effects are understood.

  1. Choose Build request or Import cURL. Import recognizes an absolute HTTP(S) URL, method, common header and data options, Basic credentials, and bearer-token forms, then returns to editable request fields without sending.
  2. Select the HTTP method and enter an absolute Request URL. Use a disposable or read-only endpoint first when the effect of a state-changing method is uncertain.
  3. Add one Header-Name: value pair per line and choose authentication only when required. Explicit Bearer, Basic, or API-key values apply to the current request and are excluded from saved presets.
  4. For methods that allow a payload, choose JSON, Form URL encoded, or Raw text. Invalid JSON stops the request before transmission; form mode expects one key=value pair per line.
  5. Open Advanced to set a 0 to 120,000 ms timeout, redirect behavior, browser credential policy, cache policy, or a reusable browser-local preset. A timeout of 0 disables the explicit abort timer.
  6. Choose Send request, then compare the status, response body, exposed headers, final URL, elapsed time, and response size. If the browser reports no exposed response, check CORS, mixed-content policy, connectivity, redirect policy, and credentials before treating it as a server status failure.

Interpreting Results:

Read the HTTP status as a category, then verify the body. A 2xx response means the HTTP operation was accepted as successful, not that every expected field or business effect is correct. A 4xx response points toward the request, authentication, permissions, route, or validation. A 5xx response says the server failed while handling the exchange.

The final URL matters when redirects are followed, and the exposed Response headers may be only a subset of what the server sent. The Exchange trace redacts authorization and API-key-looking request headers, but URLs, bodies, ordinary headers, and response content can still contain sensitive data.

A browser error does not supply a reliable hidden status code. Reproduce the request in a server-side client when you need to separate endpoint reachability from browser policy, and compare the same method, headers, credentials, body, and redirect expectations.

Technical Details:

A browser API request is assembled from the chosen method, validated absolute URL, parsed header lines, explicit authentication, optional encoded body, redirect mode, credentials mode, cache mode, and abort signal. Fetch then applies the browser's HTTP and CORS rules before page code can inspect the response.

Mechanism Core:

Browser API request and response mechanism
Stage Rule Observable evidence
Validate The URL must use HTTP or HTTPS; header names must contain letters, digits, or hyphens; timeout must be a whole number from 0 to 120,000 ms; selected auth fields and JSON syntax must be complete. The send action remains unavailable and the first input issue is shown.
Encode body JSON is parsed and serialized with application/json; form lines become URL-encoded pairs; raw input uses text/plain;charset=UTF-8. An explicit Content-Type header takes precedence. The request trace shows the body and content type used.
Apply auth Bearer and Basic modes set Authorization; API-key mode sets the named header. Explicit auth is separate from the browser credentials policy. Sensitive header values appear as [redacted] in the trace.
Fetch The browser applies CORS, redirects, credentials, caching, mixed-content checks, and an optional abort timer. A normal response or a browser-level error is returned to page code.
Read response The complete exposed body is read as bytes. At most the first 2 MiB is decoded for display, while total byte count still describes the full exposed response. Status, elapsed time, size, visible headers, body text, final URL, and exchange trace.

Formula Core:

Elapsed time starts immediately before Fetch and ends after the exposed body has been read. The timeout chart also shows how much of a nonzero browser-side timeout remained.

telapsed = tfinish - tstart
tremaining = max ( ttimeout - telapsed , 0 )

If timeout is 9,000 ms and the exposed response finishes in 640 ms, the remaining budget is 8,360 ms. When timeout is 0, the remaining budget is reported as 0 because no explicit abort budget was set. Timing is rounded to whole milliseconds.

CORS is a response-sharing protocol layered over HTTP. Some cross-origin requests trigger a preflight before the intended method is sent. Credentialed cross-origin responses require explicit server permission, and the wildcard origin cannot authorize a credentialed response. Manual redirects may appear opaque because browser APIs intentionally limit redirect details.

Saved presets keep up to 50 reusable non-secret request definitions in the current browser. Recent history keeps up to 12 compact run records. Neither storage area proves that a remote server discarded the request or response; the target service controls its own logs and retention.

Privacy and Safety Notes:

The browser sends the request directly to the URL entered. The destination can receive the method, URL, headers, explicit authentication, allowed browser credentials, and body. Browser-local presets exclude secrets, but response bodies, traces, local history, copied text, and downloaded artifacts may still reveal private data.

  • Prefer test accounts, short-lived credentials, and reversible endpoints for state-changing requests.
  • Do not assume cancellation or a browser timeout means the server stopped processing a request already received.
  • Review URLs, bodies, response data, and non-auth headers before sharing a trace.

Worked Examples:

Reproduce an authenticated JSON request

Import a cURL command containing a URL, POST, an Accept header, a bearer token, and a JSON body. Confirm the imported fields before sending. A 401 response points toward the token or its permissions; malformed JSON is rejected locally before any request is made.

Separate CORS from endpoint reachability

If the browser reports that it could not expose a response, repeat the same request with an approved server-side client. A server response there, combined with a browser failure here, is evidence to inspect CORS and browser policy rather than inventing an HTTP status that page code never received.

FAQ:

Why can cURL work when the browser request fails?

cURL is not governed by browser CORS, mixed-content, exposed-header, cookie, or opaque-redirect rules. Match the request details, then inspect the target server's CORS response and the browser console.

Does canceling a request undo it?

No. Cancellation stops the browser from waiting for the response, but the server may already have received and processed the request. Verify remote state before retrying a write.