URL Encoder/Decoder
Percent-encoding replaces characters that have meaning in a URL with %XX escapes. encodeURIComponent escapes &, =, ? and / — correct for a single query value. encodeURI leaves them intact — correct for a whole URL. Using the wrong one is why query strings break when a value contains an ampersand.
Type or paste text, pick Encode or Decode, then Component or Full URL — the result updates live and never leaves your browser.
Component: escapes & = ? / and other reserved characters — use for a single value that will be inserted into a URL.
Component vs. Full URL: two different jobs
Both modes turn unsafe characters into %XX
percent-encoded bytes, but they disagree on which characters
count as "unsafe" — and that disagreement is the whole point.
Component mode uses the browser's encodeURIComponent/decodeURIComponent,
which escapes everything that isn't a plain letter, digit, or a
small set of safe punctuation — including structural URL
characters like &, =, ?, and /. That's correct when your text
is going to become one value inside a URL someone else
is building — a search term, a redirect target, a piece of JSON
in a query string — because those structural characters need to
be neutralized so they can't be mistaken for URL syntax. Full URL mode uses encodeURI/
decodeURI, which recognizes that & = ? / : @ # and friends are exactly what makes
a URL a URL, and leaves them alone — it only escapes characters
that are genuinely invalid in a URL, like spaces or raw Unicode.
That's correct when your text is already a complete link and you
just want it to be valid.
Worked example
Encoding https://example.com/search?q=a&b gives
two different, both-correct results depending on the mode:
-
Component →
https%3A%2F%2Fexample.com%2Fsearch%3Fq%3Da%26b— every structural character is escaped. Paste this into another URL as a single query value (e.g.?redirect=https%3A%2F%2F...) and it survives intact; paste it into a browser's address bar as-is and it's just a broken, unreadable string. -
Full URL →
https://example.com/search?q=a&b— completely unchanged, because every character already present is already valid inside a URI. Full URL mode only kicks in when there's something genuinely invalid to escape, like a space: encoding?q=hello worldproduces?q=hello%20worldin both modes, since a raw space is never valid in either.
The mistake to avoid: running a whole link through Component
mode. It will happily encode the :// and every &, turning a working link into a string that no
longer functions as a URL at all — that's exactly what Full URL
mode is for.
Frequently asked questions
When should I use Component mode instead of Full URL mode?
Use Component mode whenever the text you're encoding is going to become ONE PIECE of a URL — a query parameter value, a path segment — that will then be inserted into a bigger URL you're building. It escapes every character that has special meaning in a URL (including /, ?, &, and =), so a value like "a&b=c" can't accidentally break the URL structure it gets inserted into. Use Full URL mode when the text you're encoding is already a complete, standalone link and you just want to make it valid — for example, before printing it, storing it, or passing it to a function that expects a real URL. It leaves structural characters like :, /, ?, &, and = alone, since those are exactly what makes the string work as a link.
Why does decoding sometimes show an error instead of a result?
Percent-encoding has a strict format: a % must always be followed by exactly two hexadecimal digits (like %20 or %3F). If the text you're decoding has a stray % that isn't followed by two valid hex digits — often from double-encoding gone wrong, a truncated copy-paste, or text that was never percent-encoded to begin with — the browser's decodeURIComponent or decodeURI function throws a URIError rather than guessing. This tool catches that error and shows a plain-language message instead of a blank result or a browser console error.
If I decode with Full URL mode, will %26 and %3D always turn back into & and =?
Not necessarily, and this is intentional. Full URL mode's decode step deliberately leaves the percent-encoded form of structural characters (;, /, ?, :, @, &, =, +, $, #) untouched, because unescaping them could change what the URL means — turning one query parameter into what looks like two, for instance. Component mode's decode step has no such restriction and converts every valid percent-encoded sequence back to its character, structural or not, which is correct for decoding a single value rather than a whole link.
Is percent-encoding the same thing as Base64?
No — they solve different problems. Percent-encoding (what this tool does) escapes only the specific characters that are unsafe or meaningful inside a URL, leaving ordinary letters and digits untouched, so the result stays mostly readable. Base64 re-encodes every byte of the input into a completely different alphabet, producing output with no resemblance to the original — useful for embedding arbitrary binary data in text formats, but overkill (and wrong) for a URL query value.