HTTP & GraphQL Request Tester
Send HTTP or GraphQL requests in your browser; inspect status, GraphQL errors and byte-accurate response bodies.
URL, headers and body are sent directly to the selected endpoint.
Send only when ready
Enter an HTTP/HTTPS endpoint, method, headers and optional text body. Example fills an illustrative URL and makes no request; replace it with your endpoint before sending. Headers may be a JSON object of string values or an array of string pairs for repeated names. GET and HEAD require an empty body. Fragments are not sent over HTTP.
Browser networking rules still apply
Requests go from this browser to the chosen server. Cross-origin responses require the server’s CORS permission; only exposed response headers are visible. A failed request can indicate CORS, DNS, TLS, mixed-content policy, redirect policy or another network failure. The tool cannot infer an HTTP status from such a failure. It offers no proxy or CORS bypass.
Browser-managed request headers such as Cookie, Host, Origin, Content-Length and Sec-* are rejected before sending. Other headers may still be normalized or adjusted by the browser. Credentials default to omit; include can send applicable endpoint cookies subject to browser policy and requires compatible server CORS settings. Redirects are rejected by default; Follow explicitly permits normal Fetch redirects.
Inspect exact response data
A completed HTTP 4xx or 5xx response remains a response, with its status, visible headers and body. The JSON report contains UTF-8 text when decoding is valid, plus base64 of the exact body bytes. Headers are the browser-visible set, not a raw wire capture. Compressed responses are decoded by Fetch before inspection.
Download body exports response.bin without executing HTML, images or scripts. Download exports the full JSON report; its preview is limited to 200,000 characters. Changing a field or cancelling aborts the current request and clears old output. Request bodies are limited to 1 MiB UTF-8, responses to 2 MiB of decoded bytes, headers to 100 pairs, and timeout to 1-60 seconds. Nothing is saved in local storage.
GraphQL queries and mutations
Select GraphQL mode to compose a document, variables object and optional operation name. It uses the same endpoint, headers, browser credential policy, cancellation and response-byte export as HTTP mode. Example fills a conventional illustrative schema and never sends a request. Replace both endpoint and fields with those supported by your server.
GraphQL.js 17.0.2 checks document syntax, executable definitions and operation selection before any request. A document with several operations needs an exact name; duplicate operation names and a mixed anonymous operation are rejected. Schema validation, field/type checks, fragment validation and variable coercion remain the server’s responsibility. No schema is fetched automatically and no query is run while typing.
POST sends application/json with query, variables and operationName when supplied. GET is available only for queries, with URL-encoded parameters; mutations require POST. Existing query/variables/operationName/extensions URL parameters are replaced, and unrelated parameters are retained semantically. Variables must be a JSON object; their original JSON text is kept in the request so large numeric literals are not silently rounded during serialization. Parsed response details use JavaScript number precision; the original response text and downloaded bytes remain authoritative.
The report distinguishes data, data with errors, errors only, invalid JSON/envelopes and unsupported content types. HTTP status is recorded separately: HTTP 200 with GraphQL errors is not shown as successful data. It inspects JSON and application/graphql-response+json responses, not multipart/defer responses or subscriptions over SSE/WebSocket. It does not prove that a server is GraphQL-conformant.
Documents are limited to 256 KiB and 5,000 parser tokens; variable input to 1 MiB; the complete request body to 1 MiB and GET URL to 8,192 encoded characters. The normal 2 MiB response and 1–60 second request deadline still apply. Server authentication, authorization and CORS apply equally to GraphQL. Parsed GraphQL views are capped at depth 64 and 20,000 inspected nodes. If that view is too complex, the raw body remains available instead of building an unbounded nested report.
Questions & answers
Can it read every server response?
No. Browser CORS, TLS and network policy determine access. Set-Cookie and other hidden headers cannot be exposed by this page.
Is an HTTP error the same as a failed connection?
No. A received 404 or 500 is inspectable. A browser network failure has no reliable response status to report.
Does GraphQL mode validate my schema or bypass CORS?
No. It checks syntax and selects an operation locally, then sends an explicit request. Your server validates its schema and grants browser access; no server proxy is used.
Other Languages
References
How we make sure
We check this tool with the automated test suites linked below. Example checks are shown in their original language.
- Verification method
- Check request parameters, repeated headers, UTF-8/binary responses, error statuses, cancellation and deadlines.
- Comparison reference
- Controlled Fetch responses, byte fixtures and state assertions.
- Verification scope
- This does not guarantee third-party availability or response correctness.
Test source and cases (select a file to read it)
-
live-network-tools.test.js
- HTTP options preserve repeated headers and Unicode bodies without performing I/O on invalid input
- HTTP browser-managed and dangerous override headers are rejected before fetch
- HTTP reports actual error responses, raw UTF-8 bytes and visible headers
- HTTP binary and HEAD-like responses retain exact bytes without replacement decoding
- HTTP cancellation, deadline and generic network failures remain distinct
These checks cover the listed examples and boundaries, not every possible input. Round trips and checks using the same library are not independent verification.