Double Encoding Bugs: How They Happen & How to Spot Them
You’ve seen it: a URL containing %2520 instead of %20, or %252F instead of a slash. That “25” means the percent sign itself was encoded — twice. The result? Servers either reject the request or silently decode only once, breaking your data.
How Double Encoding Sneaks In
Common culprits:
- Encoding a value, then encoding the whole URL again
- Using encodeURI() on an already-encoded string
- Middleware or proxies that “helpfully” re-encode
- Copy-pasting from tools that don’t warn you
Real Production Horror Stories
Analytics platforms receiving campaign=Spring%2520Sale (becomes Spring%20Sale → no match). OAuth redirects failing because the state parameter contains %253D instead of = after two rounds of encoding.
How to Detect It Instantly
Paste the suspicious URL into this tool. If you see %25 anywhere in the output — you have double encoding. The decoder will show you the correct final string after one proper pass.
Prevention Checklist
- Encode only raw user input — never re-encode an already encoded string
- Use this tool as your source of truth before sharing links
- Search your codebase for nested encoding calls
FAQ
Is %2520 ever valid?
Only if you intentionally want to send a literal “%20” as data — almost never.
Does decodeURIComponent fix it?
Yes — one call removes one layer. This tool lets you decode repeatedly until clean.
One paste in this tool saves hours of log diving. Use it every time you see %25.