URL-Encoded Form Data MIME Type

What does application/x-www-form-urlencoded mean?

application/x-www-form-urlencoded identifies a sequence of name-value pairs encoded for an HTML form submission. A familiar payload looks like this:

name=Ada+Lovelace&language=Analytical+Engine&published=yes

Each name is separated from its value by =, and pairs are joined with &. Characters that cannot appear literally are represented with percent-encoded bytes. A space is the important exception: this format normally serializes it as +.¹

Despite the word "URL" in its name, the format is also used as an HTTP request body. A form submitted with GET puts the serialized pairs in the URL's query component. A form submitted with POST sends the same style of data in the message body and labels it Content-Type: application/x-www-form-urlencoded.²

How URL-encoded form data works

The current algorithm is defined by the WHATWG URL Standard. Conceptually, a serializer starts with an ordered list of name-value tuples, encodes each name and value, joins the two with =, and joins tuples with &. It returns an ASCII string.¹

For example, these values:

produce:

q=tea+and+cake&symbol=A%26B&price=%C2%A35

The parser reverses that process. It splits the input at &, splits each part at its first =, changes + to a space, percent-decodes the bytes, and decodes the result as UTF-8. Repeated names are valid and remain separate entries, so color=red&color=blue represents two tuples rather than requiring one to overwrite the other.¹

Why + and %20 are not interchangeable everywhere

Generic URL percent-encoding and form URL encoding overlap, but they are not identical. In this media type, + represents a space, and a literal plus sign is encoded as %2B. The payload:

calculation=1%2B1+%3D+2

decodes to calculation = 1+1 = 2.

This distinction explains a common bug. JavaScript's URLSearchParams follows the application/x-www-form-urlencoded rules when it serializes a query string, including the space-to-plus conversion.⁴ A generic URI component encoder can produce a different spelling. Use one form-aware encoder for complete names and values instead of combining manual replacement with a second encoding pass.

History and registration

HTML 2.0 documented the form-urlencoded media type in RFC 1866 in November 1995. It specified the core conventions still recognizable today: spaces represented by +, other characters escaped with %HH, names joined to values with =, and fields separated by &.⁵

The format predates its formal IANA registration. Anne van Kesteren registered application/x-www-form-urlencoded on May 14, 2014, with WHATWG as the author and change controller. The registration was updated in 2020 and points to the WHATWG URL Standard for the generation and parsing rules.³

The x- prefix is therefore historical, not evidence that the media type is currently unregistered. IANA lists the exact spelling in the application media-type registry, with common intended usage and no parameters.³

Browser and application support

Current Chrome, Edge, Firefox, Opera, and Safari all submit ordinary HTML forms in this format. It is the missing-value and invalid-value default for a form's enctype, so this explicit attribute and an omitted attribute have the same effect for a typical form:²

<form method="post" enctype="application/x-www-form-urlencoded">
  <input name="display-name">
  <button>Save</button>
</form>

JavaScript can create the same representation with URLSearchParams:

const body = new URLSearchParams()
body.append('display-name', 'Ada Lovelace')
body.append('topic', 'mathematics & computing')

await fetch('/profile', { method: 'POST', body })

URLSearchParams preserves the order of its entries and supports more than one value for the same name.⁴

curl supports the format too. Its --data option sends this content type by default, while --data-urlencode performs URL encoding for the supplied value.⁶

curl --data-urlencode 'display-name=Ada Lovelace' \
  --data-urlencode 'topic=mathematics & computing' \
  https://example.com/profile

When should you use another media type?

URL-encoded form data is a good fit for short, flat fields accepted by an HTML form or an established HTTP API. Other representations fit different data models better.

The HTML Standard converts a form's entry list to string name-value pairs before URL-encoding it. A file entry becomes a filename rather than transferring the file's bytes. Use multipart/form-data when a form needs to upload a file.² MDN likewise identifies multipart as the form encoding that allows file inputs to send file data.⁷

JSON is usually clearer when the receiver needs nested objects or typed values. Form URL encoding has strings and repeated tuples, but no built-in distinction among a number, boolean, null value, array, or nested object. Applications that place brackets in names such as items[]=one are using a framework convention, not a nesting rule defined by this media type.

Support in Poly

Poly recognizes the exact application/x-www-form-urlencoded identifier and preserves a payload already labeled with it. The repository's canonical MIME table gives it no extension and classifies it as an unknown media category. That has practical limits:

• Poly does not infer the type from a filename or payload signature.
• The indexer does not parse fields or add decoded names and values to full-text search.
• There is no in-app text editor or specialized form-data preview.
• The Poly agent and poly file read cannot read the payload's contents.

The file can still be stored, synced, shared, versioned, downloaded, and found by filename and ordinary properties. If readable and searchable content matters, decode the payload into a text or JSON file and keep that derived file alongside the original request capture.

Converting to JSON

Conversion starts by parsing the payload into an ordered list of tuples. Do not convert directly to a simple object unless you have decided what repeated names mean. For this input:

tag=history&tag=computing&published=true

a loss-aware JSON representation could be:

{
  "tag": ["history", "computing"],
  "published": "true"
}

Notice that "true" remains a string. The source format carries no boolean type. A schema or application contract must decide whether to coerce it.

In browser JavaScript, URLSearchParams.getAll() retrieves every value for a repeated name.⁴ On a server, use the framework's form parser rather than splitting the raw body by hand, and configure request-size and field-count limits appropriate to the endpoint.

Security and privacy considerations

The encoding provides no encryption, authentication, integrity protection, or validation. HTTPS protects an HTTP exchange in transit, but the server must still validate every decoded field. The IANA registration specifically warns that the security concerns of HTML forms apply and that client-side validation must not be treated as a security boundary.³

Keep secrets out of a GET form's query string. Query data becomes part of the URL and can be copied, bookmarked, logged, or retained in browser history. For sensitive data, use an appropriate request method over HTTPS, avoid unnecessary logging, and apply the same authorization and cross-site request protections used for any state-changing form endpoint.

Parsers also need explicit rules for duplicate field names, blank values, malformed percent escapes, and character decoding. Preserve tuple order and duplicates until the receiving application's schema says how to interpret them. That avoids silently changing meaning during conversion.

Is application/x-www-form-urlencoded the same as a URL query string?

It uses the same name-value serialization commonly found in URL query components, but the media type and the URL are different things. A POST body can carry the format without placing the data in the URL. Conversely, not every query string necessarily follows HTML form conventions.

Treat the Content-Type header and the surrounding protocol as the source of meaning. Do not decide that arbitrary text is form data merely because it contains = and &; IANA explicitly says there is no reliable byte-level recognition mechanism.³