URL Encoded Content Type: application/x-www-form-urlencoded

What the body looks like

Key-value pairs joined by &, keys and values separated by =, everything percent-encoded — with one difference from a URL query string: a space is +, not %20:

POST /login HTTP/1.1
Content-Type: application/x-www-form-urlencoded

username=alice&password=s3cr%26t&remember=on

Because + means space, a literal plus must be %2B. This is the single most common bug with form encoding: a phone number +380501234567 arrives as a leading space unless encoded.

Versus the alternatives

A query string carries the same format in the URL, where it is visible in logs, browser history and referrer headers. Form-encoded bodies keep values out of those places, which is why credentials go in the body.

multipart/form-data is for file uploads — form-urlencoded cannot carry binary efficiently, since every byte would need escaping.

JSON handles nested structures and types; form encoding is flat strings only. Nesting requires conventions such as filter[status]=active, which every framework parses slightly differently.

Sending one

Let the client library build the body so encoding is handled per value:

# curl sets the content type automatically
curl -X POST https://example.com/token \
  --data-urlencode "grant_type=client_credentials" \
  --data-urlencode "scope=read write"

// fetch — URLSearchParams sets the header for you
await fetch('/token', {
  method: 'POST',
  body: new URLSearchParams({ grant_type: 'client_credentials', scope: 'read write' }),
});

Passing a URLSearchParams object as the body makes the browser set Content-Type automatically — setting it by hand while sending a JSON string is a frequent mismatch that produces empty parameters server-side.