API Request Header Builder
Build request-header snippets while validating names, values, repetitions, browser-controlled fields, authentication, and CORS boundaries.
Request header rows
Empty values are allowed. Raw CR/LF and unsafe control characters are rejected so a value cannot create a second header line.
Validated HTTP request-header output and browser/API review notes will appear here.
A Header Name and Value Can Be Syntactically Fine and Still Be Wrong for the Request
HTTP defines a general field model, but individual field specifications define what each value means. Authorization: Bearer ... can be valid syntax and still fail because the token has the wrong audience. Content-Type: application/json can be valid and still be wrong when the request body is multipart data.
The structural checks cover field syntax and common browser/API traps. The target API contract remains the authority on required authentication schemes, media types, versions and custom fields.
Accept and Content-Type Answer Opposite Sides of the Representation Conversation
Content-Type: application/json Accept: application/problem+json, application/json
Content-Type describes the representation enclosed in this request when there is one. Accept expresses which response media types the client can accept. A GET request with no body often needs Accept but has no reason to claim it is sending JSON.
Servers can use content negotiation differently, so API documentation still decides whether either field is required.
Browsers Do Not Let JavaScript Control Every HTTP Request Field
The Fetch standard and browser implementations reserve or control fields such as Host, Content-Length, Connection, Cookie, Origin and Sec-* request metadata. High-level browser code cannot treat the network request like a raw TCP header editor.
When Fetch output contains one of those names, a warning appears rather than producing a false promise that the browser will send the line exactly as written. cURL, backend clients and proxy libraries have different levels of control.
Custom Authentication Headers Can Change CORS Before the API Code Runs
Cross-origin browser requests have a small set of CORS-safelisted request headers and value restrictions. Authorization, X-API-Key and most custom fields are not simple safelisted request headers.
That can trigger a preflight OPTIONS request. If the server does not answer the preflight with compatible Access-Control-Allow-Origin, Access-Control-Allow-Methods and Access-Control-Allow-Headers behavior, the browser can block the frontend request even though the same cURL request works perfectly.
Duplicate Header Lines Are Not Universally Invalid—and Not Universally Safe Either
HTTP's general field model allows repeated field lines for fields whose definition permits combination. But fields have their own semantics. Sending two Authorization lines or two conflicting Content-Type fields is usually a configuration smell even though a generic parser can represent both.
The old Yoryantra builder rejected every duplicate. This version preserves repeated fields in raw HTTP, Fetch Headers.append(), cURL and JSON pair output, then warns more strongly for fields that are normally one logical request value.
CR/LF in a Header Value Is Not a Clever Way to Add a Second Header
Building a header block from user-controlled text without rejecting line breaks can create header-injection or response/request splitting problems in vulnerable systems. Modern HTTP libraries generally prohibit this, but code generators should not normalize dangerous input into apparently valid examples.
CR, LF, NUL, DEL and unsafe control characters are rejected in field values. If the API needs a multiline logical value, use that field's defined encoding/serialization rather than raw message framing characters.
Content-Length Is Usually the Client's Job
Content-Length describes the size of the message content in bytes under HTTP framing rules. A JavaScript string length is not automatically that byte length, and transfer/content codings can further affect what a client sends.
High-level HTTP clients calculate framing fields from the body they serialize. Hard-coding Content-Length in an example is fragile and browsers do not let Fetch scripts control it directly.
JSON Object Output Cannot Faithfully Represent Duplicate Field Names
A JavaScript/JSON object has one property slot for a given key. Serializing two X-Tag lines to an object therefore either overwrites one value or invents an array convention that a client may not understand.
For that reason the JSON mode emits an array of [name, value] pairs. It preserves order and duplicate names without pretending every HTTP client accepts an arbitrary object shape.
cURL Quoting Is Shell Syntax, Not HTTP Syntax
The -H argument tells cURL what header field line to add. The quotes around that argument are interpreted by your shell before cURL receives it. Bash/zsh-style POSIX quoting is different from Windows Command Prompt or PowerShell quoting.
The cURL output is labelled as POSIX-shell flags and escapes embedded single quotes accordingly. If you paste those flags into another shell, translate the shell quoting rather than modifying the actual HTTP header value.
Placeholder Credentials Should Stay Placeholders in Documentation
Bearer tokens and API keys routinely escape through issue trackers, copied terminal commands, screenshots, browser history, chat logs, code examples and CI output. Copyable snippets make accidental disclosure easier, so keep reusable examples without real secrets.
Use obvious placeholders in reusable snippets. When a real secret must be used for a local test, avoid saving the generated output and rotate the credential if it is exposed outside the intended environment.
Defines the general HTTP field model, field-name token grammar, field values, repeated field lines and common request semantics.
Defines browser Fetch behavior, forbidden request-header names, CORS-safelisted request headers and browser-controlled request processing.