URL Encoder / Decoder

What percent-encoding is for

URLs may only contain a restricted set of ASCII characters. Everything else — spaces, accented letters, emoji, and the punctuation that carries structural meaning — has to be represented as a percent sign followed by the hexadecimal value of each byte. A space becomes %20, an ampersand becomes %26, and a character outside ASCII becomes several percent-escapes, one per UTF-8 byte.

This is why encoding matters so much for query parameters. Characters like &, =, ?, # and / are how a URL is parsed. If a value you are inserting contains one of them unencoded, the URL is cut apart in the wrong place — a search for "fish & chips" silently becomes a parameter named "chips" unless the ampersand is escaped.

Encode the value, never the whole URL

The most common mistake is running an entire URL through an encoder. That escapes the structural characters too, turning https://example.com/search?q=x into a single meaningless string where the colon, slashes, question mark and equals sign have all been neutered.

Encode each parameter value on its own, then assemble the URL around them. The delimiters must stay literal, because they are what gives the URL its shape — the encoding exists to stop values being mistaken for structure, not to escape the structure itself.

The + versus %20 confusion

Spaces have two encodings and which is correct depends on where in the URL you are. In a query string submitted by an HTML form, a space is traditionally a plus sign, from the older application/x-www-form-urlencoded format. Everywhere else — and in a path segment always — a space is %20.

The consequence is that decoding a plus sign is ambiguous. If a value legitimately contains a plus, such as a phone number in +44 form or a tagged email address, a form-style decoder will turn it into a space and corrupt the data. That is why a plus in a value should be encoded as %2B whenever the value might be read by a form-style decoder, and it is a genuine and frequent source of bugs in email address handling.

Double-encoding and how to spot it

Encoding an already-encoded string escapes the percent signs themselves: %20 becomes %2520, because % encodes to %25. Decoding it once then leaves you with the literal text %20 rather than a space.

If you see %2520, %253A or %2526 in a URL, something in the chain has encoded twice — commonly a value that was encoded by application code and then encoded again by a framework or a redirect layer. Run the string through decode repeatedly here to find how many layers deep it goes, then remove the duplicate encoding step rather than compensating with an extra decode.

Non-ASCII, internationalised domains, and SEO

Non-ASCII characters in a path are encoded per UTF-8 byte, so a single accented letter becomes two escapes and most CJK characters become three. That is correct and browsers display it back as readable text in the address bar, but it makes URLs long and ugly when shared as raw text.

Domain names work differently: they use Punycode rather than percent-encoding, so an internationalised domain appears as an xn-- prefixed form. For SEO, readable ASCII slugs with hyphens are still the safest choice — they survive copying, sharing and logging intact, and hyphens are treated as word separators by search engines in a way that underscores are not.