URLSearchParams vs encodeURIComponent: Form vs Percent-Encoding
URLSearchParams and encodeURIComponent encode text differently. URLSearchParams uses + for spaces (application/x-www-form-urlencoded), while encodeURIComponent uses %20 (RFC 3986). Choose URLSearchParams for HTML form-style data and encodeURIComponent for general URL encoding. See the URL encoder for encodeURIComponent and the URLSearchParams tool for form encoding.
A space in a query is not one encoding. application/x-www-form-urlencoded writes +. RFC 3986 percent-encoding writes %20. This page names those outputs on the live URLSearchParams encoder and URL encoder. It is not new URL() and not a form POST client.
Two serializers, same ASCII query
+ versus %20
Encode on /url-search-params/ runs new URLSearchParams(input).toString(). A space becomes +. The percent-encode set is every code point except ASCII alphanumeric, *, -, ., and _ — so q=~ is q=%7E and q=* stays q=*. Encode URI on /url-encoder/ runs encodeURI and leaves reserved characters such as :/?#&=+ intact. Encode component runs encodeURIComponent. Both emit %20 for a space.
The same query is not interchangeable
Form-encoding q=hello world&category=news writes q=hello+world&category=news on /url-search-params/. encodeURI of that same query is q=hello%20world&category=news. encodeURIComponent of that same string is q%3Dhello%20world%26category%3Dnews because = and & are reserved. A literal plus is reserved for encodeURI: hello+world stays hello+world; Encode component writes hello%2Bworld. Decode on /url-search-params/ treats + as a space. decodeURI and decodeURIComponent leave + as +. The constructor strips one leading ? and rejects a string that starts with http:// or https://. Parse a full URL on /url-parser/.
Encode does not normalize first
NFC é and NFD e + U+0301 are different outputs
Encode turns UTF-8 bytes into form-urlencoded or percent-encoded characters and never calls String.prototype.normalize. Canonically equivalent e + U+0301 and é (U+00E9) are different UTF-8 sequences (65 CC 81 vs C3 A9). URLSearchParams output of NFC é is q=%C3%A9. URLSearchParams output of NFD é is q=e%CC%81. The same UTF-8 bytes on /url-encoder/ are %C3%A9 and e%CC%81. Decode of q=%C3%A9 or %C3%A9 writes NFC é. Try it with the ASCII query or search URL. UAX #15 output e + U+0301 → é (U+00E9) as normalized.txt lives on /unicode-normalize/.
Not a URL parser or a form POST
Query only versus a full URL
/url-search-params/ rejects a string that starts with http:// or https://. Paste the query (optional leading ?). WHATWG new URL() outputs live on /url-parser/. Parsed query strings there keep spaces as %20, not the form-urlencoded + that URLSearchParams writes. Neither encoder posts a form, fetches a host, or restores a typed image or PDF. Download on /url-search-params/ is encoded.txt or decoded.txt as text/plain.
Encode the same query with either serializer
Form-urlencoded + or RFC 3986 %20 in the browser. Nothing is uploaded.
FAQ
- What is the difference between URLSearchParams and encodeURIComponent?
- encodeURIComponent encodes a single value. URLSearchParams builds and parses complete query strings.
- Which should I use?
- Use URLSearchParams for building query strings. Use encodeURIComponent for encoding individual values.
- How do spaces encode?
- encodeURIComponent uses %20. URLSearchParams uses + (application/x-www-form-urlencoded).
- Does this tool upload my data?
- No. All encoding runs in your browser using JavaScript. Nothing is sent to a server.