Percent-encode text for safe use in a URL, or decode an encoded URL back to readable text. Two modes, because encoding a whole URL and encoding one parameter are different jobs - and using the wrong one is the most common way URLs break.
URL Encoder & Decoder
LiveParameter vs. whole URL - the distinction that matters
These two modes exist because URLs contain characters that are sometimes structure and sometimes data. A / separates path segments; a ? starts the query string; an & separates parameters. Whether those characters should be encoded depends entirely on which role they're playing.
| Mode | Encodes | Use it for |
|---|---|---|
| Parameter | Everything unsafe, including / ? & = # : | A single value going inside a URL - a search term, a redirect target, a filename |
| Whole URL | Only spaces and genuinely illegal characters - leaves the structure intact | Cleaning up a complete URL that already has its own path and query string |
Say you're building a redirect: site.com/go?to= plus other.com/a?b=1. In Parameter mode the target becomes other.com%2Fa%3Fb%3D1 - one clean value, and the redirect works. In Whole URL mode its ? and = survive, the server reads them as part of your query string, and the redirect silently loses everything after the ?.
Step-by-step guide
- Decide what you're encoding. One value going inside a URL? Parameter mode. An entire URL you want to tidy? Whole URL mode. When unsure, Parameter is the safer default - over-encoding a value is recoverable, under-encoding it is not.
- Encode the value, then assemble the URL - never the other way round. Encoding after assembly destroys the structure you just built.
- Decode once, not repeatedly. If output still contains
%25, the input was double-encoded and needs another pass - but decoding beyond that will start corrupting literal percent signs. - Test the result in a browser before shipping it into an email campaign or an ad. A malformed URL that looks fine in a text editor is a common and expensive mistake.
Common mistakes
% into %25, so %20 becomes %2520. The link still looks plausible and fails on arrival. If your input already contains % followed by two hex digits, decode before you encode.+ with a space. In the query string of an HTML form submission, + historically means a space. In a path segment it means a literal plus sign. Percent-encoding a space as %20 is unambiguous in both places, which is why it's the safer choice.# is never sent to the server - it's handled by the browser. Encoding a # inside a parameter value is essential, or the rest of your value simply disappears before the request is made.Frequently asked questions
Why do spaces become %20?
URLs can't contain literal spaces, so every unsafe character is replaced by a percent sign followed by its hexadecimal byte value. A space is byte 0x20, hence %20. The same scheme covers every other character that would otherwise be ambiguous or illegal.
Does encoding a URL affect SEO?
Search engines handle percent-encoded URLs without difficulty, so correctness isn't the concern. Readability is: a URL full of %D8%A7 sequences is harder for people to scan, share, and trust. For page URLs, prefer plain lowercase ASCII words with hyphens. Reserve encoding for parameter values, where nobody reads it anyway.
What about non-English characters in URLs?
They're encoded as their UTF-8 bytes, so a single Arabic or Chinese character typically becomes three percent-escapes. Browsers usually display the readable form in the address bar while sending the encoded version. That's normal, and the encoded form is what you should use when writing the link by hand.
Is anything I paste here uploaded?
No. Both encoding and decoding happen in your browser using built-in JavaScript functions. There is no server request and nothing is stored, which matters if the URL you're working with contains a token or a session identifier.
My decoded output still has percent signs. Why?
The input was probably double-encoded - run it through decode once more. If percent signs remain after a second pass, they're likely literal characters that were correctly encoded as %25, and decoding further would corrupt them.
Should I encode the whole URL before putting it in an email?
No - use Whole URL mode at most, which only cleans up spaces and illegal characters. Running a complete URL through Parameter mode encodes its own :// and ?, producing a string that is no longer a working link at all.
Related tools
See the full list of Generators, or try: