About the Header Normalizer
HTTP header names are case-insensitive per RFC 9110, but real-world tooling often is not: hand-written proxies, log parsers, header-based routing rules, and string-matching middleware regularly break on x-request-id vs X-Request-ID. This tool canonicalizes header casing and formatting to the conventional Title-Case-With-Hyphens form.
It is also useful when moving between HTTP/1.1 and HTTP/2 or HTTP/3 — HTTP/2 transmits all header names lowercase on the wire, which surfaces case-sensitivity bugs in code that worked fine against HTTP/1.1 servers.
Frequently asked questions
Are HTTP header names case-sensitive?
No — RFC 9110 defines field names as case-insensitive, so Content-Type, content-type, and CONTENT-TYPE are equivalent. But header values can be case-sensitive depending on their definition, and buggy middleware that string-matches names without normalizing is common, which is why canonical casing still matters in practice.
Why do my headers appear lowercase in HTTP/2?
HTTP/2 (and HTTP/3) require all header field names to be lowercase on the wire; HPACK/QPACK compression depends on it. Your client may send X-Request-Id, but the server will see x-request-id. Any code comparing header names case-sensitively breaks the moment a load balancer upgrades the connection to HTTP/2.
What is the canonical casing convention?
Title case on each hyphen-separated token: Content-Type, Cache-Control, X-Forwarded-For. A few historical oddities exist (ETag, WWW-Authenticate, TE), which is why normalizers carry an exception list rather than applying the rule blindly.
Need this managed for you, not just automated?
We're also a hands-on DevOps consultancy — Kubernetes, CI/CD, and cloud infrastructure.