URL Decode

URL decoding reverses percent-encoding. In an encoded URL, unsafe characters were replaced with a % followed by two hexadecimal digits representing a byte value. Decoding scans for each %XX group, converts the hex back to its byte, and restores the original character.

The simplest case is the space. The sequence %20 decodes back to a single space, so hello%20world becomes hello world. Reserved characters return the same way: %26 becomes &, %3F becomes ?, and %2F becomes /.

Characters that were never encoded, such as letters, digits, and the unreserved symbols -, _, ., and ~, simply pass through unchanged. The result is the human-readable value that was originally placed into the URL. Because the mapping is fixed and one to one, a correctly encoded string always returns exactly what went in, with no ambiguity. To encode text in the first place, use URL Encode, which is the exact inverse of this tool.

Query strings are where decoding pays off most. A long URL packed with % sequences is nearly unreadable, but decoding turns it into plain text you can scan and verify.

The table shows common encoded sequences and what they restore to:

One detail to watch is the + sign. In the query-string style of encoding, a literal + often represents a space, while in strict percent-encoding a space is always %20. If a decoded value shows + where you expected spaces, the source used the form-style convention. Knowing which scheme produced the URL helps you read the result correctly, especially when inspecting links from forms or search pages built with URL Encode. When the difference matters, check whether the source was an HTML form, which favors + for spaces, or a hand-built link, which usually sticks to %20 throughout.

International characters in URLs are stored as percent-encoded UTF-8 bytes, and decoding reassembles them back into letters. Because many characters use more than one byte, several percent groups can combine into a single character.

For example, %C3%A9 is two bytes that together decode to é, and a three-byte sequence like %E2%82%AC decodes to the euro sign. The decoder reads the byte values, groups them according to UTF-8 rules, and produces the correct character.

This is why you should decode the whole sequence at once rather than one group at a time. Splitting a multi-byte character apart would leave you with meaningless individual bytes. When a value decodes into unexpected symbols, the original may not have been UTF-8, or part of the sequence was lost in copying. Recopy the full encoded string from its source and decode again to confirm. A clean decode of multi-byte text is a good sign that the link survived its journey intact, since even one missing byte would throw the whole character off.

Sometimes one decode pass is not enough. If a value was encoded twice, a single decode leaves you with a string that still contains % sequences. The classic clue is seeing %2520, which decodes once to %20 and only then to a space.

When you decode a URL and the output still looks encoded, that is double encoding in action. The fix is to decode a second time:

• First pass turns %2520 into %20
• Second pass turns %20 into a space

Decode repeatedly until no %XX sequences remain and the text reads cleanly. Be careful not to over-decode a value that legitimately contains a literal % character, though, since that can corrupt real data.

If the value combines percent-encoding with another layer such as Base64, peel the layers in order. After URL decoding, Base64 Decode can handle any Base64 that was hiding underneath. Working through the layers in the order they were applied keeps each decode predictable and stops you from corrupting data partway through.

Decoded URLs often reveal more than they appear to. A query string can carry email addresses, search terms, session identifiers, or tracking parameters, all hidden behind percent sequences. Decoding makes that content readable, which is exactly why you sometimes want to inspect a link before clicking or sharing it.

Because this tool runs entirely in your browser, the URLs you paste are never sent to a server. The decoding happens locally, so a link containing personal data or a private token stays on your own machine.

This is useful when reviewing redirect chains, debugging an API request, or checking what a marketing link actually contains. You see the real parameters without exposing them to a third party. If you spot a value that is itself a token rather than plain text, a tool like JWT Decoder can read structured tokens, while URL Encode lets you re-encode any value you edit. Keeping the inspection local is what makes this safe to do with links you would never want logged elsewhere.