URL Encoder/Decoder

The Science and History of Percent-Encoding

Percent-encoding emerged from a fundamental constraint of the early internet: the ASCII limitation. When Tim Berners-Lee designed the URL syntax in 1994, the Uniform Resource Locator specification (RFC 1738) restricted web addresses to a small subset of ASCII characters. This made sense for the predominantly English-language internet of the early 1990s, but it meant that any character outside this safe set—including spaces, punctuation, and the entirety of non-Latin scripts—needed a representation mechanism. The solution was elegantly simple: represent each unsafe byte as a percent sign followed by its two-digit hexadecimal value. A space (byte value 32, hex 20) becomes %20, a question mark (byte value 63, hex 3F) becomes %3F. This scheme could represent any byte value from 00 to FF, making it capable of encoding any character in any character set. The introduction of UTF-8 as the web's standard character encoding transformed percent-encoding from a simple byte-mapping scheme into a multi-byte encoding system. A single Chinese character might require three bytes in UTF-8, producing three consecutive percent-encoded triplets. The euro sign, for example, occupies three bytes (E2, 82, AC) and becomes the six-character sequence %E2%82%AC. This is why encoded URLs containing non-Latin text can appear dramatically longer than their decoded equivalents. RFC 3986, published in 2005, refined the original URL specification and formalized the modern rules for percent-encoding. It established the concept of reserved and unreserved character sets, clarifying which characters serve as structural delimiters in URLs and which can appear literally. This distinction is why two encoding functions exist in JavaScript: encodeURI preserves structural characters for complete URLs, while encodeURIComponent encodes everything for safe embedding within URL components. The specification also introduced the principle of normalization, defining when two differently-encoded URLs should be considered equivalent.

Methodology

URL encoding replaces unsafe ASCII characters with a percent sign (%) followed by two hexadecimal digits representing the character's byte value. For example, a space becomes %20 (hex 20 = decimal 32), an ampersand becomes %26, and a plus sign becomes %2B. The encoding follows RFC 3986, which defines the set of unreserved characters that never need encoding: uppercase and lowercase letters (A-Z, a-z), digits (0-9), and four special characters (hyphen, period, underscore, tilde). This tool provides two encoding modes that map directly to JavaScript's native functions. Component mode uses encodeURIComponent(), which encodes every character except the unreserved set, making it ideal for query parameter values where characters like & and = must be escaped. Full URL mode uses encodeURI(), which additionally preserves URL structural characters such as : / ? # [ ] @ ! $ & ' ( ) * + , ; = so that a complete URL remains functional after encoding. For international characters and emoji, the tool first converts the text to its UTF-8 byte representation, then percent-encodes each byte individually. A single Unicode character like the euro sign may produce multiple percent-encoded triplets (%E2%82%AC) because UTF-8 uses variable-length encoding of one to four bytes per character.

Understanding Your Results

Use Component mode (encodeURIComponent) whenever you are encoding a value that will be placed after an equals sign in a query string. This ensures that characters like &, =, and # within your value do not accidentally break the URL structure. Use Full URL mode (encodeURI) when you have a complete URL and only want to encode spaces and non-ASCII characters while keeping the structural delimiters intact. If you see %25 in your output, this means the percent sign itself was encoded, which typically indicates double-encoding—the input was already percent-encoded before you processed it. Decoding such strings twice will recover the original text. This is one of the most common URL encoding errors in web applications and APIs. Decoding is useful for making URLs human-readable during debugging, analyzing server logs, or inspecting query parameters that contain encoded values. International domain names (IDN) use a different encoding called Punycode rather than percent-encoding, so domain names with non-Latin characters require separate handling. Always encode user-supplied input before inserting it into URLs to prevent injection attacks and ensure that special characters do not corrupt the URL structure.

Practical Examples

Search query parameter: encoding 'coffee & tea' in Component mode produces 'coffee%20%26%20tea', safely escaping both the spaces and the ampersand so the server receives the literal text. Form submission: a user enters 'price=50$' into a search field, which must be encoded as 'price%3D50%24' to prevent the equals sign from being interpreted as a key-value separator. API redirect URLs: when passing a callback URL like 'https://app.com/auth?token=abc' as a parameter to another URL, Component mode encodes the entire callback including its own query string, preventing structural conflicts. Multi-language content: encoding Japanese text like 'Tokyo' produces the UTF-8 byte sequences as percent triplets, ensuring the characters survive transmission through ASCII-only systems. Debug decoding: paste a full URL from server logs like 'search?q=hello%20world%26lang%3Den' and decode it to instantly see the original query 'hello world&lang=en' for quick troubleshooting.

Tips & Best Practices

Always use Component mode when encoding individual query parameter values. Full URL mode leaves structural characters like & and = unencoded, which will break your URL if those characters appear in the data itself rather than as delimiters. Avoid double-encoding by checking whether your input is already percent-encoded. If you see sequences like %20 or %26 in the input, decode first before re-encoding to prevent stacking (where %20 becomes %2520). When building URLs programmatically, encode each parameter value separately and then assemble the full URL. Never encode the entire URL string at once, as this will corrupt the structural characters that separate the scheme, host, path, and query components. For debugging API calls, paste the full encoded URL into decode mode to quickly read all parameter values in human-friendly form. This is especially helpful when troubleshooting webhook URLs or OAuth callback redirects that contain nested encoded values.

Common URL Encodings

Sources

• RFC 3986 – URI Generic Syntax
• MDN – encodeURIComponent