HTTP Header Formatter

Features

• Handles both request and response headers; `curl -I` output works as-is
• Repeated names are kept as separate rows, never merged (a dozen `Set-Cookie` lines is normal)
• Continuation lines are folded back with a single space
• `Content-Length` becomes a readable size; the `Content-Type` charset is extracted
• The status code is pulled out of the status line for easy lookup
• Checks a response for three missing security headers and says what each gap costs
• Parsed entirely on your device — the headers never leave it

How to use

1. Paste the raw headers into the left pane (`curl -I https://…` output is fine)
2. Turn the security check off if you do not want it
3. Results appear immediately; every row can be copied on its own
4. To look into a cookie, take the `Set-Cookie` lines over to Cookie Formatter

FAQ

Why are two rows showing the same header name? Is the parse broken?

No — that is correct. HTTP allows a header to appear more than once, and `Set-Cookie` is the common case: a dozen `Set-Cookie` lines in one response is entirely ordinary, each describing a separate cookie. ⚠️ They are deliberately not merged into one row. Combining repeated values with commas is technically valid HTTP, but `Set-Cookie` is the standing exception: its value can itself contain commas (`Expires=Wed, 21 Oct 2015 07:28:00 GMT`), and once joined there is no way to split them apart again. The result is a parse that looks successful while a cookie has gone missing.

What is a "continuation" line?

An older style where a long header value wraps onto several lines, with each following line starting with a space or tab to mark it as a continuation. ``` X-Custom: part one part two ``` Those two lines are one header whose value is `part one part two`. RFC 7230 deprecated the style (it is easy to confuse with a body and hard to parse correctly), but it still turns up in capture tools and older gateways, so it is handled and labelled here.

Do I have to add every security header it flags?

It depends, but all three deserve a serious look. `X-Content-Type-Options: nosniff` costs essentially nothing and belongs on any site — without it, a browser may treat a user-uploaded file as a script. `Strict-Transport-Security` only means anything on HTTPS, and note that it is hard to take back once served (browsers remember the `max-age`), so start with a short value. `Content-Security-Policy` is the most valuable and the easiest to misconfigure: a strict policy applied in one go will very likely blank your page, so start with `Content-Security-Policy-Report-Only` and collect violation reports before switching over. Also worth knowing: these three only make sense on responses, so pasting a request will not trigger the check.