URL Encode & Decode
Encode text for a URL or decode one back into something readable, with the choice that actually matters made explicit: escaping the delimiters for a value, or leaving them alone for a whole URL. Malformed escape sequences are reported rather than silently mangled.
Encoding a value is not the same as encoding a URL.
Nearly everyone who arrives here is stuck on this one thing, and it is the source of the truncated-parameter bug that shows up in every codebase eventually.
encodeURIComponent — for a value
Escapes everything that is not safe, including the delimiters: & = ? / #. This is what you want for a single value going inside a query parameter, a path segment, or a fragment. If you are building a URL from parts, this is the function for the parts.
encodeURI — for a whole URL
Escapes unsafe characters but leaves the delimiters alone, because they are doing their job. This is what you want when you already have a complete URL and need to make it safe to transmit without destroying its structure. Running it on a value instead is the bug: the ampersand inside your value survives and splits the parameter.
The plus-sign question
HTML form submissions encode a space as a plus sign; percent-encoding uses %20. Both appear in real query strings and they are not equivalent outside one. Decoding a query string without accounting for plus signs leaves them as literal plus characters in your values, and decoding a path while converting plus signs corrupts anything containing one.
Double encoding
Encoding an already-encoded string turns %20 into %2520, because the percent sign itself gets escaped. It usually surfaces as visible %2520 in a link, or as a redirect that loses its destination. Decoding twice is equally damaging in the other direction: it corrupts any value that legitimately contained a percent sign.
Eight escapes worth recognising on sight.
Reading a URL is much easier once these are familiar, and most encoding bugs involve one of them.
- space
%20Not permitted in a URL at all. Encoded as %20 everywhere, or as a plus sign inside a query string submitted by an HTML form. The two are not interchangeable: a plus sign in a path means a literal plus. - &
%26Separates one query parameter from the next. A value containing an unencoded ampersand is read as the end of that parameter and the start of another, which is why a search for "R&D" silently becomes a search for "R" plus a parameter called D. - =
%3DSeparates a parameter name from its value. An unencoded equals sign inside a value usually survives by luck rather than by rule, and breaks the moment anything parses strictly. - ?
%3FBegins the query string. A second unencoded question mark is ambiguous, and different servers resolve it differently. - #
%23Begins the fragment. Everything after it is never sent to the server at all, so an unencoded hash in a value silently truncates the request. This is the one that produces bugs nobody can reproduce from the server logs. - /
%2FSeparates path segments. Encoding it matters when a value legitimately contains a slash, such as a date or a file path passed as a parameter. - +
%2BMeans a space inside a form-encoded query string, and a literal plus everywhere else. Phone numbers in international format are the usual casualty. - %
%25The escape character itself. It must be encoded, or the two characters after it are read as a hex code. This is why double-encoding produces %2520 and why decoding twice corrupts data containing a literal percent sign.
It is not security, and it never was.
Encoding exists so that characters can travel through a system that reserves some of them for its own purposes. That is the whole of it. It is not encryption, it conceals nothing, and anyone can reverse it instantly — including on this page.
It is also not a defence against injection. Encoding for a URL says nothing about whether a value is safe to put into a database query, an HTML page, or a shell command, each of which reserves a different set of characters. Encode for the context you are writing into, and validate the input separately from either.
A related trap: a token or identifier in a URL is in the browser history, the server logs, and the referrer header sent to the next site you visit. Encoding it changes none of that.
URL encoding questions.
What is URL encoding?
A way of representing characters that are not permitted in a URL, or that have a special meaning in one, as a percent sign followed by two hexadecimal digits. A space becomes %20, an ampersand becomes %26. It is also called percent encoding, and it is defined in RFC 3986.
What is the difference between encodeURI and encodeURIComponent?
Which characters they leave alone. encodeURIComponent escapes the URL delimiters — & = ? / # — and is what you want for a single value going inside a URL. encodeURI leaves those alone because they are structural, and is what you want for a complete URL you need to make safe without breaking. Using encodeURI on a value is the most common cause of a parameter truncating.
Why does my query parameter get cut off?
Almost always an unencoded ampersand or hash in the value. An ampersand is read as the start of the next parameter, so your value ends there. A hash is worse: everything after it is a fragment and is never sent to the server at all, so the parameter is silently truncated with nothing in the logs to show it.
Is a space %20 or a plus sign?
Both, in different places. Percent encoding uses %20 and is valid anywhere in a URL. HTML form submissions encode a space as a plus sign inside the query string only. In a path, a plus sign is a literal plus, so converting it to a space there corrupts the URL.
What is double encoding?
Encoding a string that was already encoded. The percent signs from the first pass get escaped in the second, so %20 becomes %2520. It usually shows up as visible %2520 in a link or a redirect that loses its target, and the fix is to find the step that is encoding twice rather than to decode the result.
Why did my decoded text come out wrong?
Either the input was double-encoded, in which case one decode leaves a layer of escapes behind, or the input contains a literal percent sign that was never an escape, in which case decoding corrupts it. The tool reports malformed escape sequences rather than silently mangling them.
Does URL encoding make data secure?
No, and this is worth being clear about. Encoding is about transmitting characters safely through a system that reserves some of them. It is not encryption, it hides nothing, and anyone can decode it instantly. It is also not a defence against injection: encode for the context you are writing into, and validate separately.
Which characters need encoding?
Anything outside the unreserved set — letters, digits, hyphen, full stop, underscore and tilde — should be encoded when it appears inside a value. The reserved characters & = ? / # : @ have structural meanings, so they must be encoded when they are part of a value rather than part of the URL's structure.
How do I encode a whole list of URLs?
Paste them one per line and leave line by line on. Each line is encoded separately, so you get a list back rather than one enormous encoded string with the line breaks escaped into it.
Does it handle accented and non-Latin characters?
Yes. Those are encoded as their UTF-8 bytes, so a single accented letter typically becomes two percent-escapes and a CJK character becomes three. That is correct and is what every modern system expects.
Is my data uploaded anywhere?
No. Encoding and decoding happen in your browser using the standard functions. Nothing is transmitted or stored, which matters since URLs frequently contain tokens and identifiers.