URL Encoder and Decoder

Percent-encoding exists because a URL is made of delimiters. A slash separates path segments, a question mark starts the query, an ampersand separates one parameter from the next — and the moment your data contains one of those characters, the reader has no way to tell your slash from the structure's slash. The fix is to write the offending byte as a percent sign followed by its two hexadecimal digits. What trips people up is that the answer depends on which of those two things you are holding: one value, or a whole address. This page makes you say which, and shows the difference side by side.

How it is calculated

pct-encoded = "%" HEXDIG HEXDIG

One triplet per octet, not per character — so a character that takes four bytes in UTF-8 becomes four triplets. Uppercase and lowercase hexadecimal digits mean the same thing, and two URLs that differ only in that case are equivalent, but the specification asks producers to write them in uppercase, which is what this tool does.

Source: RFC 3986 section 2.1 — percent-encoding, pct-encoded = "%" HEXDIG HEXDIG, and the note that producers should use uppercase digits

Questions people ask

When do I encode a component and when the whole address?

Encode a component when the text is going to sit inside a URL as data — a search term, a filename, a redirect target. Every delimiter in it must be escaped, or it will be read as structure. Encode a whole address when you already have a URL and only want the characters that are illegal anywhere to be fixed, typically spaces and non-Latin letters; the slashes and question marks stay, because they are the address.

Why does the component scope escape more than encodeURIComponent does?

Because JavaScript's function predates the current specification and leaves "!", "'", "(", ")", "*" and "~" alone, even though the first five of those are listed as sub-delimiters and can be read as structure by a scheme that uses them. Escaping them is never wrong, and it is occasionally the difference between a working link and a broken one.

Why is a space sometimes "+" and sometimes "%20"?

The plus is a rule of one specific format, application/x-www-form-urlencoded, which browsers use when they submit a form. Everywhere else in a URL a space is "%20", and a literal plus is "%2B". Decoding with the wrong assumption turns every plus in your data into a space, which is why this tool asks.

What happens if I encode something twice?

The percent sign itself gets encoded, so "%20" becomes "%2520" and the reader ends up with the literal text "%20" instead of a space. This is the most common percent-encoding bug there is. Decode first if you are not sure what state your text is in.

Does it handle characters outside ASCII?

Yes. The text is converted to UTF-8 first and each octet becomes its own triplet, so an accented letter is usually two triplets and an emoji four. Decoding reverses that and refuses input whose octets do not spell valid UTF-8, rather than handing back replacement characters.

Related tools