Reading a long URL
A tracking URL, an OAuth callback or a redirect chain arrives as a wall of percent escapes with another URL nested inside it. Decoding turns it back into something you can reason about — which parameters are set, where the redirect actually points, whether the state parameter survived.
Decode once, not twice
Double-encoding is common and double-decoding is the bug it causes. If a value
was encoded twice, %2520 appears where %20 was meant: decoding once gives
%20, decoding again gives a space. If your decoded output still contains
escapes, that is the signal — decode again deliberately rather than assuming the
tool failed.
Going the other way, decoding a value that was only encoded once and then
decoding again will corrupt any literal % in the original text.
The three modes
Component decoding handles a single parameter value. Whole-URL decoding leaves
the structural characters alone, so %2F inside a path stays escaped rather than
turning into a slash that changes the route. Form decoding additionally treats
+ as a space.
Questions
Why does my decoded text have a stray plus sign?+
Because you decoded in component mode and the string was form-encoded. In form encoding a bare + means a space; in a path it means a literal plus. Switch to form mode and the + becomes a space.
What does "URI malformed" mean?+
A % that is not followed by two hexadecimal digits. Usually the string was truncated mid-escape, or it was decoded once already and a literal % survived from the original text — decoding twice is the most common cause.
Why do I see Ð and â in the result?+
The text was encoded as UTF-8 and decoded as Latin-1 somewhere along the way. This tool decodes as UTF-8, which is correct, so those characters were already in the input — the damage happened upstream.
Is it safe to paste a URL with a token in it?+
It never leaves your browser. Decoding is a string operation performed in this tab, which is exactly why a local decoder is the right place for a signed redirect URL or an OAuth callback.