URL Decoder / Encoder

%E4%B8%AD%E6%96%87 and other percent-encoded strings can be turned back into readable text here; it works the other way round too, encoding text, spaces and special characters into a form that is safe to put in a URL. Both UTF-8 and GBK are supported, a plus sign standing in for a space is recognised, and pasting a whole link additionally breaks out and decodes every query parameter. All of it runs locally in your browser; nothing is uploaded.
Encoded URL or parameter
Character set
Notes:
1. If what you paste contains %XX the page switches to decoding; if it does not, it switches to encoding. Once you click a mode button yourself, it stops guessing.
2. A malformed % sequence does not fail the whole string — those few characters are left as they are and everything else still decodes.
3. Question marks or boxes in the output usually mean the original site used GBK — switch to GBK and try again.
4. Paste a complete link and the scheme, host, path and each query parameter are listed out separately below.
5. URL encoding is not encryption — anyone can reverse it, so do not use it to hide parameters.

About URL encoding and decoding

What is URL encoding, and why does text turn into %E4%B8%AD?

The URL specification (RFC 3986) only permits ASCII letters, digits and a handful of symbols. Non-Latin characters, spaces and quotation marks are not on the list. To put them in a link they first have to be turned into bytes using some character set, and then each byte written as a percent sign followed by two hexadecimal digits — that is percent-encoding, also called URL encoding. The character 中 is three bytes in UTF-8, E4 B8 AD, which is written out as %E4%B8%AD. So a run of %E4%B8... is neither mojibake nor encryption, just another way of writing the same text — and groups of three %XX are a good sign it is UTF-8-encoded CJK.

encodeURIComponent or encodeURI — which one?

This is the single easiest thing to get wrong in code. encodeURIComponent also encodes the : / ? # & = structural characters, which makes it right for a single parameter value; encodeURI leaves them alone, which makes it right for a link you have already assembled. Getting it wrong has very concrete consequences: hand a whole URL to encodeURIComponent, https:// turns into https%3A%2F%2F, breaking the link outright. Go the other way and use encodeURI on a parameter value that itself contains an & — a search term like "A&B", say — and that & survives untouched, so the server reads it as a separator and your one parameter arrives as two. The encoder above offers both; the parameter-value form is the default.

URL encoding is not encryption

URL encoding, like Base64, is an encoding, not encryption: the rules are fully public, there is no key, and anyone who has the string can reverse it in one step — this page does exactly that. Its purpose is to let special characters travel safely through a URL, and it provides no confidentiality at all. Percent-encoding an order number, a phone number or an internal ID before putting it in a link therefore protects nothing: what sits in the address bar, the server logs and the Referer header is still plain text. For something genuinely irreversible see SHA-256; for sensitive parameters, use POST over HTTPS. Incidentally, "URL decryption" is not a real thing — the correct word is decoding.

Three traps: the + sign, %20, and mojibake

Spaces have two spellings. Form submissions use application/x-www-form-urlencoded encodes a space as +, while paths and modern APIs generally use %20. The awkward part is that JavaScript's decodeURIComponent does not recognise + at all and leaves a literal plus sign behind — hence the toggle above, which reads it as a space by default. Conversely, if your content genuinely contains a plus sign (1+1), encoding turns it into %2B, and that is correct.

The character set is the second trap. UTF-8 is the default everywhere now, but plenty of older sites and systems use GBK, where 中 is two bytes, %D6%D0. Decode GBK-encoded content as UTF-8 and you get question marks or boxes. The decode side of this page lets you switch to GBK; the encode side is UTF-8 only, because that is all the browser can natively produce.

The function names, language by language. PHP's urlencode turns a space into +, rawurlencode encodes it as %20, and the matching decoders are urldecode / rawurldecode; Java's URLEncoder.encode(s, "UTF-8") follows the form-submission rules, so also +; Python uses urllib.parse.quote / unquote, where only quote_plus produces +; and JavaScript has just encodeURIComponent / decodeURIComponent, which always emits %20. When the front end and the back end disagree, this plus sign is nearly always the reason.

FAQ

Why did the text in my link turn into %E4%B8%AD?

That is URL-encoded text, not mojibake. The URL specification only allows ASCII letters, digits and a few symbols, so anything else is first turned into bytes using UTF-8 and each byte written as a single %XX. A CJK character normally takes three %XX. Paste the whole thing above and hit Decode to get it back. It works the other way too: when your address bar shows a link with readable non-ASCII text in it, the browser is displaying the encoded form for you — copy it out and you usually get %XX.

I decoded it and still got mojibake or a row of question marks. Now what?

Switch to GBK and decode again. UTF-8 is the default here, but a fair number of older sites and systems use GBK: the same character 中 is %E4%B8%AD in UTF-8 and %D6%D0 in GBK, and the wrong character set inevitably produces question marks or boxes. A quick rule of thumb: %XX in groups of three is usually UTF-8; groups of two whose first byte falls between %A1–%FE are usually GBK.

What is the difference between encodeURIComponent and encodeURI?

The first encodes : / ? # & = as well, so it is for a single parameter value; the second preserves those structural characters, so it is for a whole link. When you are assembling a URL you should almost always use encodeURIComponent on each parameter value and then join the ? and & together yourself. Using encodeURI on a complete URL only fits one situation: the link is already assembled and you simply want the non-ASCII characters and spaces in it made legal.

Is + a space or a plus sign?

It depends on the context, and this is where mistakes happen most. Form submissions (application/x-www-form-urlencoded) encode a space as +, so a + in a query string is usually a space, whereas one in the path or in a modern API is usually + a literal plus. JavaScript's decodeURIComponent does not perform the conversion at all. This page reads + as a space by default; if your content genuinely contains a plus sign ( C++), clear that checkbox before decoding.

What causes "URI malformed" or a decoding error?

It means the string contains an invalid percent sequence — a % not followed by two hexadecimal digits, or bytes that do not add up to valid UTF-8. Usually a character was lost while copying, or the content was encoded twice (%25E4 and the like, where %25 is % itself, so one more pass gets you the real text). This page will not fail the whole string over it: the invalid fragment is left as-is while everything else decodes normally, so you can see exactly which part is broken.

Does URL encoding protect the parameters in a link?

No — it has nothing to do with encryption. The rules are public and anyone can reverse them in one step, so a phone number or an order ID is still sitting in plain text in the address bar, the browser history, the server logs and the Referer header after encoding. To actually protect a sensitive parameter, submit it with POST over HTTPS, check authorisation on the server, or replace it with an irreversible hash. And "URL decryption" is simply the wrong term; the right one is decoding.

Do the links I paste get uploaded?

No. Encoding and decoding use the browser's built-in encodeURIComponent / TextDecoder, computed on your device and displayed straight away; not a byte leaves the browser. Once the page has loaded you can disconnect from the network and the tool keeps working — that is the most direct way to verify it. Links carrying tokens or order IDs are safe to paste. See the Privacy Policy.

What other developer tools are there?

Plenty. JSON Format expands an API response into a readable tree, Base64 encoder / decoder covers the other encoding you meet constantly, Timestamp Converter turns the 10- and 13-digit numbers in your logs into readable times, and MD5 and SHA-256 compute checksum hashes. All of them run locally as well, with nothing uploaded.

Related tools

JSON FormatBase64 DecodeTimestamp ConverterMD5 HashSHA-256 HashRandom Password GeneratorQR Code Generator