Written by Alex Chen · Reviewed by Jane Smith · July 23, 2026
Percent-encode text for safe use in URLs, or decode percent-encoded URLs back to human-readable text. No data is transmitted to any external server.
The tool runs every character of your input through JavaScript's built-in encodeURIComponent() when you choose Encode, and through decodeURIComponent() when you choose Decode. The key detail most people miss is that encodeURIComponent() is deliberately lazy: it leaves the letters A through Z, the digits 0 through 9, and the nine punctuation marks - _ . ! ~ * ' ( ) completely untouched, and percent-encodes everything else. A space becomes %20, never a plus sign — the plus is reserved for HTML form-style encoding, which this tool does not use. Even characters that look safe in a URL, like /, ?, &, =, and #, get the same treatment, because any of them can be mistaken for URL structure by a server.
JavaScript ships two encoders with similar names and very different jobs. encodeURI() assumes it is receiving a complete web address and deliberately keeps the reserved characters like /, ?, and & intact, so a full URL stays readable. encodeURIComponent() assumes it is receiving a single piece of data that must be buried inside a URL, so it encodes even those reserved characters. This tool uses the second one, which is the correct choice for query string values. A search term like 3/4 & 5 would break a URL if left raw, but encoded it becomes 3%2F4%20%26%205, a single value the server can decode back to the original string.
Take the string hello world & more and click Encode. Each space becomes %20, and the ampersand, which would otherwise be read as a parameter separator, becomes %26. The result is hello%20world%20%26%20more. Paste that into a query string like ?q=hello%20world%20%26%20more and a server sees one parameter whose value is hello world & more, not three separate parameters. Decode the output and you are back to the original phrase. Now try something with an apostrophe, such as it's: it encodes to it's — unchanged — because the apostrophe sits in the untouched set. That asymmetry surprises people, but it is correct per the RFC that defines URI components.
Decoding is not always possible. Percent encoding works in pairs: a percent sign must be followed by exactly two hexadecimal digits. If you feed the decoder a string that violates that rule, such as %ZZ or a bare % at the end of the input, decodeURIComponent() throws a URIError, and the tool catches it and shows the message Error: URI malformed in the output box instead of guessing. This is a deliberate behavior: garbage in produces a visible error, never a silent wrong result. The encode side, by contrast, can always succeed, because any character can be turned into a valid escape sequence.
The classic mistake with this tool is encoding data that has already been encoded. A literal percent sign in your input becomes %25, so if a URL already contains %2F (an encoded slash) and you run the whole thing through the encoder again, the % of the %2F becomes %25 and you get %252F. Decode once and you recover %2F; decode twice and you get the slash. The same applies to the ampersand: & in already-encoded content will not survive a second pass intact. A practical tell is length — if your encoded output has more percent signs than you expected, check whether the input was already escaped. Unicode is handled as UTF-8 bytes, so an emoji like 😀 becomes the four escape sequences %F0%9F%98%80, which is why a single character can expand to many characters of output.
This tool uses encodeURIComponent(), which is the standard for query strings in JavaScript and most server-side frameworks. The plus sign is a legacy convention from the original HTML form encoding spec and only applies when a form is submitted with application/x-www-form-urlencoded. Most APIs expect %20.
The apostrophe, along with - _ . ! ~ * ( ), is in the "unreserved" set of characters defined by RFC 3986, so it never needs encoding in a URI. If you encode it anyway, most servers decode it back without complaint, but this tool follows the spec and leaves it alone.
Only the parts that carry user data. The scheme and host should stay readable, while query parameter values should be passed through encodeURIComponent(). Encoding an entire URL with this tool turns the : and / into escape sequences, which makes the address invalid when a browser tries to visit it.
It means the decoder found a percent sign that was not followed by two valid hexadecimal digits, or a UTF-8 sequence that does not decode to a legal character. Check for stray percent signs in the input, often left over from copying an already-encoded URL.
No. Each encoding solves a different problem: percent encoding makes data safe for URLs, HTML entities make text safe inside markup, and Base64 turns binary data into ASCII text. They are not interchangeable, and decoding with the wrong one produces garbage.
Use it when you are assembling a URL by hand — building a search link, an API call with parameters, or a redirect that carries data — and you need to see exactly how the browser will interpret each character. Skip it when a framework already does the escaping for you: most fetch libraries, URL builders, and server-side templates encode query values automatically, and double-encoding will quietly corrupt your data. If you are debugging why a server receives garbled parameters, this tool lets you compare the raw text against its encoded form side by side, which is the fastest way to spot a missing escape.