Free Online URL Encoder & Decoder

URL Encoding Standards (RFC 3986)

The authoritative specification for URL encoding is RFC 3986 — "Uniform Resource Identifier (URI): Generic Syntax" — published by the Internet Engineering Task Force (IETF) in January 2005. This document superseded the earlier RFC 2396 and defines the rules that every web browser, HTTP library, and web server follows when parsing and constructing URLs. Understanding RFC 3986 is essential for any developer who builds, consumes, or debugs web APIs.

Reserved Characters

RFC 3986 defines a set of reserved characters that have special meaning within a URI's structure. These characters delimit the components of a URL — the scheme, authority, path, query, and fragment. If you need to include a reserved character as literal data (rather than as a delimiter), it must be percent-encoded.

The reserved character set is: : / ? # [ ] @ ! $ & ' ( ) * + , ; =

For example, the ? character separates the path from the query string. If a query parameter value itself contains a ?, it must be encoded as %3F to prevent the parser from misinterpreting it as a second query string delimiter.

Unreserved Characters

Unreserved characters are safe to include in any component of a URI without encoding. They will never be misinterpreted by a compliant parser. The unreserved set consists of:

• Uppercase letters: A–Z
• Lowercase letters: a–z
• Digits: 0–9
• Four special characters: - . _ ~ (hyphen, period, underscore, tilde)

Any character not in the unreserved or reserved sets — including spaces, non-ASCII characters (UTF-8 multi-byte sequences), and control characters — must be percent-encoded.

Percent-Encoding Rules

The encoding process is straightforward: each byte of the character's UTF-8 representation is expressed as a percent sign (%) followed by exactly two uppercase hexadecimal digits. For single-byte ASCII characters, this produces familiar forms like %20 for space (byte 0x20) and %26 for ampersand (byte 0x26). For multi-byte UTF-8 characters, each byte is encoded separately — for example, the Euro sign (€, U+20AC) is encoded as %E2%82%AC (three bytes in UTF-8). RFC 3986 mandates that hexadecimal digits should be uppercase (%2F, not %2f), although most decoders accept both forms.

Common URL Encoding Issues & Troubleshooting

Even experienced developers run into URL encoding pitfalls. Here are the most common issues and how to resolve them:

Double Encoding

Double encoding occurs when an already-encoded string is encoded again. For example, a space that was correctly encoded as %20 gets re-encoded to %2520 (because the % itself becomes %25). This is one of the most frequent bugs in web applications and typically happens when multiple layers of code — such as a client library, a framework middleware, and a server-side router — each apply their own encoding pass. The fix is simple: encode once, at the point of construction, and ensure that downstream code does not re-encode.

Space: + vs. %20

The + sign as a space replacement is a legacy of the application/x-www-form-urlencoded content type, originally defined for HTML form submissions. In this format, spaces in form data are replaced with +. However, outside of the query string in a form-encoded context, + is not interpreted as a space — it is a literal plus sign. The universally safe choice is %20, which is valid in all parts of a URL (path, query, fragment). JavaScript's encodeURIComponent() always produces %20, not +.

Encoding Query Parameters vs. Path Segments

A common mistake is using the same encoding function for both path segments and query parameter values. While encodeURIComponent() works for both, the context matters. Path segments are separated by /, which must not be encoded within the path. Query parameter values sit after the ? and are separated by &, both of which must be encoded if they appear as literal data within a value. When building URLs programmatically, use the URL and URLSearchParams APIs in JavaScript — they handle the context-specific encoding automatically.

Unicode in URLs (IRI / IDN)

Internationalized Resource Identifiers (IRIs), defined in RFC 3987, extend URIs to support Unicode characters directly. Modern browsers display IRIs in the address bar (e.g., https://example.com/日本語), but the underlying HTTP request uses the percent-encoded form (https://example.com/%E6%97%A5%E6%9C%AC%E8%AA%9E). Similarly, Internationalized Domain Names (IDNs) use Punycode to represent non-ASCII domain names (e.g., münchen.de becomes xn--mnchen-3ya.de). When working with international URLs, always encode the path and query using UTF-8 percent-encoding, and use Punycode for domain names to ensure compatibility across all browsers and servers.

URL Encoding in APIs & Web Development

Proper URL encoding is the glue that holds modern web architecture together. From REST APIs to OAuth flows, almost every web interaction depends on correctly encoded URLs. Here are the most critical scenarios:

REST API Query Parameters

When calling a REST API, query parameters are appended to the URL after a ? and separated by &. Each parameter key and value must be individually encoded using encodeURIComponent(). For example, searching for the phrase "price > 100 & currency = USD" requires encoding to q=price%20%3E%20100%20%26%20currency%20%3D%20USD. Failing to encode will cause the API to misinterpret the & as a parameter separator and the = as a key-value delimiter, resulting in garbled data. Our URL encoder tool is perfect for testing these encodings before embedding them in your code.

Form Data Submission

HTML forms submitted via GET or POST with the application/x-www-form-urlencoded content type automatically encode form field values. However, when constructing form data programmatically (e.g., using fetch() or XMLHttpRequest), you are responsible for encoding the values yourself. The URLSearchParams API in JavaScript handles this elegantly:

const params = new URLSearchParams();
params.append('name', 'John Doe & Sons');
params.append('city', 'New York');
fetch('/api/search?' + params.toString());

Redirects & Callback URLs

Redirect URLs frequently appear in authentication flows, payment gateways, and single sign-on (SSO) systems. When passing a redirect URL as a query parameter (e.g., ?redirect_uri=https://myapp.com/callback?token=abc), the entire callback URL must be encoded so that its internal ?, =, and & characters are not parsed as part of the outer URL structure. Incorrectly encoded redirect URIs are one of the most common causes of OAuth authentication failures.

OAuth Callbacks & Webhook URLs

OAuth 2.0 requires that the redirect_uri parameter exactly matches the value registered with the authorisation server — including encoding. A mismatch of even a single encoded vs. unencoded character (e.g., %2F vs. /) will cause the authorisation server to reject the request with an "invalid redirect_uri" error. Similarly, webhook URLs registered with third-party services (Stripe, GitHub, Twilio) must be properly encoded, especially when they contain query parameters for routing or authentication tokens.

Debugging Tip: Use the Browser Console

When debugging URL encoding issues, the browser's developer console is your best friend. Use encodeURIComponent() and decodeURIComponent() directly in the console to test individual values. For full URLs, the URL constructor parses and normalises a URL string, giving you access to individual components (.pathname, .searchParams, .hash) with encoding handled automatically.