Double URL Encoding

Double URL Encoding: Why %2520 Appears and How to Fix It

Double encoding is what happens when a value passes through an encoder one time too many. Each pass replaces every percent sign with %25¹, so a space that became %20 on the first pass becomes %2520 on the second. The data is not corrupted, but it is now wrapped in an extra layer, and a single decode returns %20 instead of the space you wanted².

Double encoding usually creeps in when two layers of a system each try to be helpful: a client encodes a value, then a framework or proxy encodes the already-encoded string again³. Consequently, the classic symptoms are literal %20, %3A, or %2F sequences showing up in decoded output, or their doubled forms %2520 and %252F appearing in logs³. The CapyToolkit decoder lets you peel the layers one at a time until the value stops changing, which is the reliable way to recover the original⁴.

How a value gets encoded twice

Double encoding is rarely deliberate; it emerges where responsibilities overlap. Picture a browser that encodes a query value with encodeURIComponent, producing %20 for each space⁵. That encoded string then flows into a server-side routine, or a redirect builder, that assumes its input is raw and encodes it again. Neither layer is wrong in isolation, because each one sees only the string it received and applies the rule it was designed for.

Where the extra layer gets added

Consequently, the % in %20 becomes %25, and the value now reads %2520¹. The same thing happens when a URL is stored, retrieved, and re-encoded before reuse, or when an API gateway re-encodes a path it forwards, which explains why %20 turns into %2520 without anyone touching the value by hand. From the machine's side nothing is wrong, because each encoder did its job on the input it received. The trouble is that the two encoders disagreed about whether the string was already encoded. Naming which layer owns encoding, and encoding exactly once there, prevents the whole class of bug before it starts⁶. Teams that split URL handling across a frontend, an API gateway, and a backend service are especially prone to this, since no single layer can see the whole pipeline.

The %25 fingerprint that reveals it

You detect double encoding by looking for percent signs that should not survive a decode. A correctly decoded value contains no %XX sequences at all, because decoding resolves them into characters⁷. The reason this works is that a single clean decode turns every valid escape into its literal byte, leaving nothing percent-shaped behind⁸, so any remaining % after one pass is proof of extra layers. That is why a single clean decode should leave the string fully human-readable, and if you still see percent escapes the input was encoded more than once by a layer that did not know it was receiving encoded data.

Reading the doubled escapes

When you decode a string once and the output still holds %20, %2F, or %3A, the value was encoded twice: the first decode stripped the outer layer and revealed the inner one⁹. Equally, seeing %2520 or %252F in a raw URL or a log line is the direct fingerprint, since %25 is an encoded percent sign and the trailing digits spell the original escape⁹. Furthermore, a value that needs three or more passes before it becomes clean text points to triple encoding, which happens in pipelines with many hops¹⁰. The CapyToolkit decoder shows the output of each pass, so you can count exactly how many layers wrap the value.

Recognizing the %25 fingerprint on sight, rather than decoding blindly, saves time when you are scanning a long access log for the source of a malformed redirect. It also helps you avoid false positives: a legitimately encoded percent sign, such as the one in 50%25off, should not be confused with the outer layer of a double-encoded string, because only the latter reveals an extra percent layer when decoded once¹¹.

Decoding layer by layer

The safe fix is iterative decoding, not a single guess. Paste the suspect value into DECODE mode and read the result: if it still contains percent-escapes, decode that output again, and repeat until the text stops changing². Each pass removes one layer, and the stable result is the original value.

Conversely, resist the urge to strip %25 with a find-and-replace, because that damages legitimate %25 sequences meant as literal percent signs⁷. Once you know how many layers exist, fix the source by choosing a single owner for encoding and removing the redundant pass⁶. The decoder never transmits your input, so you can safely unwind double-encoded production URLs, tokens, or redirect targets while you trace where the extra encoding entered the pipeline. Documenting which layer owns encoding, once you find it, also prevents the next engineer who touches that code from reintroducing the same redundant pass.

When one layer is enough

With small inputs the fix is always the same: pick one place in the pipeline and encode there. If a client is responsible, the server decodes raw values and never re-encodes. If a backend owns encoding, the frontend should pass the raw value without percent-encoding it first¹¹. This boundary is what matters, because the moment two layers both try to encode, they each need to know whether the other already touched the string, which is exactly the ambiguity that produces %2520 in production.

Beyond fixing the immediate bug, write the ownership rule into your codebase comments or README. Encoding happens at the boundary, not inside shared utilities, because shared utilities are the most likely place to be called twice by accident¹². Adding a single assertion that checks whether a value already contains %25 before encoding it is also a practical safeguard, because it turns a silent double-encoding bug into an obvious failure in development rather than a mysteriously mangled redirect in production.

When to use this

Turn to this when decoded values still show %20 or %2F, when logs contain %2520, or when a redirect target arrives mangled¹⁰. Paste the value into the CapyToolkit decoder and decode repeatedly until the output stabilizes, counting the layers as you go⁴. Use that count to locate the redundant encoding step in your pipeline, then encode exactly once at a single owning layer so the double-encoding cannot return⁵. This is especially useful when debugging a multi-hop redirect chain, where each hop is a candidate for having added an unwanted extra layer¹².

Examples

%2520

%20, then a space

a%252Fb

a%2Fb, then a/b

redirect=https%253A%252F%252Fexample.com

https%3A%2F%2Fexample.com, then https://example.com

50%25off

50%off