HTTP Response Builder

Build mock HTTP responses with custom status, headers, and body for API testing and documentation.

Presets

Response Config

Version

Status Code

Common Statuses

Headers

Body

HTTP Response Output

HTTP/1.1 200 OK
Content-Type: application/json
Date: Fri, 28 Aug 2026 15:17:26 GMT

{"status":"ok","message":"Hello, World!"}

HTTP VersionHTTP/1.1

Status Code200 (OK)

Headers Count2

Total Output Size125 B (Body: 41 B)

HTTP Response Builder

Mock HTTP responses are essential for API testing, documentation, and frontend development. This builder lets you construct a complete HTTP response message — status line, headers, and body — in the exact wire format defined by RFC 7230. Use it to generate examples for API docs, test parsers, or share expected responses with teammates. All processing runs entirely in your browser.

Built and maintained by Meet Shah · Last updated 1 August 2026

What this tool is used for

Composing a mock response for a client test.
Building a response with specific headers to reproduce a bug.
Producing an example response for documentation.
Testing how a client handles a particular status code.
Learning the raw response format rather than a library's abstraction.

Frequently Asked Questions

What is the difference between 401 and 403?: 401 means "I do not know who you are" — no credentials, or invalid ones — and it must include a `WWW-Authenticate` header saying how to authenticate. 403 means "I know who you are and you still may not". Returning 401 for an authenticated-but-unauthorised user tells clients to re-login pointlessly.
When should I use 422 rather than 400?: 400 for a request the server could not parse — malformed JSON, a broken header. 422 for one that parsed perfectly but failed validation: well-formed JSON with an email field containing no `@`. The distinction tells a client whether to fix its serialisation or its data.
301 or 302?: 301 is permanent and browsers cache it aggressively — often indefinitely, which makes a mistaken 301 very hard to take back from users who already have it. 302 is temporary and re-checked. Use 308 and 307 when the method must be preserved; 301 and 302 historically allowed POST to become GET.
What is 204 for?: Success with deliberately no body — the response must not have one. It is the right answer to a DELETE that worked or a PUT with nothing to return, and it saves the client parsing an empty object. Sending `{}` with a 200 instead is the commonest small API design mistake.
Does the status line's reason phrase matter?: Not to any client. "OK" and "Not Found" are for humans reading a trace; HTTP/2 removed the reason phrase from the wire format entirely. Clients branch on the numeric code, so never encode meaning into a custom phrase — nothing will read it.

Common errors and gotchas

Returning a status whose semantics contradict the body, such as a 201 with no Location header.
Using LF rather than CRLF line endings, which the protocol requires.
Sending a body with a 204 or a 304, which must not have one.
Forgetting the blank line between headers and body.
Assuming a raw response is valid over HTTP/2, whose framing differs entirely.