URL Encode / Decode

Introduction

URL encoding, also known as percent-encoding, is a mechanism for encoding information in a Uniform Resource Identifier (URI) under RFC 3986. [rfc-3986] URLs can only be sent over the Internet using the ASCII character set, which means characters outside this set — as well as certain reserved ASCII characters — must be converted into a valid format. Understanding URL encoding is essential for web developers, API integrators, and anyone who works with web technologies.

Reserved characters have special meaning within URLs. The characters :, /, ?, #, [, ], @, !, $, &, ', (, ), *, +, ,, ;, =, and the space character must be encoded when they appear in URL components where they are not serving their reserved purpose. For example, an unencoded ampersand (&) in a query parameter value would be interpreted as a parameter separator rather than literal data.

URL encoding is used when building query strings for GET requests or REST APIs, submitting web form data via application/x-www-form-urlencoded, encoding file names containing special characters for download URLs, and debugging API calls by decoding percent-encoded strings back to readable text.

The principle behind percent-encoding is conceptually simple but has important nuances that affect web development. Each character in a URL is either unreserved (can be used literally), reserved (has special meaning in certain contexts), or unsafe (must always be encoded). Unreserved characters include A-Z, a-z, 0-9, hyphen, period, underscore, and tilde. Reserved characters like colon, slash, question mark, and hash are allowed in URLs but only when they serve their designated purpose — for example, a colon separates the scheme from the host in a URL, but a colon appearing in a path segment should be encoded as %3A.

Unicode and non-ASCII characters require a two-step encoding process that many developers find confusing. First, the character must be encoded as a sequence of bytes using UTF-8 (the standard character encoding for the web). Then, each byte that is not an unreserved character is percent-encoded individually. For example, the Euro sign (U+20AC) encodes to UTF-8 bytes E2, 82, AC, and then each byte is percent-encoded to %E2%82%AC. Emoji characters like the smiling face (U+1F600) encode to four UTF-8 bytes and thus become %F0%9F%98%80 — a 12-character encoded string for a single emoji.

Why URL Encoding Is Necessary

URLs have a restricted character set defined by RFC 3986. The specification defines which characters are allowed in each component of a URL and, critically, what happens when a character that is not allowed appears in the wrong place. Without proper encoding, a URL can be misinterpreted, truncate, or even introduce security vulnerabilities. Understanding why encoding is necessary helps developers write robust web applications that handle edge cases gracefully.

Reserved characters like :, /, ?, #, [, ], @, !, $, &, ', (, ), *, +, ,, ;, and = each have designated purposes within a URL structure. A colon separates the scheme from the authority component, a slash separates path segments, a question mark introduces the query string, and a hash marks the fragment identifier. When these characters appear as literal data rather than structural delimiters, they must be percent-encoded. For example, if a user searches for a product named "shoes & boots", the ampersand in the query parameter value must be encoded as %26. Without encoding, the server receives two separate parameters instead of one, producing incorrect search results or no results at all.

Unsafe characters such as space, double quote, angle brackets, curly braces, pipe, backslash, caret, and backtick cannot appear unencoded in any URL component. The space character is the most commonly mishandled — it appears naturally in user-generated content like search queries, product names, and document titles. An unencoded space in a URL causes the browser to treat the space as the end of the URL, truncating the request and producing a broken link. This is why search engines and e-commerce platforms always encode spaces in their URLs.

Missing or incorrect encoding leads to three main categories of problems. First, broken links and malformed requests: a URL containing an unencoded ampersand causes the query string to split into unintended parameters, altering the request the server receives. Second, security vulnerabilities: improper encoding of user-supplied data in URLs can enable cross-site scripting (XSS) attacks. If an attacker inserts JavaScript code into a URL parameter and the application reflects this value without encoding, the script may execute in the victim's browser. CRLF injection (inserting carriage return and line feed characters %0D%0A) can enable HTTP response splitting attacks that poison caches and hijack user sessions. Third, form submission errors: when JavaScript manually constructs URLs without encoding, form data containing special characters gets truncated or misinterpreted, causing silent data loss that is difficult to debug.

ASCII and Unicode in URLs

Percent encoding operates on individual bytes using the ASCII character set. Each character to be encoded is replaced by a percent sign (%) followed by its two-digit hexadecimal ASCII code. The space character has ASCII code 32, which is 0x20 in hexadecimal, so it encodes as %20. The exclamation mark (ASCII 33, 0x21) encodes as %21, and the double quote (ASCII 34, 0x22) encodes as %22. This direct byte-to-hex mapping makes percent encoding mechanically simple, but the complexity arises when characters fall outside the ASCII range.

The ASCII table maps each of the 128 characters (0x00 to 0x7F) to a single byte value. Control characters from 0x00 to 0x1F — including tab (0x09), line feed (0x0A), and carriage return (0x0D) — must always be encoded in URLs. Printable ASCII characters from 0x20 (space) to 0x7E (tilde) include letters, digits, punctuation, and symbols. Character 0x7F (DEL) must also be encoded. Characters above 0x7F are non-ASCII and require a multi-byte encoding scheme.

Internationalized domain names (IDNs) use a different encoding mechanism called Punycode. While the path and query components of a URL percent-encode non-ASCII bytes, domain names must use ASCII-compatible encoding (ACE) with the xn-- prefix under RFC 3492. For example, the Spanish word "españa" as a domain becomes "xn--espaa-rqa". The Cyrillic domain "россия.рф" becomes "xn--p1ai.xn--p1ai". This distinction is essential: percent-encoding applies to the path and query string, while Punycode applies to the hostname. Mixing them up produces URLs that are invalid in both schemes.

Non-ASCII characters in URLs follow a consistent two-step process: encode the character as a sequence of UTF-8 bytes, then percent-encode each byte individually. The Spanish letter ñ (U+00F1) has UTF-8 bytes C3 and B1, so it encodes as %C3%B1. The accented é (U+00E9) has UTF-8 bytes C3 and A9, encoding to %C3%A9. Characters from non-Latin scripts follow the same pattern: the Chinese character 中 (U+4E2D) has UTF-8 bytes E4, B8, AD, encoding to %E4%B8%AD. The Japanese character 日 (U+65E5) encodes as %E6%97%A5.

Browser auto-encoding behavior introduces another layer of complexity. When a user types or pastes a URL containing raw Unicode characters into the address bar, modern browsers like Chrome, Firefox, and Safari automatically percent-encode them before sending the request. [whatwg-url] However, the exact behavior varies across browsers and versions. Some browsers encode the path differently than the query string, some apply Unicode normalization form NFC while others preserve the original form, and some handle IDN homograph attacks by displaying Punycode rather than the native script. These inconsistencies have caused cross-browser compatibility bugs that are notoriously difficult to reproduce and fix.

How to Use

1. Type or paste the text you want to encode or decode.
2. Select the desired operation: Encode (text to URL-safe format) or Decode (encoded string back to plain text).
3. The result appears instantly, ready to copy and use.
4. Use the swap button to quickly move output back to input for iterative encoding.

Choose the Right Encoding Mode: This tool offers two modes: encodeURIComponent (encodes all special characters including those used in URL paths) and encodeURI (preserves characters needed for valid URL structure like slashes and colons). For query string parameters, always use encodeURIComponent-style encoding. For encoding an entire URL path segment, use encodeURI-style encoding to keep the URL structurally valid. The default mode in this calculator handles query parameter encoding, which is the most common use case.

Formulas and Calculations

Reference Tables

Common URL Encoding Mistakes and Fixes

One of the most common mistakes is determining whether a space should be encoded as %20 or +. In the query string portion of a URL (after the ? character), spaces can be encoded as either %20 or + according to the application/x-www-form-urlencoded convention, and most server-side frameworks accept both. However, in other URL components such as the path, spaces must be encoded as %20. This tool uses %20 by default, which works universally, and also decodes + characters as spaces for maximum compatibility.

Double encoding is a frequent source of bugs. If you encode a value that has already been percent-encoded, the percent signs in the existing encoding become %25, producing corrupted output. For example, "hello world" encoded once becomes "hello%20world". Encoding that result again produces "hello%2520world" — the %25 represents the encoded % character, followed by "20world". This tool helps diagnose double encoding by allowing step-by-step decoding. If a decoded result still contains percent signs followed by hex digits, it requires another pass of decoding.

Encoding vs escaping varies by context and is often confused. URL percent-encoding replaces unsafe bytes with %XX sequences. HTML escaping uses entities like & and < to represent reserved HTML characters. JSON escaping uses backslashes before special characters within string values. These are entirely different mechanisms serving different layers of the web stack. A common mistake is to URL-encode a value, then HTML-escape it, then JSON-encode it — by which point the original value is buried under three layers of transformation that are difficult to reverse.

The difference between encodeURI and encodeURIComponent in JavaScript is critical in practice. [mdn-encodeuricomponent] encodeURI preserves characters that are structurally valid in a complete URL (:, /, ?, #), making it suitable for encoding an entire existing URL. encodeURIComponent encodes all special characters except unreserved ones, making it appropriate for encoding individual parameter names and values. Using encodeURI on a query parameter value leaves special characters like & and = unencoded, which breaks the query string.

A real-world scenario: API authentication often uses HMAC signatures encoded as base64. Base64 output includes the + character. When this signed value is placed in a URL query string without proper encoding, the + is interpreted as a space by many server frameworks, causing authentication to fail. The fix is to always encode base64 signatures using encodeURIComponent, which converts + to %2B, or use URL-safe base64 encoding that replaces + with - and / with _.

Practical Tips

Encode Each Component Separately: Encode each parameter name and value separately before assembling the full query string.

Watch for Double Encoding: If a value has already been encoded, encoding it again produces a double-encoded result like %2526.

Use the Right Function for the Job: In JavaScript, encodeURIComponent() encodes all special characters and should be used for query string parameters. encodeURI() preserves URI structure (slashes, colons, hashes) and should be used for encoding entire URLs. This tool provides encodeURIComponent-equivalent behavior by default, which is appropriate for the most common use case of encoding parameter values. If you need to encode a full URL path segment, you may need to manually preserve certain characters.

Test Your Encoded URLs: After encoding a URL parameter, always test the complete URL by pasting it into a browser address bar and verifying it navigates correctly. Some web frameworks and servers handle encoding differently — what works for one backend may fail for another. Common issues include servers that expect + for spaces, or frameworks that double-decode values. Testing catches these edge cases before they affect production systems and frustrate users.

Use Browser Developer Tools to Inspect Encoded Requests: The Network tab in Chrome DevTools or Firefox Developer Tools shows the exact URL that was sent to the server. You can copy any request URL and paste it into this tool to verify the encoding. This is especially useful when debugging why a particular API call is failing — the encoded URL in the developer tools is the ground truth of what the browser actually transmitted.

Be Aware of Language-Specific Encoding Functions: Different programming languages have different encoding functions with subtle behavioral differences. Python provides urllib.parse.quote() and urllib.parse.quote_plus(), where quote_plus encodes spaces as +. PHP uses urlencode() (which encodes spaces as +) and rawurlencode() (which uses %20). Java's URLEncoder follows the application/x-www-form-urlencoded convention with + for spaces. When building cross-platform integrations, verify that both sides agree on the encoding convention, or standardize on %20 which works everywhere.

Limitations

• Follows RFC 3986 percent-encoding standard. Uses %20 for spaces; + is also treated as space during decoding.
• Non-ASCII and Unicode characters require UTF-8 encoding before percent-encoding.
• Character encoding differences between systems can produce different outputs.
• Uses encodeURIComponent-equivalent behavior.

Frequently Asked Questions

What is the difference between encodeURI and encodeURIComponent?

encodeURI preserves URI syntax characters; encodeURIComponent encodes everything except unreserved characters.

Can URL encoding prevent SQL injection?

No. URL encoding is a transport-layer concern, not a security measure. Use parameterized queries for security.

How do I handle Unicode characters like emoji in URLs?

Unicode is first encoded to UTF-8 bytes, then each byte is percent-encoded. For example, smiley face (U+1F600) becomes %F0%9F%98%80.

What is the maximum length of a URL?

No official limit in RFC 3986; practical limits are 2,000-8,000 characters depending on browser and server.

When should I use base64 encoding instead of URL encoding?

Base64 encoding is designed for encoding binary data into ASCII text for transmission, while URL encoding is designed for encoding special characters in URLs. Base64-encoded data is typically larger (33% overhead) and uses characters like +, /, and = that need further URL encoding when used in query parameters. For simple text values with special characters, URL encoding is more efficient. For binary data like images or files, base64 is more appropriate but should be used judiciously due to its size overhead.

How does URL encoding relate to HTML form submission?

When an HTML form is submitted with method GET, the browser automatically URL-encodes each form field name and value and assembles them into a query string. With method POST and enctype application/x-www-form-urlencoded, the same encoding is applied to the request body. Understanding this automatic encoding helps developers predict how their form data will arrive at the server and avoid common pitfalls such as hidden fields whose values contain characters that break the query string format.

Why do spaces in URLs become + or %20?

The + sign for spaces comes from the application/x-www-form-urlencoded MIME type used by HTML forms, where + was chosen for compactness. RFC 3986 percent-encoding uses %20 for spaces. Both are valid in the query string, but only %20 is valid in other URL components like the path. Most modern frameworks accept both, but %20 is the universal choice that works everywhere.

How do I encode email addresses in mailto: links?

In a mailto: link, the email address itself does not need encoding if it contains only standard characters. However, the subject, body, and other query parameters must be percent-encoded like any URL query string. Spaces in the subject line become %20, and special characters like & in the body must be encoded as %26. For example: mailto:user@example.com?subject=Hello%20World&body=Check%20this%20%26%20that.

What is the difference between URL encoding and HTML entities?

URL encoding (percent-encoding) is used to transmit special characters in URLs by converting bytes to %XX format. HTML entities like &amp; and &lt; are used to display reserved HTML characters in web pages without breaking the HTML parser. They operate at different layers: URL encoding affects how data travels over the network, while HTML entities affect how content renders in the browser. A value can be both URL-encoded and HTML-escaped if it passes through both layers.

How do I decode URLs in JavaScript?

JavaScript provides decodeURI() for decoding whole URIs and decodeURIComponent() for decoding individual components. decodeURIComponent is more commonly used and handles the full percent-encoding scheme, including decoding %20 to spaces and %26 to &. Always wrap decodeURIComponent in a try-catch block, as it throws a URIError if the encoded string contains malformed sequences like an incomplete %XX or a lone percent sign.

References

1. [1]RFC 3986 — Uniform Resource Identifier (URI): Generic Syntax
2. [2]MDN Web Docs. (n.d.). encodeURIComponent().
3. [3]WHATWG URL Living Standard. (n.d.). Retrieved from https://url.spec.whatwg.org/.