Generate realistic HTTP header lines — request, response, or both — using standard, RFC-defined header names paired with plausible, format-correct values. Handy for mock servers, parser fuzzing, and documentation.
How it works
An HTTP header is a Name: value pair on its own line. This tool keeps separate
tables of standard request and response headers, then for each chosen header it
generates a value that matches that header’s expected shape:
Authorization: Bearer <random token>
Content-Type: <random MIME type>
Date: <current GMT date>
Cache-Control: <random directive>
Names are real and standard; values are fabricated but format-correct, so the output parses like genuine traffic without exposing any real data.
Tips and notes
Header names are case-insensitive per the spec, though the canonical
capitalization (such as Content-Type) is conventional and used here. When
feeding the output into a strict parser, keep the single space after the colon
and one header per line — both are what well-behaved clients and servers emit.
When this tool is genuinely useful
Building a mock API server. When writing integration tests against a stub server, you need realistic response headers — not just Content-Type: application/json. Generating a set of plausible Cache-Control, ETag, X-Request-Id, and Vary headers makes the mock behave like a real server and surfaces header-parsing bugs your code might not hit with minimal stubs.
Fuzzing an HTTP parser or middleware. Parser vulnerabilities — header injection, malformed-value handling, oversized header lines — are best found by feeding a parser a wide variety of header combinations it was not written to expect. Randomised but format-valid headers let you explore the normal-value space before moving to edge cases.
Teaching and documentation. When writing a tutorial on how HTTP headers work, you need plausible examples that do not expose credentials or real IP addresses. The generator produces illustrative Authorization, Set-Cookie, and User-Agent lines that read like real traffic.
Populating test-data fixtures. If your test suite needs a JSON array of realistic HTTP exchange objects, you can generate batches of request/response pairs here and paste them straight into your fixture files.
Request vs. response headers — a quick guide
| Type | Examples | Direction |
|---|---|---|
| Request | Accept, Authorization, User-Agent, Referer, Cookie | Client to server |
| Response | Content-Type, Set-Cookie, Cache-Control, ETag, Location | Server to client |
| Both | Content-Length, Date, Transfer-Encoding | Either direction |
Some headers appear in both directions: Content-Type in a request body (POST/PUT) or in a response body is valid, for instance.
Pasting the output into common tools
- curl: save the block to a file and pass it with
curl -H @headerfile. EachName: valueline in the file becomes a request header. - Postman / Insomnia: paste lines into the Headers tab; the tool splits on
:automatically. - Node.js test with
node-fetchorundici: convert lines to aHeadersobject by splitting each line on the first:. - OpenAPI / Swagger stub: copy specific response headers into the
headersmap of a response object in your spec.