What is URL encoding?
URLs can only contain a limited set of characters defined by the RFC 3986 standard: letters (A–Z, a–z), digits (0–9), and the characters - _ . ~. Every other character must be percent-encoded — replaced with a % sign followed by two hexadecimal digits representing the character's UTF-8 byte value. A space becomes %20, an ampersand becomes %26, and a forward slash (when used as data rather than a path separator) becomes %2F.
This encoding exists because URLs were designed in an era when many systems could only reliably transmit ASCII text, and characters like spaces, angle brackets, and non-Latin characters needed a safe representation.
Two modes: full URL vs component encoding
The tool offers two encoding modes because the right mode depends on what you are encoding. Full URL encoding (encodeURI) preserves the structural characters of a URL — the colon after https, forward slashes in paths, the question mark before the query string, and the ampersands between parameters. It only encodes characters that are never valid anywhere in a URL. Use this when you have a complete URL with proper structure that just contains some unsafe characters.
Component encoding (encodeURIComponent) encodes everything that is not a letter, digit, or one of - _ . ~ — including forward slashes, colons, and ampersands. Use this when encoding a single value that will be placed inside a URL, such as a query parameter value, where slashes and ampersands would break the URL structure if left unencoded.
When you need URL encoding
Query parameter values that contain special characters must be encoded. If a user searches for "C++ programming" and you build a URL like /search?q=C++ programming, the + and space break the URL. The correctly encoded version is /search?q=C%2B%2B%20programming. Email addresses in mailto: links must have the @ encoded as %40 when used as a query parameter value. Non-ASCII characters in URLs — accented characters, emoji, CJK characters — must be percent-encoded because URLs are defined as ASCII strings.
Common encoding mistakes
Double-encoding is the most common mistake: encoding a string that is already encoded, turning %20 into %2520 (because % is encoded as %25). Always check whether a string is already encoded before encoding again. The decoder will reveal double-encoding immediately — if decoding produces a string that still contains percent-signs, it was double-encoded.
Encoding at the wrong level is another frequent error: encoding the entire URL instead of just a parameter value, which encodes the colons and slashes that give the URL its structure. Always encode individual values using component encoding, and only use full URL encoding on a complete URL that needs light sanitisation.
Decoding for debugging
When debugging API calls, webhook payloads, or redirect URLs, the encoded form is often unreadable. Paste the encoded string into the decoder to see the original values clearly. This is particularly useful for complex OAuth redirect URLs and JWT tokens passed as URL parameters.