FAQ
Should a space be %20 or +?
This tool uses %20, the RFC 3986 form. The plus sign belongs to form encoding and the two are not interchangeable.
Why does Chinese turn into %E4...?
Each character is split into UTF-8 bytes and every byte is written as %XX. Decoding restores it.
Why is decoded text still garbled?
Usually the source was not UTF-8, for example GBK. This tool decodes as UTF-8, so such input shows garbled characters rather than an error.
About this tool
The rule is exactly the browser's encodeURIComponent: letters, digits and - _ . ! ~ * ' ( ) pass through untouched, everything else is split into UTF-8 bytes first and each byte is written as %XX. One Chinese character (U+4E2D) is therefore three groups (%E4%B8%AD) and one emoji is four (%F0%9F%98%80) — a repeating pattern of three groups means CJK text.
A space becomes %20, never +, and decoding does not turn + back into a space — a+b copied out of a query string decodes to a+b. The two conventions are a historical split: +-for-space belongs to form encoding (application/x-www-form-urlencoded). To decode form data, replace + with a space yourself first.
It cannot encode a whole URL: the : and / in https://a.com/p would become %3A%2F%2F and the link breaks. Split the work instead — keep scheme, host and path as they are and encode only the query keys and values. This tool is a pure percent-encoder and does not do that splitting for you.
Malformed input (%zz, a trailing lone %, a truncated multi-byte sequence) reports a failure rather than silently swallowing it, which is deliberate — garbled output is harder to diagnose than an error. Note that %XX sequences copied from a GBK page are decoded as UTF-8 here and come out garbled rather than failing; confirm the original encoding for such content.