What is a URL Encoder/Decoder?
URL encoding (percent-encoding) replaces unsafe or reserved characters in a URL with a '%' followed by two hexadecimal digits — for example, a space becomes %20 and an ampersand becomes %26. Encoding makes URLs safe to transmit across the web; decoding reverses the process to reveal the original text.
Why URLs need encoding in the first place
URLs were designed to contain only a small, unambiguous set of ASCII characters. Anything outside that set — spaces, accented letters, emoji, control characters — has no guaranteed meaning in transit, and servers or browsers may mangle it. Percent-encoding converts each byte of the UTF-8 representation of those characters into a safe three-character sequence like %20 or %C3%A9, so the address survives email clients, chat apps, redirects and proxies intact.
Reserved characters are the second reason. Symbols like ?, &, = and # have structural jobs in a URL: ? starts the query string, & separates parameters, # begins the fragment. If one of those characters appears inside a parameter value — say a search for "salt & pepper" — it must be escaped to %26, or the server will parse your value as two separate parameters and return the wrong results.
Full URL vs component encoding
There is no single "encode a URL" operation — the correct behavior depends on what you are encoding. A whole URL must keep its structure: the :// in the scheme, the ? before the query and the & between parameters all need to stay literal. That is what the Full URL mode does, mirroring JavaScript's encodeURI(). Only genuinely unsafe characters like spaces and non-ASCII text are escaped.
A query parameter value is the opposite situation. When you encode one value that will be slotted into a larger URL, every reserved character inside it must be escaped — otherwise it collides with the URL's own syntax. The Component mode mirrors encodeURIComponent(), escaping everything except letters, digits and a handful of unreserved marks. Encoding each value separately and then assembling the URL is the only reliable workflow.
How percent-encoding works under the hood
Every percent sequence is one byte written as hexadecimal. The character é, for example, is two bytes in UTF-8 — C3 and A9 — so it encodes as %C3%A9. An emoji like 😀 is four UTF-8 bytes and becomes %F0%9F%98%80. Decoding reverses the process: collect the bytes, interpret them as UTF-8, and the original characters come back.
Not everything needs escaping. The URL specification defines an "unreserved" set — letters A–Z and a–z, digits 0–9, and the four marks - . _ ~ — that may appear literally anywhere in a URL. Encoders leave those characters alone and escape everything else. That is why "hello world" becomes hello%20world: only the space is unsafe. Understanding this one rule explains almost every encoded URL you will ever see: long runs of % sequences are simply non-ASCII text, while the readable remainder was already safe.
One subtlety worth knowing: the strict decode operation can fail. A truncated sequence like %2, invalid hex like %zz, or bytes that are not valid UTF-8 all raise errors in most programming languages. This tool catches those cases and shows a best-effort decode with a warning, so you can still see the recoverable parts of a damaged URL.
The double-encoding trap
The most common percent-encoding bug is encoding something twice. A value that goes through a form library, then a redirect helper, then a manual encodeURIComponent() can end up as %2520 — the % of the original %20 was itself encoded to %25. Users see literal "%20" in page titles and APIs reject the mangled parameter. If a decoded result still contains percent sequences, run it through the decoder again; if you spot %25 anywhere, suspect a double encode somewhere upstream.
The reverse mistake is forgetting that + means space only in query strings, not in path segments. A path like /files/my+report.pdf refers to a file literally named "my+report.pdf". Use %20 for spaces everywhere and you will never hit this ambiguity.
Why use our url encoder/decoder?
Two correct modes
Encode a whole URL or a single query value, exactly the way the URL spec intends — no broken :// or escaped ? by accident.
Built-in cheat sheet
The nine most common character encodings — space, &, =, /, ?, #, +, % and é — are one click away in the reference strip.
Instant both ways
Encode and decode as you type, with a Swap button that flips direction for quick round-trip verification.
Completely private
Tracking URLs, tokens and redirect parameters you decode never leave your browser — all conversion happens locally.
URL Encoder/Decoder examples
| Input | Mode | Output |
|---|---|---|
| hello world | Encode · Component | hello%20world |
| https://example.com/search?q=café menu | Encode · Full URL | https://example.com/search?q=caf%C3%A9%20menu |
| %3Cdiv%3E | Decode | <div> |
| a=b&c=d | Encode · Component | a%3Db%26c%3Dd |
| %2520 | Decode (twice-encoded) | %20 → space |
How to use this url encoder/decoder
Paste your URL or text into the input field.
Choose Encode or Decode with the direction control.
Pick "Full URL" to preserve URL structure, or "Component" for a single query value.
Copy the result — or hit Swap to send the output back through the other direction.
Common mistakes to avoid
Encoding a whole URL with component mode. — Component mode escapes the ://, ? and & that give the URL its structure, breaking it. Use Full URL mode for complete addresses.
Double-encoding values. — If you see %2520, the value was encoded twice — %20 became %2520. Decode once to check how many layers were applied.
Using + for spaces in path segments. — + only means space inside query strings; in paths it is a literal plus sign. Paths always need %20.
Encoding after concatenating raw values. — Encode each parameter value first, then assemble the URL. Encoding the finished string escapes the separators too.