URL Encoder and Decoder

How to use the URL encoder and decoder

Paste on the left and the result updates as you type. While encoding, the panel lists every distinct character that changed and the percent triplet it became. While decoding, it shows the decoded text and, when the input looks like a query string, the individual key and value pairs.

The mode switch is the part most tools get wrong. Component encoding escapes the separators, because inside a single value an ampersand or an equals sign would end that value early and silently create a new parameter. Full URL encoding leaves those same characters alone, because in a whole address they are the structure.

Everything outside the unreserved set becomes one triplet per UTF-8 byte, which is why non-Latin text grows so fast. A Latin letter with an accent is two bytes and six characters. An Arabic letter is two bytes. An emoji is four bytes and twelve characters, which is how a short link full of emoji turns into a very long one.

The plus sign is the classic bug. In plain percent-decoding a plus is a literal plus. In form-encoded data, which is what an HTML form and most query strings produce, a plus means a space. Apply the wrong rule and C++ comes back as C followed by two spaces, or a search for salt and pepper comes back with plus signs in it.

Nothing you paste leaves your browser. There is no upload and no logging, and the text is never written into the page URL, so a signed link or a session token pasted here does not end up in a shareable address or in a log somewhere else.

Reserved, unreserved, and what each mode touches

RFC 3986 splits the character space into three groups, and the whole scheme follows from them. Unreserved characters may always appear literally. Reserved characters have a structural meaning and must be escaped when they are data rather than structure. Everything else has no place in a URI at all and is always escaped.

Full URL mode escapes only the third group, so an address keeps working. Component mode escapes the second group as well, which is what makes it safe for a single value. Neither ever touches the first group, so a slug made of letters, digits and hyphens passes through both modes unchanged.

Why a plus sign sometimes means a space

Two different specifications are in play and they disagree. RFC 3986 defines percent-encoding for URIs and says nothing about the plus sign, so there a plus is simply a plus. The form-encoded serialisation, which HTML defines for what a form sends, encodes a space as a plus instead of as %20.

That second rule exists for historical reasons and it is not going away, because every HTML form and most search boxes on the web still emit it. So the same string can arrive with a space written two ways, and a decoder has to be told which rule to apply rather than guessing.

The rule of thumb: tick the plus box for anything that came out of a query string or a form submission, and untick it for a path segment, a fragment, or a value you built by hand. When you are encoding, escape a real plus as %2B and the question never comes up.

The formula, worked line by line

Percent-encoding has one rule and no arithmetic. Take the character, take its UTF-8 bytes, and write each byte as a percent sign followed by two hexadecimal digits. The only question a tool has to answer is which characters get that treatment, and that is where the two modes differ.

Because the unit is the byte rather than the character, the cost of encoding depends entirely on the alphabet. Anything in the ASCII range is one byte and three characters. Latin with accents, Greek, Cyrillic, Hebrew and Arabic are two bytes. Most Chinese, Japanese and Korean characters are three, and emoji are four.

triplet = "%" followed by the byte in two hexadecimal digits
encoded length = 3 × the number of UTF-8 bytes needing escape
unreserved, never escaped: A-Z a-z 0-9 - . _ ~
component mode also escapes: ; / ? : @ & = + $ , #
form-encoded only: a space may be written + instead of %20

Hexadecimal digits may be written in either case, so %c3%a9 and %C3%A9 decode identically. Uppercase is what RFC 3986 recommends and what browsers produce, and matching that convention makes two versions of the same URL compare equal instead of merely decoding equal.

Double encoding is the failure mode to watch for. Encode a value that was already encoded and every percent sign becomes %25, so %20 turns into %2520 and the receiver hands your code a literal percent two zero. If a value arrives looking like that, something in the chain encoded it twice.

Length limits are the other practical consequence. There is no limit in the specification, but implementations impose their own, and a common conservative ceiling is around 2,000 characters for a URL that has to work everywhere. Non-Latin text encoded at three characters a byte reaches that ceiling far sooner than it looks like it should.

Questions people ask