URL decoder

What this tool does

This is a URL decoder and a query string parser in one page. Paste a link of any length — a redirect out of an email, a callback URL from an OAuth flow, a line lifted from a server log, a tracking link with thirty parameters glued to the end of it — press Decode, and two things come back. The whole string is converted from percent-encoded text into human readable text, and if it carries a query string, every parameter in that query is laid out underneath as a table with the key in one column and the value in the next.

The table is the part that saves the time. A query string is a single run of characters in which the boundaries are marked by two punctuation characters that look identical to every other character around them, and finding the fourth parameter by eye means counting ampersands. Split into rows, the same query answers at a glance which parameters are present, which are empty, and which one carries the value that is wrong.

Each decode appears above the one before it, so two versions of a link can be compared without losing the first. "Copy" hands back the decoded text; "Copy link" hands back a link to this page with the URL you pasted already in it, so a colleague opening that link sees the same decode without you having to explain which link you meant. Results can be removed one at a time or cleared all at once, and nothing survives a refresh.

What percent-encoding is, and why URLs have it

A URL is allowed to contain a small, fixed set of characters: letters, digits, a handful of marks such as the hyphen and the full stop, and a few punctuation characters that carry structural meaning — the slash that separates path segments, the question mark that opens the query, the ampersand that separates parameters, the equals sign that splits a key from its value, the hash that starts the fragment. Everything else has to be encoded, and so does any of those structural characters when it is meant as data rather than as structure.

The encoding is deliberately plain. The character is converted to its bytes in UTF-8, and each byte is written as a percent sign followed by two hexadecimal digits. A space becomes %20. A slash inside a value becomes %2F. An ampersand that belongs to the data becomes %26, which is exactly what keeps it from being read as the start of the next parameter. Anything outside ASCII takes more than one escape: the é in café is two bytes and therefore %C3%A9, and an emoji is four.

Decoding reverses that, and it is a mechanical operation with no room for interpretation — which is why a decoder can be trusted to be exact. What it gives you is the string the sender meant, rather than the string the URL was obliged to carry.

The query string table, and why the order of operations matters

Everything after the first question mark, up to the fragment, is the query string. Convention rather than specification says it is a list of key–value pairs, separated by ampersands, each pair split at the first equals sign. That is the convention this page follows: split on the ampersand to get one row per parameter, split each row at its first equals sign to get the two columns.

The order of those steps is not a detail, and getting it backwards is the single most common bug in home-made URL parsers. The splitting has to happen on the encoded text, before anything is decoded. Consider a search parameter whose value is café & bar: encoded, the ampersand inside it is %26 and cannot be confused with a separator. Decode the whole query first and that %26 becomes a real ampersand, so the split then produces two parameters where the sender sent one, and the value quietly loses everything after the ampersand. The same trap applies to an equals sign inside a value, which is why the split is made at the first equals sign only — a base64 value ending in padding, or a nested URL carrying its own query, would otherwise be cut in half.

A parameter written with no equals sign at all is legal and reasonably common as a flag. It appears in the table with its key and a value marked as empty, rather than being dropped, because a flag that is present is a different thing from a flag that is absent.

Your URL never leaves your browser

Nothing you paste here becomes a network request. The decoding is done by your own browser, the table is built in the page, and the text is held in memory only — nothing is posted to a server, written to a cookie or saved in local storage. Refreshing clears every result, and closing the tab disposes of the data.

A URL looks like the least sensitive thing you could paste anywhere, and it is routinely the most. Query strings are where systems put session identifiers, password reset tokens, signed download links, API keys added by a lazy integration, invitation codes, email addresses, and enough tracking parameters to identify a specific person on a specific device. A password reset link pasted into a decoder that uploads its input has been handed to somebody, and the reset token in it is usually valid for another hour.

Because the decoding happens in your browser, none of that arises. Open your network tab while you use this page: apart from the analytics beacon the site sends on every page load — a URL and a page title — decoding produces no request at all. Disconnect from the network entirely and the tool keeps working, which is the only demonstration of the claim that does not require taking anyone at their word.

Plus signs, double encoding and the other traps

Three things routinely make a decoded URL look wrong, and all three are worth recognising rather than debugging.

The first is the plus sign. In a query string a plus traditionally means a space, a leftover from HTML form submission that every web framework still honours. Everywhere else in a URL — in the path, in the fragment — a plus is a literal plus. This page follows that split exactly: the table treats a plus in a parameter as a space, while the full decoded string above it leaves plus signs alone. If a value that should read [email protected] comes back with a space, the sender encoded it wrongly; a literal plus in a query value must be sent as %2B.

The second is double encoding. A URL that has been through an encoder twice shows %2520 where a space should be, because the percent sign of %20 was itself encoded to %25. Decoding once turns that back into %20 rather than into a space, which looks like a broken decoder and is in fact an accurate report of a broken link. Paste the result back in and decode again to confirm it — and then fix the code that encoded it twice, usually a value that was encoded when it was stored and again when it was put into a link.

The third is a malformed escape: a bare percent sign that is not followed by two hexadecimal digits, which happens whenever a URL has been truncated by a log format or cut off by a line wrap. A strict decoder refuses the entire string on that basis. This page instead decodes the escapes that are valid, leaves the broken one visible where it sits, and lets you read the rest — which is what you needed from a truncated log line in the first place.

A worked example

Take a search link with five parameters: a query of café + bar with both the accent and the ampersand encoded, a category containing a slash, a page number, a note containing a percent sign, and a redirect target that is itself a full URL with its own query.

Decoded, the header reports five parameters. The first row reads q and café & bar — one parameter, not two, because the split happened before the decoding. The category row shows food/drink with its slash restored, and the note shows 50% off, where the percent sign survived only because it was sent as %25. The last row holds the nested URL, complete with the question mark and ampersand of its own query, which is exactly the case that breaks a parser that decodes too early. Press "Load a sample" to see that link taken apart.