Should a space be %20 or a plus sign?

It depends on where it lands. Inside a URL path or query, use %20. Inside an application/x-www-form-urlencoded body, a space is a plus sign. Confusing the two is the most common reason Chinese parameters turn into garbage.

What is the difference between encodeURIComponent and encodeURI?

The first escapes slashes, question marks, hashes and ampersands too, so it belongs on a single parameter value. The second leaves structural characters intact, so it belongs on a whole URL. Use the wrong one and you get either a broken link or text that was never escaped.

Decoding once did not restore the original. Why?

The input was probably encoded twice. You will still see fragments starting with %25 inside. The tool flags suspected double encoding rather than guessing; decoding such input twice does restore it, and normal input is never altered on the way through.

My Chinese parameter came back as mojibake. Did the encoding fail?

Percent-encoding carries bytes, not characters, so garbled output almost always means the two ends disagreed about which character encoding produced those bytes. The sender may have written the form as GBK or Big5 while the receiver decoded the escapes as UTF-8, or the page declared one charset and was saved in another. RFC 3986 asks for UTF-8, so check the declared and actual charset of both ends before suspecting the escaping itself. The other frequent cause is the plus sign: in a form body it means a space, in a query string it may be a literal plus, and guessing wrongly turns every space or every plus into the wrong character.

Should I encode the whole URL before putting it somewhere?

No. The unit of encoding is a component value, not the address. Running a complete URL through encodeURIComponent escapes the scheme separator, the path slashes and the query ampersands, and the result will not open; running it through encodeURI leaves ampersands and equals signs intact, which is good for structure but means a value containing them can silently rewrite your parameter list. Build the address from parts, encode each part once, and let URLSearchParams handle query pairs. If you are pasting a URL into a context with its own escaping rules, such as HTML, a shell command or a JSON string, that layer needs its own quoting, and percent-encoding is not a substitute for it.

URL Encode & Decode

Percent-encode and decode text or URLs. Choose encodeURIComponent or encodeURI scope, with form plus-sign and double-encoding handling.

Encoding scope

Waiting for input

How to use

Paste the text or the whole URL you need to fix
Pick the scope: encode a single query value, or keep URL structure and escape only what is illegal
Check whether the result is encoded or decoded, and run the opposite direction if needed
Copy it back into your code or the address bar

About this tool

A URL can only travel safely through a small set of characters, so everything else has to be spelled as a percent sign followed by two hexadecimal digits, each pair standing for one byte. That is percent-encoding, defined in RFC 3986. The alphabet it leaves alone is short and worth memorising: the letters A to Z and a to z, the digits, and the four marks minus, underscore, period and asterisk. Everything else is either a reserved character that carries structure, or data that must be escaped. Non-ASCII text adds a second layer: what gets escaped is bytes, not characters, and RFC 3986 says those bytes should be produced by UTF-8, which is why a Chinese character normally becomes three percent escapes such as %E4 %B8 %AD. A converter that used the code point instead, or a legacy single-byte code page, would emit something else entirely, and a browser cannot tell you which one you got.

The practical difficulty is not the escaping rule but the question of where to stop, and that is what most broken links come down to. encodeURIComponent escapes every character outside the safe set, including slash, question mark, hash, ampersand and equals, which is exactly right for the value of one query parameter and exactly wrong for a whole URL, because it destroys the structure that makes the URL a URL. encodeURI does the opposite: it leaves reserved characters intact so the structure survives, which means it will happily leave an ampersand inside your value unescaped, and that ampersand will then be read as a parameter boundary. Form bodies add a third rule, because application/x-www-form-urlencoded spells a space as a plus sign while the general syntax uses %20, so a value containing a literal plus has to be written as %2B or it will come back as a space. This tool exposes those three scopes explicitly rather than picking one for you, and if you can build the query with URLSearchParams in your own code, do that: it applies the form rules per pair and removes the whole class of mistake.

Position changes what is dangerous. In a query value the characters that truncate or split it are hash, ampersand and equals, and a bare plus may be reinterpreted; in a path segment slash is a boundary, so a filename containing slash must be escaped, while sub-delimiters such as comma, semicolon and dollar are usually tolerated; in the fragment the same rules apply as in the query, and browsers additionally stop reading the URL at the first hash, so a second unescaped one silently discards the rest. Hosts are their own story: internationalised domain names are not percent-encoded at all but converted to punycode, and an IPv6 literal needs square brackets to be parseable at all. The general rule, and the one that prevents most accidents, is that you encode each component value separately and never run a complete URL through a whole-string encoder.

Decoding is where silent corruption shows up, so this tool is strict rather than clever. A malformed escape, a percent sign followed by something that is not two hex digits, makes decodeURIComponent throw; the legacy escape form %uXXXX is not part of the standard and will not decode; and a lone plus in already-encoded text is ambiguous unless you know whether it came from a form body. Double encoding is the other common failure, when an already-encoded string is passed through the encoder again so that %20 becomes %2520: one decode then leaves you with visible percent escapes rather than the original text, which looks like a bug in the decoder but is not. This tool detects that shape and says so instead of quietly returning half-decoded text. For storage, the rule is simple: keep the decoded value in your database or configuration, encode only at the moment the URL is written, and never encode something that may already be encoded, because that is how a search engine ends up with a query string full of literal percent signs.

Frequently asked questions

Should a space be %20 or a plus sign?: It depends on where it lands. Inside a URL path or query, use %20. Inside an application/x-www-form-urlencoded body, a space is a plus sign. Confusing the two is the most common reason Chinese parameters turn into garbage.
What is the difference between encodeURIComponent and encodeURI?: The first escapes slashes, question marks, hashes and ampersands too, so it belongs on a single parameter value. The second leaves structural characters intact, so it belongs on a whole URL. Use the wrong one and you get either a broken link or text that was never escaped.
Decoding once did not restore the original. Why?: The input was probably encoded twice. You will still see fragments starting with %25 inside. The tool flags suspected double encoding rather than guessing; decoding such input twice does restore it, and normal input is never altered on the way through.
My Chinese parameter came back as mojibake. Did the encoding fail?: Percent-encoding carries bytes, not characters, so garbled output almost always means the two ends disagreed about which character encoding produced those bytes. The sender may have written the form as GBK or Big5 while the receiver decoded the escapes as UTF-8, or the page declared one charset and was saved in another. RFC 3986 asks for UTF-8, so check the declared and actual charset of both ends before suspecting the escaping itself. The other frequent cause is the plus sign: in a form body it means a space, in a query string it may be a literal plus, and guessing wrongly turns every space or every plus into the wrong character.
Should I encode the whole URL before putting it somewhere?: No. The unit of encoding is a component value, not the address. Running a complete URL through encodeURIComponent escapes the scheme separator, the path slashes and the query ampersands, and the result will not open; running it through encodeURI leaves ampersands and equals signs intact, which is good for structure but means a value containing them can silently rewrite your parameter list. Build the address from parts, encode each part once, and let URLSearchParams handle query pairs. If you are pasting a URL into a context with its own escaping rules, such as HTML, a shell command or a JSON string, that layer needs its own quoting, and percent-encoding is not a substitute for it.

Related tools

Back to all Encoding Conversion tools