URL decode, one parameter at a time

Because whatever produced it used form encoding, where a space is written as a plus sign. That convention comes from HTML 2.0 form submission in 1995 and survives today as application/x-www-form-urlencoded, the media type a browser posts a plain <form> with and the format URLSearchParams writes. It applies to the query string and to a form body — nowhere else. A plus inside a path segment is a literal plus, which is why this page makes the behaviour a switch instead of a rule: decoding /files/c++/readme with the switch on gives you /files/c /readme and a puzzle.

It is a space that was encoded twice: the space became %20, then the % of that escape became %25, giving %2520. One round of decoding can only undo one round of encoding, so it hands back %20 and stops — correctly, because a decoder cannot know whether that %20 is data or another layer. This page decodes again while the result still contains an escape, up to six rounds, and lists each round so you can see how many encoders the value passed through. Two rounds almost always means a URL was put inside a redirect parameter of another URL by code that called the encoder without checking whether one had already run.

A % that is not followed by two hexadecimal digits, which makes the escape meaningless. The usual cause is a literal percent sign that was never encoded — “50% off” written straight into a query value produces %20 out of “% o”, or fails outright — and the fix is to write it as %25 at the source. A truncated string does it too, when the copy stopped between the % and its digits. Position numbers here count characters from the start of what you pasted, so you can find the spot without counting by hand.

Because a single byte E9 is é in Latin-1 but is not valid UTF-8 at all — in UTF-8 that letter is two bytes, %C3%A9. Something upstream encoded the text in a legacy character set: an old .NET handler, a form whose page declared iso-8859-1, or a desktop application that never left the 1990s. The bytes are shown through Windows-1252 rather than as replacement characters, so the text stays readable, but the fix belongs at the encoder: serve the page as UTF-8 and the same letter arrives as %C3%A9.

Both, and it does them at the same time. The right pane decodes everything you pasted as one string, which is what you want for a value; the table below splits the query first and decodes each parameter separately, which is what you want for a link. Splitting a URL into scheme, host, port, path and fragment is a different operation and lives on the URL parser page.

No, and it is the most common way to corrupt a URL. A value may legitimately contain %26, an ampersand that is data rather than a separator; decode first and that value splits into two parameters, quietly. The same applies to %3D, an equals sign inside a value. Every parser worth using splits on the raw & and =, then decodes each half, and that is the order this page follows — which is why the table shows the raw value beside the decoded one.

It will, if the plus toggle is on and the string is Base64. Base64 uses + as one of its 64 data characters, so turning it into a space destroys the payload — the page notices a Base64-shaped input and says so rather than letting you find out later. A signature, a hash in a header and an encrypted token have the same problem. Switch the toggle off for anything that is not a query string.