UtilityBase logoUtilityBase

2 min read

What Is URL Encoding and When Do You Need It

Why URLs can only contain certain characters, how percent-encoding represents the rest, and which reserved characters you must escape and when.

Why URLs cannot hold every character

A URL is limited to a small set of ASCII characters. The unreserved set, which never needs encoding, is the letters A to Z and a to z, the digits 0 to 9, and the four marks hyphen, period, underscore, and tilde. Everything else is either reserved for a structural role or is unsafe to include directly.

Spaces, non-English letters, emoji, and most punctuation cannot appear literally in a URL. To carry them, the URL uses percent-encoding, which represents a byte as a percent sign followed by two hexadecimal digits. A space becomes %20 and an at sign becomes %40.

How percent-encoding works

Percent-encoding operates on bytes, not characters. The text is first encoded to bytes, almost always with UTF-8, and then each byte that is not allowed is written as % plus its two-digit hex value. The euro sign, three bytes in UTF-8, becomes %E2%82%AC.

Because the percent sign itself is the escape marker, a literal percent must be encoded as %25. Forgetting this is a common source of double-encoding bugs, where an already-encoded string is encoded again and %20 turns into %2520.

Reserved characters and why context matters

Reserved characters such as the slash, question mark, hash, square brackets, at sign, ampersand, plus, comma, semicolon, and equals have special meaning in a URL. A slash separates path segments, a question mark begins the query string, a hash marks a fragment, and an ampersand separates query parameters. When you want one of these as literal data rather than structure, you must encode it.

This is why the answer to 'do I encode a slash' is 'it depends'. Inside a path a slash is structural and stays literal, but a slash that is part of a single query-parameter value must be encoded as %2F so it is not misread. The plus sign is especially tricky: in a query string it can be interpreted as a space, so a literal plus should be sent as %2B.

Encoding and decoding with the tool

The URL Encoder / Decoder converts text to its percent-encoded form and back, so you can build safe query strings or read what an encoded URL actually says.

  1. 1Paste the text or full URL into the input box.
  2. 2Choose encode to convert special characters into percent-encoded form, or decode to reverse it.
  3. 3Copy the result into your link, API request, or query parameter.
  4. 4If you are encoding a value that goes inside a query parameter, confirm that reserved characters in the value were escaped.
  5. 5Decode a suspicious URL to reveal any hidden or obfuscated destination before you trust it.

Common pitfalls

Two mistakes cause most broken links. The first is double-encoding, where a string is encoded twice and every percent sign becomes %25. The second is encoding the whole URL when you only meant to encode one parameter value, which escapes the structural slashes and colons and destroys the link. Encode the individual pieces, then assemble them.

Frequently asked questions

What is the difference between %20 and a plus sign for a space?

%20 is the standard percent-encoding for a space and works anywhere in a URL. A plus sign only means space inside the query string under form encoding, so %20 is the safer, universal choice.

Do I need to encode letters and numbers?

No. Unreserved characters, which are A to Z, a to z, 0 to 9, and the marks hyphen, period, underscore, and tilde, are always safe and should be left as-is. Encoding them is harmless but unnecessary.

Why did my encoded string get %2520 in it?

That is double-encoding. An already-encoded %20 was encoded again, turning its percent sign into %25. Encode text only once, and decode before re-encoding if you are unsure of its current state.

Tools mentioned in this guide

Keep reading