HTTP Request Generator
See an HTTP request as it really travels over the network: request line, headers, blank line, body. Fill in the form and get the exact message, with Host, Content-Length and multipart boundaries worked out, or a .http file that editors can run directly.
- Runs in your browser
- No sign-up
- Free to use
The message is generated in your browser. Nothing is sent.
How to use HTTP Request Generator
- Choose the method and enter the URL.
- Add parameters, headers, authentication and a body.
- Choose the raw message or the .http file format and set its options.
- Copy the text, or download it with correct line endings.
HTTP Request Generator features
Exact wire format
Request line, Host header, your headers, a blank line and the body, as defined by the HTTP/1.1 specification.
Content-Length computed
The body size is counted in bytes of UTF-8 with CRLF line endings.
Multipart bodies
Boundaries and part headers are generated for multipart/form-data, including file parts.
.http files
Output for the VS Code REST Client and the JetBrains HTTP Client, optionally with variables for the base URL and secrets.
CRLF download
The downloaded file uses the line endings HTTP requires, which a copy from a text box cannot guarantee.
Basic auth encoded
The Authorization header is computed from user name and password.
When to use HTTP Request Generator
- Learning or teaching what an HTTP request consists of.
- Keeping a collection of API requests as .http files next to the code.
- Sending a hand-written request with netcat or openssl to debug a server or proxy.
- Writing test fixtures for an HTTP parser, a proxy or a web application firewall.
HTTP Request Generator FAQ
How is this different from the cURL Generator and the API Request Builder?
Those produce commands and code that ask a program to send a request. This tool produces the request itself: the text that program would put on the connection, or a .http file that an editor sends as written.
What is a .http file?
A plain text file containing one or more requests in a format close to raw HTTP. The REST Client extension for VS Code and the HTTP Client built into JetBrains IDEs can run each request with a click and show the response. Because they are text, such files can be versioned with the project.
Why does the request line contain only the path?
In HTTP/1.1 the request line holds the method, the path with the query string, and the version. The host name travels separately in the Host header, which allows many sites to share one IP address. The .http format puts the full URL in the request line for convenience.
Why do line endings matter?
HTTP/1.1 separates lines with a carriage return and a line feed, CRLF. Many servers tolerate a bare line feed, but not all, and Content-Length must match the bytes actually sent. Use the download button for a file with the right endings.
Is this what HTTP/2 looks like?
No. HTTP/2 and HTTP/3 carry the same information, method, path, headers and body, in a binary framing that is not human-readable. The textual HTTP/1.1 form remains the standard way to write a request down.
Can I send the raw message?
Yes, with a tool that opens a plain connection: nc or telnet for http://, and openssl s_client for https://. The notes below the output give the command for your URL.
The anatomy of an HTTP request
Underneath every API call, page load and webhook is a short piece of text with a fixed structure. The first line, the request line, names the method, the target and the protocol version. Then come the headers, one per line, each a name, a colon and a value. An empty line marks the end of the headers. Whatever follows is the body. The response from the server has the same shape, with a status line in place of the request line.
A few headers are structural. Host is mandatory in HTTP/1.1 and tells the server which site is meant. Content-Length gives the size of the body in bytes, so the receiver knows where the message ends; it counts bytes, which differs from the number of characters as soon as the text contains anything outside ASCII. Content-Type says how to interpret the body. Connection: close asks the server to end the connection after replying, which is useful when sending a request by hand, since otherwise the connection stays open waiting for the next one.
Bodies come in a handful of encodings. JSON is sent as is. A URL-encoded form joins name=value pairs with ampersands and percent-encodes special characters. A multipart form, the only one that can carry files, separates its parts with a boundary line that must not occur in the content, and each part has small headers of its own. Getting the boundary and the final closing marker exactly right by hand is tedious, which is one reason to generate it.
Being able to read and write this format pays off whenever a layer in between misbehaves. Proxies, load balancers, firewalls and caches all operate on these lines. Sending a precise request by hand and reading the raw reply often settles in a minute what an hour of guessing through a high-level client does not.