URL Decoder

URL Decoder reverses percent-encoding: it turns sequences like %20, %2F, %3A and UTF-8 byte runs such as %E2%9C%93 back into the spaces, slashes, colons and Unicode characters they represent. It is built for the moment you are staring at an opaque, escaped string and need to see what it actually says.

For web and dev work it fits inspecting tracked or redirect URLs, reading a query string a server logged, or unpacking a value pulled from an API response, a webhook payload, or a referrer field. For office, admin and student tasks it is just as useful for decoding the long click-through links email platforms wrap around destinations, or for reading a parameter someone pasted into a ticket or spreadsheet.

Because it works on raw text rather than a live address, you can also use it to sanity-check a single decoded segment before you reuse it elsewhere, or to compare what two encoded links really point to when sharing or auditing them.

The flow is direct: paste your encoded text into the Input box and press Run, or use the Ctrl/Cmd+Enter shortcut. Decoding happens entirely in your browser using the standard decodeURIComponent routine, so nothing is uploaded and nothing remains once the tab closes. The decoded result appears in the Output box, where Copy puts it on your clipboard and Download saves it as a plain .txt file (formatos-url-decoder.txt).

It decodes every percent-escape it finds, including reserved characters, so %2F becomes a slash and %3F becomes a question mark rather than being left intact. Multi-byte UTF-8 escapes are reassembled into their proper characters, which is why an emoji or accented letter comes back correctly instead of as separate bytes.

Two notes on scope. A plus sign is left as a literal +, not converted to a space, because this is component decoding rather than form-field (application/x-www-form-urlencoded) decoding. And the tool only decodes; it does not parse a URL into host and parameters, follow redirects, fetch the page, or re-encode anything.

The most common surprise is the plus sign. Strings that came from an HTML form often use + for spaces, and this tool will leave them as +. If your source is form data, replace + with %20 before decoding, or expect to fix spacing afterward.

Malformed pieces are left alone rather than guessed at. A percent sign that is not followed by two hex digits, an invalid pair like %ZZ, or a truncated multi-byte sequence such as a lone %C3 stays in the output exactly as written, while everything valid around it is decoded. If you see a leftover % sequence, that part of the source was not valid percent-encoding.

Also watch for double-encoding: a value escaped twice (for example %2520) decodes only one layer per pass, so you may need to run it again. Decoding does not validate that the result is a safe or legitimate link, and very large pastes are handled in a single in-browser operation, so extremely long inputs lean on your device's memory.

Read the decoded result against what you expected: confirm spaces, slashes and colons landed where they belong, that any non-English or symbol characters render correctly, and that no stray %25 or leftover escapes remain (a sign of double-encoding that needs another pass). If you decoded only a fragment, make sure you grabbed the whole value and not half of a parameter.

Remember the plus-sign rule when the text came from a form, and look at any % sequence left in the output: it marks the exact spot that was not valid encoding. If the output still looks scrambled, the source may not have been percent-encoded in the first place, or it may be a different scheme such as Base64 or HTML entities.

For anything official or financial, such as a payment link, an invoice reference, or a parameter you will act on, verify the decoded value manually against the original source rather than relying on the decode alone. This tool reveals what the encoded text says; confirming that the underlying link or value is correct and current is still your call.