= Form URL encoding
<Form URL encoding> is the `application/x-www-form-urlencoded` format for serializing an ordered list of name/value pairs. It is used by <URLSearchParams> and common form-processing conventions. Repeated names are allowed; the data model need not be a dictionary with one value per name.<URL Standard by WHATWG>[§5, format; §6.2, URLSearchParams]{ref}
For example, the three pairs `("q", "a b+c")`, `("tag", "x")` and `("tag", "y")` serialize as `q=a+b%2Bc&tag=x&tag=y`.
Here the space becomes `+`, while the literal plus in the value becomes `%2B`. Parsing the result recovers `a b+c` and both tag values. Replacing every plus with a space before deciding which encoding convention applies would misread data from other <URL> contexts.
Structural separators must also be distinguished from value data. The encoded pair `q=a%26b` has one value, `a&b`, rather than two pairs. The form parser first recognizes pair boundaries and then decodes their component data. <Percent-encoding> inside a component is consequently not an instruction to reinterpret the resulting characters as new separators.<URL Standard by WHATWG>[§5.1, split, plus replacement and percent-decoding steps]{ref}
For modern serialization, text is encoded as <UTF-8> bytes before the relevant bytes are percent-encoded. The name/value pair `("word", "café")` therefore produces `word=caf%C3%A9`. This connects a text character with its byte representation rather than assigning one arbitrary percent code to the whole character.<URL Standard by WHATWG>[§5.2, serialization with UTF-8 and the form percent-encode set]{ref}
A <query string> can use this format, but generic URL syntax does not require every query to be interpreted this way. State the parser and encoding when comparing an original spelling with its recovered list of values.
Back to article page
