Content-Type header defined.
The Content-Type header is the line in an HTTP request that tells the server what format the body is in, so it knows how to read the bytes that follow.
How the Content-Type header works
A request body is just a stream of bytes, and those bytes could be anything: a form's fields, a JSON object, an uploaded image. The Content-Type header removes the guesswork by naming the format, using a media type like application/x-www-form-urlencoded, multipart/form-data or application/json. The server reads that header first, then picks the right parser to turn the body back into structured data.
Browsers set this header for you automatically. A plain HTML form sends application/x-www-form-urlencoded by default, and switches to multipart/form-data (with a boundary marker) the moment the form includes a file input. A fetch call, by contrast, sends whatever you tell it to, so you set the header yourself when POSTing JSON. A form backend has to accept all three, because that's what real browsers and scripts send. FormWire's endpoint reads the Content-Type on every submission, parses form-encoded, multipart and JSON bodies alike, and hands you the same clean set of fields whichever one arrived.
Three media types, one endpoint.
form-urlencoded
The default for a plain HTML form. Fields are packed as key=value pairs, the same shape a query string uses, in the request body.
multipart/form-data
What the browser switches to when a form carries a file. Each field becomes its own part, separated by a boundary the header declares.
application/json
What a fetch call sends when you POST a JavaScript object. Here you set the header yourself, because no form tag is doing it for you.
Related questions
Not for a plain HTML form. The browser sets it automatically based on the form's enctype, and switches to multipart the moment you add a file input. You only set it by hand when you submit with fetch, because then you control the request entirely.
The server tries to parse the body with the wrong parser and usually fails, so the fields come back empty or garbled. A common bug is sending a JSON body while leaving the header as form-urlencoded, which makes the whole payload arrive as one unreadable key.
They're two sides of the same coin. The enctype attribute on a form tells the browser how to encode the body, and the browser then advertises that choice to the server in the Content-Type header. Set enctype, and the matching header follows automatically.
See how enctype maps to the header →No. The endpoint inspects the header and parses form-encoded, multipart and JSON bodies the same way, returning one consistent set of fields. That means a plain HTML form and a fetch call can both hit the same URL with no special handling.
Want to see it working?
Read the docsHow FormWire fills the role.
Send any content type and let the endpoint parse it.
Free tier forever. No credit card required.