What next?
Percent-encoding is one of several escaping schemes.
How to use this tool
- Paste your text or URL.
- Choose encode or decode.
- Copy the percent-encoded (or decoded) result.
What your result means
The encoded string is your text made safe to travel inside a URL. Every character that would otherwise be read as structure — a space, a slash, an ampersand, a question mark — has been replaced by a percent sign and the hexadecimal value of its bytes, so the receiving server reads it as data rather than as part of the address.
The critical judgement is scope. Encode the value, not the whole address: percent-encoding a complete URL escapes the colons and slashes that make it a URL at all, and the link stops working. If your decoded output looks like mojibake rather than readable text, the string was almost certainly encoded from a non-UTF-8 source and needs the original character set to recover it correctly.
Why this one is different
Every character the encoder touched is listed with what it became, so you can see whether the one you cared about was escaped — and just as importantly, that the rest were left alone. Decoding reads the percent sequences back the same way, and a malformed escape is named rather than silently passed through.
Why spaces become %20
URLs can only safely contain a limited set of characters. Anything outside that set — spaces, accents, &, ?, # — has to be "percent-encoded" into a % followed by its hex code, which is why a space turns into %20.
Get this wrong and links break or query parameters get misread. Encoding query values before you paste them into a URL is the fix.
Related tools
How percent-encoding works
URLs may only contain a limited set of ASCII characters. Anything outside that set — a space, an accent, an ampersand that is part of a value rather than a separator — is replaced by a percent sign followed by the two-digit hexadecimal value of each byte in its UTF-8 representation. A space becomes %20, an ampersand %26, and the é in "café" becomes %C3%A9 because it is two bytes in UTF-8.
Worked example
Encoding a search value containing an accent, a space and an ampersand:
Output caf%C3%A9%20%26%20bar
The é became two percent-escapes because it is two bytes in UTF-8. The ampersand became %26 so the server reads it as part of the value rather than as the start of the next parameter — leaving it unencoded would silently truncate the search term at "café".
Encoding a URL and encoding a value inside one are different jobs
JavaScript exposes both, and choosing wrongly is a routine source of broken links. encodeURI leaves the characters that give a URL its structure — the slashes, question mark, ampersands and colons — intact, so it is for encoding a whole URL that is already correctly assembled. encodeURIComponent escapes those characters too, which is what a single query-string value needs: a value containing a slash or an ampersand must not be allowed to look like structure.
Double-encoding is the failure that follows. Encoding an already-encoded string escapes the percent signs themselves, so %20 becomes %2520 and the receiving system sees a literal "%20" in the data. If a value passes through two systems, each should decode what it receives and encode what it sends, rather than encoding twice at the origin.
A related subtlety: form submissions use application/x-www-form-urlencoded, in which a space is a plus sign rather than %20. Both forms appear in real URLs, so a decoder needs to know which context produced the string. Percent-encoding is also not sanitisation — a correctly encoded value can still be hostile when it is finally used, so validate it on arrival.
Frequently asked questions
When should I encode a full URL versus a single parameter?＋
Encode individual parameter values, not the whole URL. Encoding a complete URL would escape the slashes, colons and question marks that give it structure. In JavaScript, encodeURIComponent is for values and encodeURI is for whole URLs.
Why do I sometimes see + instead of %20 for a space?＋
The application/x-www-form-urlencoded format used by HTML form submissions encodes a space as +, while RFC 3986 percent-encoding uses %20. Both are correct in their own context, which is why decoders often accept either.
Which characters never need encoding?＋
The unreserved set: A–Z, a–z, 0–9 and the four marks - . _ ~ . These always pass through unchanged. Everything else is either reserved (structural) or must be encoded.
What is the difference between encodeURI and encodeURIComponent?＋
encodeURI leaves the characters that structure a URL intact, so it is for whole URLs. encodeURIComponent escapes those too, which is what you want for a single query value that may contain slashes or ampersands.
Why does an ampersand in a parameter break my link?＋
Because it is read as the separator between parameters. Encoding it as %26 keeps it as part of the value instead of starting a new one.
Do I need to encode a URL twice?＋
Almost never, and doing so is a common bug: the percent sign itself gets encoded, so %20 becomes %2520. If a value passes through two systems, decode once at each stage rather than encoding twice at the start.
Further reading
Assumptions & limitations
The percent-encoding is exact. What to encode, and how far, is a judgement the tool cannot make:
- Encoding a whole URL and encoding a single parameter value are different operations with different reserved sets.
- Double-encoding is a common bug: the percent sign itself gets encoded, so %20 becomes %2520.
- Plus signs mean a space in form-encoded data but a literal plus elsewhere, so the two contexts cannot be treated alike.
- Encoding is not sanitisation. A safely encoded value can still be a hostile one when it reaches its destination.