| On | Key | Value | Remove |
|---|---|---|---|
|
|
| On | Header | Value | Remove |
|---|---|---|---|
|
|
| On | Key | Value | Remove |
|---|---|---|---|
|
|
| On | Key | Type | Value / File | Remove |
|---|---|---|---|---|
|
|
Selected: {{ row.file.name }}
Reattach file: {{ row.savedFileName }}
|
| Metric | Value | Copy |
|---|---|---|
| {{ row.label }} | {{ row.value }} | |
| No response metrics. | ||
{{ formattedBody }}
| Header | Value | Copy |
|---|---|---|
| {{ h.key }} | {{ h.value }} | |
| No headers returned. | ||
| Captured | Method | URL | Result | Actions |
|---|---|---|---|---|
| {{ formatRecentRunTime(entry.createdAt) }} | {{ entry.method }} | {{ entry.url }} |
{{ entry.status !== null ? `HTTP ${entry.status}` : 'Status unknown' }}
{{ recentRunStatusLabel(entry) }}
· {{ entry.elapsedMs }} ms
· {{ entry.responseType }}
|
|
| No recent runs yet. | ||||
| Name | Method | URL | Actions |
|---|---|---|---|
| {{ entry.name }} | {{ entry.method }} | {{ entry.url }} |
|
| No saved requests yet. | |||
API testing in a browser is really about observing the full request and response relationship, not just sending a URL and hoping for a useful reply. Method choice, query parameters, headers, authentication, body format, redirect handling, credentials mode, cache behavior, response headers, body decoding, and browser CORS policy can all change what you are allowed to see and how the result should be interpreted.
This tool turns that workflow into one browser-local console. It lets you compose a request, paste a full cURL command to populate the form, load safe starter recipes, send the call directly from the browser, then inspect the response as raw text, formatted JSON, sandboxed HTML, request and response traces, a response-header table, and a combined request-plus-response payload export.
That makes it useful for day-to-day debugging. You might replay a small JSON POST and confirm the echoed fields, test redirect behavior without automatically following the next hop, compare header changes across two runs, or prove that a failure is really a browser CORS block rather than a server-side 500. The tool is designed to keep those questions in one place instead of splitting them across a console, a cURL shell, and browser devtools.
It also includes stateful conveniences that matter during longer investigations. Saved requests live in browser storage, recent runs keep a short local history, request recipes provide browser-safe starting points, and export actions let you carry the current snapshot, headers, JSON body, or full request-plus-response payload into another document without reconstructing the test later.
The key limit is architectural. Requests are sent directly from the browser to the target endpoint. That means the tool cannot bypass CORS, cannot see server-only network paths, and cannot preserve secrets safely if you paste credentials that should never live in local browser storage. It is a precise browser-side API workbench, not a proxy service or a server-side capture appliance.
Start with the request target and method, then decide whether you are beginning from scratch or from a known pattern. The recipe cards are useful when you want a safe baseline for JSON, HTML, redirects, or a blank request shell. The cURL parser is faster when someone has already handed you a command line and you want the browser form populated automatically instead of retyping method, headers, and body by hand.
The request body mode should match the server’s expectations rather than your editing preference. Raw is the most flexible when you want to send exactly what you typed. JSON is useful when the payload should be valid JSON and you want quick pretty-printing in the editor. x-www-form-urlencoded is for classic key-value bodies. multipart/form-data is for mixed text and file parts, with the browser generating the boundary automatically.
Authentication is explicit. Basic turns username and password into a Base64-encoded Authorization header. Bearer passes the token as entered. Credentials mode and cache mode are separate decisions that influence how the browser behaves, not how the server understands the message. Redirect mode is equally important because a manual redirect test answers a different question from a normal follow path.
The response tabs answer different classes of question. The main snapshot shows status, URL, size, time, and headline badges. The request trace is for confirming what was actually sent. The response trace is for status line, headers, body, and timing context. Response JSON and HTML preview are for content interpretation. The headers table is for field-by-field inspection. The combined request-plus-response JSON export is for preserving the exact browser-observed transaction state.
The CORS note should be taken literally. If the target does not allow your origin, the browser can block access to the response even when the server replied. In that situation the tool is still useful because it tells you that the failure is happening at the browser-policy layer, but it cannot read through that block. That is a feature of the browser model, not a defect in the tool.
The request builder starts with the final URL, which is formed from the target plus enabled query rows. It then merges enabled header rows, applies authentication if Basic or Bearer mode is selected, and decides whether a request body is allowed based on the HTTP method. GET and HEAD ignore the body. Other methods can send raw text, JSON, URL-encoded form data, or multipart form data, with content type inferred when appropriate and missing.
The transport path is direct browser fetch, not a relay. Timeout is enforced locally through an abort controller. Redirect mode, credentials mode, and cache mode are passed through to the fetch request. If the browser cannot access the target response because of network failure, timeout, cancellation, or CORS policy, the tool records that outcome as a browser-observed failure rather than fabricating a server result.
| Stage | Package behavior | Why it matters |
|---|---|---|
| URL assembly | Builds a final URL from the target plus enabled query rows, preserving existing query terms | Lets you test parameter changes without hand-editing encoded URLs |
| Header merge | Combines enabled header rows and adds Authorization when auth mode is active |
Makes the raw request trace match the actual browser request state |
| Body preparation | Supports raw text, JSON, URL-encoded form data, and multipart form data | Keeps request-body shape aligned with common API input styles |
| Fetch options | Applies timeout, redirect, credentials, and cache settings to the browser fetch call | Explains behavior that often differs between browser calls and shell tools |
| Response capture | Records status, resolved URL, headers, body text, size, type, and elapsed time | Turns one request into a complete debug snapshot instead of a raw body dump |
Response handling is content-aware. The package reads the response buffer, estimates size from the received bytes, and decodes textual bodies using the charset declared by Content-Type when one is present, falling back to UTF-8 when needed. JSON is detected either from content type or from likely body structure and then pretty-printed. HTML is rendered in a sandboxed preview. Binary bodies are still captured for size and metadata, even when no human-readable preview makes sense.
Trace output is deliberately redundant. The raw request preview shows the method, final URL, headers, and body that the browser-side tool assembled. The response trace shows the status line, headers, response body, and timing details. That duplication is useful because debugging often depends on proving whether the request itself was malformed or whether the server replied in an unexpected way.
State persistence is local to the browser. Saved requests are stored in localStorage, can be exported as JSON, and can be imported back into the editor. Recent runs keep a shorter rolling record, up to the package’s built-in limit. Multipart file rows preserve the field structure but cannot preserve file objects themselves, so reattachment is still required after reload or import.
| Capability | Supported options | Operational note |
|---|---|---|
| HTTP methods | GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS | GET and HEAD ignore request bodies in the package logic |
| Authentication | None, Basic, Bearer | Basic is encoded as Base64 of user:pass; Bearer is passed as entered |
| Body modes | Raw, JSON, URL-encoded form, multipart form data | JSON can be beautified; multipart relies on browser-generated boundaries |
| Transport controls | Timeout, redirect mode, credentials mode, cache mode | These influence browser behavior and can change what is observable |
| Result surfaces | Snapshot, traces, headers, response JSON, HTML preview, combined payload JSON, saved history | Each surface answers a different debugging question |
The status code is the first clue, not the whole answer. A success code can still hide a wrong payload. A redirect can be expected or suspicious depending on the redirect mode you chose. A client error often means something in the request shell needs correction. A server error means the request reached the service, but the service did not complete the work cleanly.
The error message should also be read in context. A timeout message tells you the browser gave up before a usable response arrived. A cancellation message tells you the request was intentionally aborted. A CORS-related message means the browser blocked access to the response because the target did not allow the current origin or related access pattern. That is different from an HTTP 4xx or 5xx response, which the browser was allowed to read.
Headers, content type, and body interpretation should be read together. If the content type says JSON but parsing fails, the server may be mislabeling the response or returning malformed JSON. If the body is HTML, the sandboxed preview is helpful for quick inspection, but the raw trace is still the safer truth source for debugging. If the content is binary, size and headers matter more than preview text.
A teammate sends a cURL command that reproduces a failing POST. You paste it into the cURL field, let the package split the URL, headers, auth, and body into structured form, then resend it as a browser request to see whether the issue is the payload itself or a browser-only condition such as CORS.
A redirecting endpoint behaves differently depending on whether the caller auto-follows the next location. Setting redirect mode to manual lets you inspect the response status and headers instead of jumping straight to the next page, which is often the fastest way to confirm where the redirect logic is pointing.
You build a request with specific headers, a short timeout, and a JSON body that reproduces an issue. Saving that request locally means the next test can start from the same shell instead of rebuilding it. Exporting the saved requests JSON also gives you a portable session record that can be re-imported later.
No. Requests are sent from the browser, so the browser still enforces cross-origin rules and can block access to the response.
They are stored locally in the browser and can be exported or imported as JSON. They are not relayed through a tool-specific backend.
Because browser file objects are not preserved in saved request snapshots. The field structure can persist, but files still need to be reattached.
No. It is a practical parser for common cURL request shapes so the browser form can be populated quickly, not a complete shell interpreter.