What is application/x-www-form-urlencoded?

It is the default content type for HTML form submissions over POST. Each field becomes key=value, pairs are joined with ampersands, spaces become plus signs, and any reserved or non-ASCII character is percent-encoded as a UTF-8 byte sequence.

Why are spaces encoded as plus signs and not %20?

The form-urlencoded rules predate the modern URL spec and define space as the plus sign. A correct decoder must turn plus back into a space first, then percent-decode. In a path segment, by contrast, a space is %20, which is why form encoding differs from generic URL encoding.

Which characters are left unescaped?

Letters, digits, and the characters star, minus, period, and underscore pass through unchanged. Everything else, including the literal plus sign, equals sign, and ampersand inside a value, is percent-encoded so it cannot be confused with a separator.

How is non-ASCII text handled?

Non-ASCII characters are first converted to UTF-8 bytes, then each byte is percent-encoded. For example an accented e becomes %C3%A9. This matches what browsers send for UTF-8 forms.

Is my data uploaded anywhere?

No. All encoding and decoding runs locally in your browser, so form fields and captured request bodies never leave your device.

What is the HTML Form URL Encoding?

Encode key/value pairs into an application/x-www-form-urlencoded body — spaces as plus signs, reserved characters percent-encoded, pairs joined by ampersands. Also decodes a form body back to readable pairs. Runs in your browser. It runs free in your browser on Gera Tools, with nothing uploaded.

HTML Form URL Encoding

Name: HTML Form URL Encoding
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

application/x-www-form-urlencoded is the wire format browsers use when you submit an HTML form. This tool converts key/value pairs into that body and parses a body back into readable pairs, in your browser.

How it works

Form encoding builds key=value&key2=value2:

Each key and value is encoded independently. Letters, digits, and * - . _ pass through.
A space becomes + (this is the historic form-urlencoded rule, not %20).
Every other character is converted to UTF-8 bytes and each byte is percent-encoded as %XX, so =, &, +, and non-ASCII are all safe.
Pairs are joined with & and each pair is key=value.

Decoding reverses this: split on &, then on the first =, turn every + back into a space, then percent-decode each %XX byte and UTF-8 decode the result.

Worked example

Given the pairs:

name=Ada Lovelace
note=1 + 1 = 2
city=Zürich

The encoded body is:

name=Ada+Lovelace&note=1+%2B+1+%3D+2&city=Z%C3%BCrich

Notice:

The space in Ada Lovelace becomes +.
The literal + inside the note value is escaped %2B so it is not confused with a space when decoding.
The = inside the note value is escaped %3D so it is not read as a separator.
The ü in Zürich is encoded as two UTF-8 bytes: %C3%BC.

When decoding, the + between words must be restored to a space before any percent-decoding happens — getting that order wrong is the classic form-decoding bug.

Where this format appears

Default for <form method="POST"> when no enctype is set.
The body of OAuth 2.0 token requests (Content-Type: application/x-www-form-urlencoded).
Query strings in GET URLs, where the same encoding applies to the query component.
Many webhook payloads and older payment gateway callbacks.

How it differs from JSON

application/x-www-form-urlencoded only supports flat key-value pairs. For nested objects or arrays, the convention is repeated keys (item=a&item=b) or bracket notation (items[0]=a), but there is no single standard. JSON (application/json) avoids this entirely and is the modern preference for API bodies. Use form encoding when the server or spec requires it, or when interacting with HTML form submissions.

Tips

When you see + in a URL query string, it is a space — but only in the query component. Path segments use %20 instead, so context matters when reading URLs.
A correct decoder restores + to space first, then runs decodeURIComponent. Reversing that order corrupts any value containing a percent sign — a common source of bugs in hand-rolled decoders.
The tool also works in reverse: paste a raw form body (for example from a browser network tab) to decode it back into readable pairs.
For multi-value fields (for example a multi-select), the convention is to repeat the key: color=red&color=blue. There is no array syntax in the standard; server frameworks parse repeated keys into arrays themselves.
This encoding only covers the body or query string. File uploads require multipart/form-data instead (enctype="multipart/form-data" on the form element), which uses a different, boundary-delimited wire format.