Build an application/x-www-form-urlencoded body from key/value pairs. The exact format browsers use when submitting HTML forms via POST.
When an HTML <form> is submitted, the browser serializes the fields into a standardized payload so the server can read them back. There are two formats, and choosing the right one — and encoding it correctly — is what keeps accented text, special characters, and file uploads from arriving corrupted. This encoder produces the first format, application/x-www-form-urlencoded.
The single most common source of confusion is how a space is encoded, because the rule changes with where the space sits:
?): a space must be %20. A literal + here is an actual plus character, not a space — so /my+file and /my%20file are different paths.application/x-www-form-urlencoded): a space is serialized as +. This is the historical form-submission convention, and a compliant parser converts those plus signs back into spaces on the way in. %20 is also accepted here.So the same space is %20 in a path and + in a form body — both correct, in their own layer. Mixing them up is what turns a search for C++ into C , or leaves + signs littered through a decoded path.
URL-encoding is built for text. If you try to push a binary file — an image, a PDF — through application/x-www-form-urlencoded, every byte has to be percent-encoded into text, inflating the payload substantially and offering no clean way to carry multiple files. That’s why the HTML form spec uses a different media type for uploads.
multipart/form-data (defined in RFC 7578) solves this with a boundary: a unique delimiter string, declared in the Content-Type header, that separates the payload into independent parts. Each text field and each binary file gets its own part with its own headers, so binary data travels as-is — no percent-encoding, no size blow-up — alongside your text fields. The rule of thumb: plain text fields → url-encoded; any file upload → multipart.
| application/x-www-form-urlencoded | multipart/form-data | |
|---|---|---|
| Best for | Plain text fields | File uploads & binary data |
| Layout | One string: a=1&b=2 |
Separate parts split by a boundary |
| Space becomes | + (or %20) |
Sent literally within a part |
| Binary files | Inefficient — must be encoded to text | Carried directly, no encoding overhead |
| Defined by | WHATWG URL Standard | RFC 7578 |
Non-ASCII characters must be encoded as their UTF-8 bytes, or they arrive garbled (the classic é in place of é is a charset mismatch). This encoder handles that byte-level conversion for you. Encoding is about safe transport, though — it is not sanitization. Form data still has to be validated and escaped on the server before it’s rendered or queried, or it can enable cross-site scripting and injection; our input-hardening guide covers that side.
See also: How to send form data via a POST request — a step-by-step guide with runnable code.
+-for-space convention. url.spec.whatwg.org%20 (not +) is the space in a URL path. rfc-editor.org/rfc/rfc3986 §2.1Honest scope: application/x-www-form-urlencoded comes from the WHATWG URL Standard (and early HTML specs), while multipart/form-data is defined by RFC 7578 — they’re two separate standards for two jobs. This tool produces the url-encoded form; it doesn’t build multipart bodies, since those are assembled by the browser or HTTP client at upload time.
It formats key/value pairs into the application/x-www-form-urlencoded layout — the exact body an HTML form sends when submitted by POST. Enter your fields above and you get the encoded string ready to use.
The application/x-www-form-urlencoded convention (from the WHATWG URL Standard) uses + for a space, whereas RFC 3986 uses %20. Both mean a space in a query string; this encoder follows the form convention because that’s what receivers of form data expect.
URL-encoded packs all fields into one text string — ideal for plain text inputs. multipart/form-data splits each field into its own section and is required for file uploads and binary data. This tool produces the URL-encoded form.
Use URLSearchParams: new URLSearchParams({name:'a b'}).toString() gives name=a+b. It encodes each value once, so don’t also wrap values in encodeURIComponent or you’ll double-encode them.
urllib.parse.urlencode(data_dict) converts a dictionary into an encoded query string suitable for a POST body. It applies the form convention (spaces as +) by default.
Incoming form fields arrive in the $_POST superglobal, already decoded. For outgoing requests, http_build_query() serializes an array into an encoded body.
It can be corrupted or dropped in transit. Non-ASCII characters must be encoded as their UTF-8 bytes; this encoder does that for you, so accented text and other scripts survive the round trip intact.
Line breaks in a text area are normalized to a CRLF sequence and encoded as %0D%0A, per the form-encoding rules. This keeps multi-line values consistent across browsers and servers.
Each character is converted to its UTF-8 bytes and every byte is percent-encoded, so a single emoji becomes a chain like %F0%9F%91%A5. The encoder handles the byte-level conversion automatically.
Yes — run it through this encoder so its ?, &, and :// become safe encoded text rather than structural characters. That way the nested URL travels as a single value without breaking the surrounding data.
RFC 3986 recommends producers emit uppercase hex (%20, not %20 in lowercase digits), though decoders accept either since hex is case-insensitive. Consistent casing avoids duplicate-URL issues when the encoded value ends up in a link.
Unvalidated form data can enable cross-site scripting or SQL injection if it’s later rendered or queried unsafely. Encoding is about safe transport; you still need to validate and escape on the server — see our input-hardening guide.
Disconnect from the internet and encode something — it still works, because all processing happens locally in your browser tab. Your input is never uploaded.
Written and maintained by the urlencodedecode.com team. Every technical claim on this page is verified against primary sources — the RFCs (3986, 3629, 4648, 7578), the WHATWG URL Standard, and official vendor or language documentation — rather than second-hand summaries. When a source contradicts a common assumption, we follow the source and note the discrepancy. Corrections: contactus@urlencodedecode.com.