Request Header Builder

Build request header blocks, cURL flags, JSON pairs, or Fetch headers without silently dropping duplicate fields.

Header Rows

Add request headers as normal name and value pairs.

Common Headers

Add common headers quickly, then edit the values if needed.

Auth Header

Auth Type

Output Options

Output

Hide sensitive valuesReplace Authorization, Cookie, API key, and token-like values with placeholders.Skip empty valuesLeave out headers with no value.Sort headersSort output alphabetically by header name.

Active Headers

Output Type

Header block

Auth

None

Length

Header Output

Header output will appear here.

Header generation runs in this browser session. The page does not send entered header values to an API. Masking is a sharing aid, not a guarantee that every custom secret name will be recognized.

Build Fields Without Losing Their HTTP Meaning

HTTP field names are case-insensitive tokens, but field values are defined by each header’s specification. Duplicate field names are therefore preserved instead of being silently collapsed: some fields allow repeated or list-like values, while others have stricter semantics.

RFC 9110 defines the common field-name syntax and HTTP field model. The builder blocks invalid field names and line-breaking characters before producing output. See RFC 9110, Section 5 for the HTTP field rules.

Output Formats Preserve Different Things

Header block: keeps each field line in order.
JSON header pairs: uses an array of name/value pairs so duplicate names are not lost.
cURL headers: uses POSIX-shell-safe single quoting for the URL and each -H argument.
Fetch headers: emits a header-pair array, but browsers can still block or control particular request headers.

Authorization Needs More Than Formatting

Bearer tokens are copied with the Bearer scheme. Basic credentials are entered as username:password and Base64-encoded; Base64 is reversible and provides no confidentiality. Send credentials only over HTTPS and follow the server’s authentication requirements.

RFC 7617 defines HTTP Basic authentication, including charset considerations for non-ASCII credentials. See the RFC 7617 specification.

Browser Fetch Has Its Own Boundary

A syntactically valid HTTP header is not automatically writable from browser JavaScript. Fetch maintains a forbidden or browser-controlled request-header set for security and protocol reasons. The builder flags names such as Cookie, Host, Content-Length, and Sec-* when Fetch output is selected.

A header can also be writable and still make a cross-origin request non-simple. For example, Authorization, custom API-key fields, and Content-Type: application/json are not CORS-safelisted request headers in those forms, so they can contribute to a preflight request. The warning is intentionally a practical hint rather than a complete CORS simulator because the request method, origin, credentials, and additional value restrictions also matter.

The forbidden request-header and CORS-safelisted request-header sections of the WHATWG Fetch specification are the authoritative references for these browser boundaries.

Before Sharing a Header Set

Authorization values, cookies, API keys, session identifiers, and custom secret headers can grant access to real systems. Keep masking enabled for examples, then inspect the final output because no name-based detector can recognize every organization-specific secret.