URL Encoder / Decoder

What is URL encoding?

URL encoding, also called percent-encoding, converts characters that are not allowed or have special meaning in a URL into a safe form. Each character becomes a percent sign followed by two hexadecimal digits giving its byte value in UTF-8. A space becomes %20 and an exclamation mark becomes %21. The copyright symbol © is two bytes in UTF-8, so it takes six characters: %C2%A9.

Why it is required

RFC 3986, the standard that defines Uniform Resource Identifiers, spells out exactly which characters a URL may contain. Only the unreserved set (A–Z, a–z, 0–9, hyphen, underscore, period, tilde) can appear as-is. Reserved characters such as colon, slash, question mark, ampersand, equals and hash carry syntactic meaning, so they must be encoded whenever they are meant as literal data rather than structure. Everything else, including spaces, accented letters and emoji, always gets encoded.

encodeURI versus encodeURIComponent

These two are not interchangeable, and mixing them up is the most common URL bug there is.

encodeURI() encodes a whole URL while preserving its structure. It deliberately leaves : / ? # & = + $ , ; @ ! ' ( ) * alone, because those characters are what makes a URL a URL. Reach for it when you have a complete address containing a stray space.

encodeURIComponent() encodes everything except the unreserved set. It is for a single value going into a query string. If a search term contains an ampersand, this one turns it into %26 so it cannot be mistaken for the start of the next parameter.

Feed a full URL to encodeURIComponent() and you get https%3A%2F%2Fexample.com, which is correct behaviour and almost never what you wanted.

The plus sign trap

In application/x-www-form-urlencoded data (an HTML form submission, and the query string that comes from one) a + means a space. In a URL path, or anywhere else in a URI, + is a literal plus sign and nothing more. The two conventions have coexisted since the early 1990s and they still catch people out.

So ?q=a+b is ambiguous on its own: as form data it reads “a b”, as a plain URI it reads “a+b”. This tool decodes strictly, treating + as a plus, and tells you what the form-data reading would have been whenever the two differ. When you are producing a URL rather than reading one, sidestep the whole question by encoding a space as %20, which is unambiguous everywhere.

Double encoding

The other classic bug. Encode a string that already contains percent-escapes and the percent signs themselves get escaped: %20 becomes %2520. If the server then decodes once, the visitor sees a literal “%20” in the page; if some proxy decodes a second time, the two layers cancel and nobody notices until a filename contains a real percent sign.

UTF-8 and international characters

Modern browsers and servers all use UTF-8 here. The Chinese character 中 is three bytes (0xE4 0xB8 0xAD), so it encodes to the nine-character %E4%B8%AD. Non-English URLs get long fast. Domain names solve the same problem differently, at the DNS level, using Punycode.

What this means for SEO

Encoded URLs work fine, but they read as noise to a human and are awkward to paste into a chat message. Most content systems (WordPress, Hugo and the rest) sidestep percent-encoding for page addresses entirely: they build a slug by lowercasing the title, replacing spaces with hyphens and dropping anything else. That is the better answer for a public URL, and percent-encoding is for the query string.