URL Encoder & Decoder

Get These Four Right and Little Else Goes Wrong

• Use encodeURIComponent for a single value — a query parameter, a path segment, anything going inside a URL — and encodeURI only when the whole thing is already a complete, working URL.
• Only turn on Form Encoding when you actually know the target expects it — a form submission or a classic query string, not a modern JSON API or a value going somewhere else entirely.
• Reach for Fully Decode when a value still has % characters in it after one decode — that's the signature of accidental double-encoding.
• Paste a full URL to see the breakdown automatically — no separate action needed, and every parameter value is one click from being copied.

Features

Component or Whole URL — Why the Function You Pick Matters

encodeURIComponent and encodeURI aren't two flavors of the same thing — they're built for opposite jobs, and picking the wrong one produces a genuinely broken result rather than just a cosmetically different one. Component encoding assumes the text is a single value that will be placed inside a URL, so it escapes /, ?, &, =, and # along with everything else unsafe — because if a query parameter's value happened to contain a literal &, leaving it unescaped would split the query string in the wrong place. URI encoding assumes the opposite: that the text already is a full, structured URL, and encoding those same characters would break the very structure it's supposed to preserve. Getting this backwards is one of the most common URL-handling bugs, and it's invisible until the exact input that breaks it shows up.

The Function selector switches between the two deliberately, rather than trying to guess which one a given input needs — a guess would be wrong exactly often enough to be dangerous. If a value is destined for a query parameter that itself contains another encoded payload, like a callback URL or a Base64-encoded token embedded inside it, Component is almost always the right choice, since it treats the entire string as opaque data rather than trying to interpret any part of it as URL structure.

The Silent Bug in Most "Simple" URL Decoders

A lot of quick online URL decoders take a shortcut: convert every + to a space before decoding, no questions asked. That's correct for a classic form submission or a query string, where + genuinely means space by long-standing convention — but it's wrong everywhere else, and a raw + is completely valid, meaningful data in plenty of real values: a phone number, part of a Base64 fragment, a mathematical expression. A decoder that always makes that substitution silently turns a real + into a space with no warning, which is a genuinely hard bug to catch later since the output still looks plausible. This tool only converts + to space when Form Encoding is explicitly turned on — the decoder never guesses at what convention your data was encoded with.

It's worth noting this is a different problem entirely from HTML-escaping a value before it goes into markup — an ampersand that needs to survive inside an href attribute's query string is a URL-encoding concern, while the same ampersand appearing in visible page text is an HTML entity concern, and conflating the two is a second common source of mangled links and broken pages.

Seeing Through a URL, Not Just Encoding It

Encoding and decoding solve half the problem — the other half is actually understanding a URL someone handed you, especially a long one with a dozen query parameters crammed into a single unreadable line. The moment either the input or the output looks like a complete URL, this tool parses it apart automatically: protocol, host, port, path, hash, and a clean table of every query parameter with its value already decoded and ready to copy on click. No separate "parse" button, no second tool — paste the URL and the breakdown is already there underneath the raw encode/decode output.

Every parameter's value is shown fully decoded regardless of how it was originally encoded in the URL, which matters more than it sounds — a query string can legitimately mix+-for-space form encoding with regular percent-encoding in the same request, and the underlying parser handles that distinction correctly rather than requiring you to pick one convention for the whole URL. If a decoded parameter turns out to itself be a JSON-encoded object — common in analytics and tracking URLs — that value is one click away from being copied straight into a formatter.

Fully Decoding a URL That's Been Encoded Twice

Double-encoding is a specific, recognizable failure mode: a value gets percent-encoded once, then passed through a second system that encodes it again, turning the literal % characters from the first pass into %25. The telltale sign is a decoded result that still has % sequences sitting in it — a single decode only ever undoes one layer. Fully Decode keeps applying the same decode step, checking after each pass whether anything actually changed, and stops the moment it doesn't — so a value encoded once decodes once, a value encoded three times decodes three times, and you never have to manually count how many layers deep it went.

Unwinding a Tracking Link That Went Through Three Redirects

A URL copied from a marketing email or a shared tracking link has usually passed through several redirect services by the time it lands in your clipboard, and each hop has a habit of encoding whatever it received again rather than checking if it already was — that's how a URL ends up with %2520 where a single space should be. Fully Decode resolves the whole chain in one step instead of manually decoding and re-pasting until it stops changing, and the breakdown underneath shows exactly which parameter carried the actual destination once everything is unwound.

The reverse direction shows up just as often: encoding a title, a search term, or a return path with Component encoding before it goes into a query string being built by hand, so a stray & or # inside the value doesn't silently truncate the rest of the URL. And when an API integration isn't behaving as expected, decoding the raw request URL and checking the breakdown for the exact parameter in question — or diffing an expected URL against what was actually generated in the Text Diff Checker — usually finds the mismatch faster than reading two walls of percent signs side by side.

Frequently Asked Questions