URL encoder / decoder
Encode URLs and query parameters to percent encoding or decode them back to readable text. Instant results.
Ctrl + L clear | Ctrl + Shift + C copy output
What is URL encoding and why is it needed
URLs can only contain a limited set of characters from the ASCII character set. Letters, numbers, hyphens, underscores, periods, and tildes are safe. Everything else must be percent-encoded — replaced with a percent sign followed by two hexadecimal digits representing the character's ASCII code. A space becomes %20, an ampersand becomes %26, and a forward slash in a query parameter becomes %2F. Without this encoding, URLs containing special characters would be malformed and browsers or servers might misinterpret them.
Full URL mode vs Component mode
Full URL mode — equivalent to JavaScript's encodeURI — encodes a complete URL while preserving characters that have structural meaning in URL syntax. Slashes, question marks, hash signs, ampersands, and equals signs are left unencoded because they are needed to structure the URL itself. Use this when encoding an entire URL that already has its structure in place.
Component mode — equivalent to JavaScript's encodeURIComponent — encodes everything including structural characters. A forward slash becomes %2F, a question mark becomes %3F, and so on. Use this when encoding individual URL components like query parameter values, where the structural characters in the value must be encoded so they are not confused with URL delimiters. This is the most commonly needed mode for developers building API requests and form submissions.
Common URL encoding use cases
Search query parameters containing spaces and special characters must be URL encoded before being appended to a URL. A search for "café au lait" in a query string becomes caf%C3%A9%20au%20lait. Form data submitted via GET requests is URL-encoded automatically by the browser but developers working with APIs often need to encode values manually. Authentication tokens, redirect URLs passed as parameters, and file paths with spaces all require URL encoding.
Decoding URL-encoded strings
URL decoding converts percent-encoded sequences back to their original characters. Switch to Decode mode and paste any URL-encoded string. Both %20 space encoding and + space encoding (used in HTML form data) are handled correctly. This is useful when reading encoded URLs from server logs, debugging API requests, or when you receive encoded data and need to read its original content.
Frequently asked questions
Why do I see %C3%A9 instead of é in my URL?
Non-ASCII characters are encoded as their UTF-8 bytes, and é happens to be a two-byte character: 0xC3 0xA9, which percent-encodes as %C3%A9. Emoji go further — 😀 becomes four bytes, %F0%9F%98%80. Browsers usually hide this by displaying the decoded characters in the address bar while sending the encoded form over the wire, which is why a URL that looks clean on screen turns into percent soup when copied. Paste any such URL into Decode mode to read it back in human form.
What is the difference between encodeURI and encodeURIComponent?
They differ in what they leave alone. encodeURI (this tool's Full URL mode) treats the input as a complete URL and preserves structural characters — slashes, question marks, ampersands — so the URL keeps working as a URL. encodeURIComponent (Component mode) encodes those characters too, because inside a parameter value a slash or ampersand is data, not structure. The classic bug is using the wrong one: encode a redirect URL with encodeURI, and its own query string merges into the outer URL's parameters. When encoding a value to put after an equals sign, Component mode is almost always what you want.
Why does a space become %20 in a URL?
Spaces are not legal in URLs — early internet standards reserved them as delimiters — so the space is written as %20, its ASCII code 32 in hexadecimal. You will also meet the older convention of + for spaces, which comes from HTML form submissions (the application/x-www-form-urlencoded format). Both decode to a space, and this tool's decoder handles both, but when generating URLs yourself %20 is the safer choice since a literal plus sign in data is ambiguous under the + convention.
What happens if I encode a URL twice?
Each percent sign gets re-encoded as %25, so %20 becomes %2520 and the URL breaks — the server decodes once, finds "%2520", and renders a literal "%20" in the middle of your data. Double encoding is one of the most common URL bugs, typically caused by two layers of code each "helpfully" encoding the same value. If you see %25 sequences in a URL, that is the fingerprint: paste it into Decode mode twice to recover the original, and fix the pipeline so encoding happens exactly once.
What characters do not need to be URL encoded?
RFC 3986 defines the unreserved set that is always safe: the letters A–Z and a–z, digits 0–9, and exactly four symbols — hyphen, underscore, period and tilde. Everything else should be percent-encoded when it appears inside a URL component. This tiny safe set is why URL slugs are built from lowercase letters and hyphens, and why encoding tools exist at all: nearly every interesting character, from spaces to accents to emoji, falls outside it.