URL encoding, query parser and redirect debugger
Paste a messy link. This thing decodes the percent-encoded junk, pulls apart the query string, flags the tracking fields, and digs out any redirect URL buried inside another parameter. It’ll also hand you back a clean copy with the campaign cruft stripped. Honestly it’s mostly for the moment an API call or an analytics link breaks and you can’t tell why.
URL processing runs in your browser. This tool does not open the destination; it inspects the string and the parsed URL structure.
URL encoding protects structure from accidental meaning
A URL leans on a handful of characters to mean something structural. The question mark kicks off the query string. Ampersands split one parameter from the next. Equals signs glue a value to its key, slashes carve up the path, and the hash fragment never even leaves the browser. So what happens when a value contains one of those characters on purpose? Say a space, or a stray symbol, or another whole URL stuffed inside it. Without percent encoding, the parser reads that character as structure and the whole thing falls apart. That’s the headache behind redirect links, OAuth callbacks, search URLs, and pretty much any API client you’ve fought with.
I built this less as a one-click converter and more as a thing you reach for when something’s already broken. It decodes the percent gibberish, encodes a component or a full URL, breaks the query into rows, marks which keys are tracking, and yanks out redirect targets hiding a layer or two deep. Then it gives you a tidied URL with the usual tracking junk gone. The plus column is there because form encoding turns a plus into a space and a normal path doesn’t, which trips people up more than you’d think.
How to choose the right encoding mode
Reach for encodeURIComponent behavior when you’ve got one value going inside a query parameter. Full URL encoding is the other case: you want the URL’s shape to stay readable while the sketchy characters inside it get escaped. Decode mode is for when a link lands in your lap from an email or a redirect chain or some API log and you need to read what it actually says. And if a parameter is hiding an encoded URL of its own, bump the decode depth up and go look at the nested URL tab. That one catches people off guard.
- Decode URL turns the gibberish back into readable query values and surfaces nested destinations.
- Encode component is your pick for a single query value. A search term, a callback URL, that kind of thing.
- Encode full URL leaves the separators alone and only escapes the unsafe stuff.
- Parameters pulls the real application values away from the tracking noise.
- Clean URL drops the campaign and click IDs so you can debug without the clutter.
Useful checks before clicking or sharing a link
Decode first, then look at the hostname. The visible text lies all the time. A long link can tuck a redirect parameter inside itself that fires you off somewhere completely different, and you’d never know from a glance. UTMs themselves are harmless, mostly, but they’re pure noise when you’re trying to debug a canonical URL or an API signature. Then there’s double encoding, where a callback got encoded once for its parameter and then again for the redirect wrapping it. That’s sometimes exactly right. The problem is when nobody meant for it to happen.
Common questions
Should I encode a whole URL or only a component?
Going inside another URL’s parameter? Encode the component. The whole-URL option only makes sense when that URL is itself the final destination and you want its structural characters to stay readable. Mix those two up and you’ll spend an afternoon staring at a double-encoded mess wondering what went wrong.
Why does plus sometimes become a space?
Blame the form encoding. HTML forms have used a plus to mean a space since forever. Drop that same plus somewhere else in a URL, though, and it’s just a plus sign that means plus. Annoying, right? You can flip between both readings here and watch which one your link actually wants.
Can this check whether a redirect is safe?
Sort of, not really. It’ll surface a nested destination and point out structure that looks off, but it never opens the page and it won’t promise you anything is safe. I wouldn’t lean on it for that. For the real call, run the link through a proper redirect checker and confirm the domain with your own eyes.
Which characters need URL encoding?
Spaces, for starters, which become %20. Then the reserved ones when they show up inside a value instead of doing their structural job: the ampersand, the question mark, the hash, the slash. And anything non-ASCII gets encoded too. Basically if a character could be mistaken for URL plumbing, escape it.
What is the difference between encodeURI and encodeURIComponent?
encodeURI plays nice with a full URL and leaves the structural characters alone so the link still works. encodeURIComponent doesn’t care, it escapes those too. That second one is what you want for a lone query-string value, because there’s no structure left to protect.
Why do I sometimes see + instead of %20 for a space?
Two formats, one space. Plain percent-encoding writes it as %20. The application/x-www-form-urlencoded format that HTML forms spit out writes it as a plus instead. Put each in its proper context and both come back out as a space, so neither one’s wrong.
