URL Decoder
Turn percent-escapes back into readable text. Plus signs are treated as spaces because that is what they mean in a query string, and a value that was encoded twice can be unwrapped in steps. An incomplete escape is reported with its exact position rather than as a bare encoding failure.
Correct for form data and query strings. Turn it off if the plus sign is meant literally.
Unwraps a value that was encoded two or three times, up to four passes.
How url decoder works
- Paste the encoded stringA full URL, a query string or a single escaped value all work.
- Decide about plus signsLeave the toggle on for query strings, turn it off for a path.
- Check for leftoversFurtu warns if escapes remain, which usually means double encoding.
What you get
Read a percent-encoded URL, including values encoded more than once. Everything happens inside this page: the file is read by your browser, transformed in memory and handed straight back to you as a download. There is no upload queue, no waiting for a server, and nothing left behind when you close the tab.
Supported formats
This tool works on text you paste or type, so there is no file format to worry about. Nothing you type is sent anywhere.
Limitations, stated up front
- Repeated decoding is capped at four passes. A deeper stack of encoding needs the same number of manual decodes.
- Multi-byte characters are reassembled as UTF-8, so a value encoded as Latin-1 will be reported rather than guessed at.
Frequently asked questions
Why does plus become a space?
Because in a query string it always has. HTML forms have encoded spaces as a plus since the early web, and everything that reads a form body accepts it. In a path or a fragment a plus is a real plus, which is why this is a toggle rather than a rule.
What if my value is encoded twice?
Some stacks encode a value, put it in a URL, and encode it again on the way out. The server then decodes once and sees %20 rather than a space. Repeated decoding peels that off, and Furtu stops after four passes or as soon as the value stops changing, so it cannot run away on text that is not encoded at all.
Why does it report the position of a bad escape?
A truncated value such as a query ending in %2 is common in a log line that got cut off. Knowing the character position turns a generic failure into something you can find, and the built-in decoder throws without saying where.
Does the decoded text get sent anywhere?
No. It is decoded in the tab and never transmitted, which matters because a URL often contains a token or a reset code.