URL Decoder

Reading a percent-encoded string by eye is a reliable way to miss what it says. Decoding it here costs nothing — nothing is fetched, nothing is requested, and no reputation service is told what you are looking at — so a hostile URL can be read safely before any decision is made about it.

Repeated decoding is a choice, not a default

A redirector often hides its real destination behind two or three layers of encoding, and decoding once leaves you looking at %2F%2Fevil.test wondering whether that is the answer. But repeated decoding also changes meaning: a legitimate value containing a literal %2520 is a string that merely looks encoded, and decoding it twice silently alters the data.

So it is a checkbox. When on, decoding repeats until the string stops changing, capped at eight passes so a crafted input cannot loop, and the status strip reports how many passes ran.

A plus sign is only sometimes a space

In form data (application/x-www-form-urlencoded, what an HTML form submits) + means a space. Everywhere else — a path, a fragment, most APIs — it is a literal plus. So that is a checkbox too, and it applies to the first pass only: a + that came out of decoding %2B was escaped on purpose.

Malformed input

A % not followed by two hex digits is not valid percent-encoding, and escapes that spell bytes which are not valid UTF-8 (%E9 on its own, the Latin-1 é) cannot be decoded to text either. Each is reported by name rather than guessed at, because guessing invents content.

Repeated decoding is different. If a later pass hits one of those, the % came out of an escape the sender wrote on purpose — 100%25%20off is 100% off, not an error — so decoding stops at the last pass that worked and the status strip says it stopped at a literal %.

a%2526b decodes once to a%26b and twice to a&b. If the decoded result is a live URL, run it through the IOC Defanger before it goes into a ticket or a chat window, or take it apart with the URL Parser.