URL Encoder / Decoder

How URL Encoder / Decoder Works

What is URL Encoding?

URL encoding (formally percent-encoding, defined by RFC 3986) converts characters that aren’t safe to use directly inside a URL into a %XX form, where XX is the character’s byte value in hexadecimal. A space becomes %20, an & becomes %26, and so on. URLs were originally designed around a small set of ASCII characters — percent-encoding is how everything else (spaces, punctuation, non-English text, emoji) travels safely inside one.

This tool encodes and decodes using component-style encoding — the same behaviour as JavaScript’s encodeURIComponent and Python’s urllib.parse.quote(safe=''). That means it’s built for encoding a single value that will be placed into a URL (a query parameter, a path segment) — not for re-encoding an entire URL as one blob, which would also incorrectly escape the scheme and host.

Reserved Characters

RFC 3986 defines a small set of unreserved characters that never need encoding: letters, digits, and - . _ ~. Everything else — including the reserved characters that give a URL its structure (/ ? : # [ ] @ ! $ & ' ( ) * + , ; =) — gets percent-encoded by this tool, because those characters have special meaning if they appear literally inside a value. A literal & inside a query parameter’s value, for example, would be misread as the start of the next parameter unless it’s encoded as %26 first.

Percent Encoding — How It Works

Encoding takes each byte of the UTF-8 representation of a character and writes it as % followed by two hexadecimal digits. A space (one byte, 0x20) becomes %20. A non-ASCII character first becomes multiple UTF-8 bytes, then each byte is separately percent-encoded — for example, ’₹’ (₹, 3 UTF-8 bytes) becomes %E2%82%B9.

Worked Example

q=hello world&page=1 encodes to:

q%3Dhello%20world%26page%3D1

Note that = and & are encoded too — this is component-style encoding, treating the whole string as a single value rather than an already-structured query string.

UTF-8 and Emoji

Every non-ASCII character is encoded as its full UTF-8 byte sequence before percent-encoding, so Unicode text of any script and any emoji round-trip correctly. “पुणे 🎉” (4 Devanagari characters, a space, and one emoji — 17 UTF-8 bytes total) encodes to %E0%A4%AA%E0%A5%81%E0%A4%A3%E0%A5%87%20%F0%9F%8E%89. If decoded bytes don’t form valid UTF-8, this tool reports that clearly rather than showing corrupted text.

Query Strings

A query string is the ?key=value&key2=value2 part of a URL. Each individual value (and, if it contains special characters, each key) should be percent-encoded before being joined with = and & — encode each piece separately with this tool, then assemble the full query string yourself. Encoding the entire key=value&key2=value2 string in one pass (as the worked example above shows) will also escape the structural = and &, which is correct only if that entire string is itself a single value being passed somewhere (for example, as one query parameter whose value is another URL).

URL vs URI

A URI (Uniform Resource Identifier) is the general concept of a string that identifies a resource. A URL (Uniform Resource Locator) is the most common kind of URI — one that also tells you how to fetch the resource (scheme, host, path). In everyday use the two terms are used almost interchangeably, and the percent-encoding rules (RFC 3986) apply to both.

Common Mistakes

• Encoding an entire URL, not a component. Passing https://example.com/a b through this tool percent-encodes the :// and / too, corrupting the URL structure. Only encode the parts that go inside a URL (query values, path segments), and assemble the rest of the URL around them unencoded.
• Confusing + and %20 for spaces. RFC 3986 percent-encoding uses %20 for a space. The older application/x-www-form-urlencoded convention (used by HTML form submissions) uses + for spaces instead — the two are not interchangeable, and mixing them up produces literal + characters in decoded text instead of spaces, or vice versa.
• Double encoding. Encoding an already-encoded string turns its % characters into %25, so %20 becomes %2520. Decoding this once correctly returns %20 — not a space — because a single decode only reverses one layer of encoding. See below.
• Assuming decode always succeeds. Not every string is valid percent-encoding — this tool reports invalid input as a clear result with the exact reason, rather than a cryptic error or silently mangled output.

Double Encoding — Why One Decode Isn’t Always Enough

If a value gets encoded twice before you receive it — often by accident, when two different layers of a system each apply their own encoding — decoding it once will only undo the outer layer. 100% done encoded twice becomes 100%2525%2520done; decoding it once returns 100%25%20done (the once-encoded intermediate, not the original), and only decoding a second time produces 100% done. This tool deliberately performs a single decode pass every time, rather than looping until no % characters remain: automatically decoding until nothing looks encoded is a well-known security anti-pattern, because it can be used to sneak encoded attack payloads past a filter that only checks the input once. If your data needs multiple decode passes, apply this tool multiple times deliberately.

Security Notes

Percent-encoding is not encryption or sanitisation — it only changes how characters are represented, not what they mean once decoded. Never rely on the mere presence of percent-encoding as a security control; always validate and sanitise decoded values before using them (in SQL queries, HTML output, file paths, etc.), exactly as you would validate any other user input. Recursively auto-decoding user-supplied strings without limit is a common source of request-smuggling and filter-bypass vulnerabilities — decode deliberately, a fixed number of times, matching how many times the value was actually encoded.

Related Tools

For decoding a full JSON Web Token (which uses Base64URL, a different encoding, not percent-encoding), use the JWT Decoder. For general Base64 encoding/decoding, see the Base64 Encoder / Decoder. To inspect or reformat a JSON payload before or after encoding it, use the JSON Formatter or JSON Validator.