URL Encoding Explained: Encode and Decode URLs Correctly

Published on May 8, 2026

Every time you click a link, submit a form, or make an API request, URL encoding is working behind the scenes to ensure your data arrives intact. Also known as percent encoding, URL encoding is the mechanism that translates characters that are not allowed in URLs into a safe, standardized format. Without it, spaces, ampersands, plus signs, and non-ASCII characters would break URLs in unpredictable ways. In this guide, we will explain what URL encoding is, when you need it, the most common mistakes developers make, and the critical difference between JavaScript's encodeURI and encodeURIComponent functions.

What is URL Encoding (Percent Encoding)?

URL encoding is a method for converting characters into a format that can be transmitted safely over the internet. In a URL, only a limited set of characters are allowed without special handling. These allowed characters include uppercase and lowercase letters, digits, and a few special characters such as hyphen, underscore, period, and tilde. All other characters must be encoded.

The encoding process works by replacing each unsafe character with a percent sign followed by its two-digit hexadecimal ASCII code. For example, a space becomes %20, because the ASCII value of a space is 32 in decimal, which is 20 in hexadecimal. An exclamation mark becomes %21, and a pound sign becomes %23. This is why the scheme is often called percent encoding.

Consider a search query like "coffee & tea". If you tried to include this directly in a URL without encoding, the ampersand would be interpreted as a query parameter separator, breaking the URL. The correctly encoded version becomes coffee%20%26%20tea, where %20 represents each space and %26 represents the ampersand. The resulting URL looks like this: https://example.com/search?q=coffee%20%26%20tea. When the server receives this URL, it decodes the percent-encoded sequences back to their original characters and processes the query correctly.

URL encoding is defined by RFC 3986, which is the standard governing URI syntax. The specification divides characters into three categories: unreserved characters that can be used as-is, reserved characters that have special meaning and must be encoded in certain contexts, and all other characters that must always be encoded. Let us look at these categories more closely. Unreserved characters include A through Z, a through z, 0 through 9, hyphen, period, underscore, and tilde. Reserved characters include colon, slash, question mark, hash, square brackets, at sign, exclamation mark, dollar sign, ampersand, single quote, parentheses, asterisk, plus sign, comma, and semicolon. Reserved characters only need encoding when they are used for purposes other than their reserved meaning.

Common Characters and Their Encoded Forms

Here is a reference table of frequently encoded characters that you will encounter in everyday web development. Bookmark this section for quick lookup when debugging URL issues.

When Do You Need URL Encoding?

URL encoding is required in many common web development scenarios. Here are the situations where you will most often need to reach for an encoding tool.

Query parameters with special characters. Any time you include user-generated content in a URL query string, you must encode it. Search queries, form submissions, and filter parameters can all contain spaces, ampersands, question marks, and other characters that have special meaning in URLs. Encoding these values prevents broken links and incorrect parameter parsing. For example, if a user searches for "cars & trucks", the ampersand must be encoded as %26 to avoid being interpreted as a parameter separator.

Non-ASCII characters in URLs. Modern URLs can contain Unicode characters, but they must be encoded first. A query containing characters like or accented letters must be percent-encoded to their UTF-8 byte sequences. For example, the character becomes %C3%A9 in its percent-encoded form. While modern browsers handle this encoding automatically when you type in the address bar, when you are constructing URLs programmatically, you must encode non-ASCII characters yourself.

Form GET submissions. When an HTML form is submitted using the GET method, the browser automatically encodes the form data and appends it to the action URL as a query string. The default encoding for form data is application/x-www-form-urlencoded, which follows the same percent-encoding rules but uses the plus sign as a shorthand for spaces. This is why form data often contains plus signs where spaces would appear. Server-side frameworks decode this automatically, but if you are constructing form submissions manually, you need to be aware of this convention.

API requests. REST APIs often require encoded parameters in URLs, especially for filtering, searching, or including complex data in requests. If you are building an API client, you should always encode query parameter values using encodeURIComponent or your language's equivalent function. Failure to do so can result in malformed requests and API errors. The URL Encoder tool lets you quickly check that your URL parameters are correctly encoded before sending a request.

Fragment identifiers. The hash fragment of a URL, used for client-side routing and anchor links, can contain special characters that require encoding. While modern browsers handle much of this automatically, when working with single-page applications and hash-based routing, encoding fragment values correctly is important for reliable navigation.

URL Encoding in Different Programming Languages

Every major programming language provides built-in functions for URL encoding. While the underlying concept is the same across all languages, the function names and subtle behaviors differ. Here is how to handle URL encoding in the most common languages.

JavaScript. As discussed earlier, JavaScript provides encodeURI() and encodeURIComponent(). Use encodeURIComponent() for encoding query parameter values and path segments. For decoding, use decodeURIComponent(). Node.js also provides the querystring module for encoding entire query string objects: querystring.stringify({q: "coffee & tea"}) produces q=coffee%20%26%20tea.

Python. Python's urllib.parse module provides quote() and quote_plus() for encoding. Use quote() for general percent encoding and quote_plus() for form-urlencoded data where spaces become plus signs. For encoding an entire query string, use urlencode(): urllib.parse.urlencode({'q': 'coffee & tea'}). Decoding functions are unquote() and unquote_plus().

PHP. PHP uses urlencode() and rawurlencode(). The difference is that urlencode() converts spaces to plus signs (as in form data), while rawurlencode() converts spaces to %20 (as per RFC 3986). For decoding, use urldecode() and rawurldecode() respectively. When building URLs dynamically, rawurlencode() is generally the safer option because it follows the RFC standard.

Java. Java provides URLEncoder.encode() and URLDecoder.decode(). Note that URLEncoder.encode() converts spaces to plus signs, following the application/x-www-form-urlencoded convention. For strict RFC 3986 encoding, you may need to replace plus signs with %20 after encoding. Java's URI class can also handle encoding when constructed with the appropriate parameters.

Ruby. Ruby's ERB::Util.url_encode() and the CGI module provide URL encoding. The Addressable::URI gem offers more comprehensive URI handling that follows RFC 3986 strictly. For simple encoding needs, URI.encode_www_form_component() handles query parameter values correctly.

C# (.NET). .NET provides Uri.EscapeDataString() for encoding individual components and Uri.EscapeUriString() for encoding a full URI. EscapeDataString() is the equivalent of JavaScript's encodeURIComponent(). For decoding, use Uri.UnescapeDataString().

Security Implications of Improper URL Encoding

Failing to encode URLs correctly is not just a reliability issue; it can also introduce security vulnerabilities. Understanding these risks is essential for building secure web applications.

Parameter pollution attacks. If user input is not properly encoded before being included in a URL, an attacker can inject additional query parameters. For example, if a search page constructs a URL like /search?q=userInput without encoding, and a user enters shoes&admin=true, the resulting URL would be /search?q=shoes&admin=true. The server might interpret admin=true as a separate parameter, potentially granting unauthorized access if the application processes unexpected parameters. Proper encoding would convert the ampersand to %26, preserving it as part of the q value.

Open redirect vulnerabilities. When URLs accept a redirect target as a parameter, failure to validate and encode the value can allow attackers to redirect users to malicious sites. For example, /redirect?url=http://evil.com could be exploited if the application does not validate the domain. While encoding alone does not fix this (the encoded URL still redirects), proper encoding combined with a strict allowlist of permitted domains prevents attackers from manipulating the redirect path using special characters like @ or # to confuse the URL parser.

Cross-site scripting (XSS) via URL components. If your application reads values from a URL and displays them on the page without sanitization, an attacker can craft a malicious URL containing JavaScript code. For example, /profile?name=<script>alert('xss')</script>. URL encoding does not prevent this; the browser decodes the URL before the page processes it. The fix is to always HTML-encode values before inserting them into the page, regardless of whether they came from a URL, a database, or any other source.

Server-side request forgery (SSRF) protection. When your server makes HTTP requests based on user-supplied URLs, improper encoding can allow attackers to access internal services. For example, if an attacker provides http://localhost:8080/admin as a URL parameter, and your server fetches that URL without validation, they could access internal administration interfaces. Always validate the scheme and hostname before making requests, even after URL encoding is applied.

Double decoding hazards. If your application decodes URL parameters twice, once at the web server level and again in application code, an attacker can exploit this to bypass input filters. For example, if you have a filter that blocks URLs containing %2F (encoded slash), an attacker could send %252F (percent-encoded percent sign followed by 2F). The first decode turns %252F into %2F, which passes the filter, and the second decode turns it into /, potentially allowing path traversal. Avoid decoding input that has already been decoded by your web framework.

Common URL Encoding Mistakes to Avoid

Even experienced developers make these mistakes. Here is what to watch out for.

Double encoding. This happens when you encode a value that has already been encoded. For example, if you encode a space as %20 and then run the entire string through an encoder again, the percent sign itself gets encoded to %25, turning %20 into %2520. The server then decodes this as %20 instead of a space, causing unexpected behavior. Always track whether your data has already been encoded and avoid encoding the same value twice.

Forgetting to encode query parameter values. This is one of the most common bugs in web applications. If you construct a URL by string concatenation without encoding the values, any special characters in the values will break the URL structure. Always encode individual parameter values, not the entire URL. Using the URL Encoder tool can help you verify your parameter encoding is correct.

Encoding the entire URL. If you pass a full URL like https://example.com/path?query=value through a URL encoder, the slashes and colons in the protocol portion get encoded, producing https%3A%2F%2Fexample.com, which is not a valid URL at all. Only encode individual components, not the whole URL string.

Confusing URL encoding with HTML encoding. URL encoding and HTML entity encoding serve different purposes. URL encoding converts unsafe characters for use in URLs, while HTML encoding converts characters like < and > for safe display in HTML documents. Applying the wrong type of encoding can lead to security vulnerabilities and broken output. Each context has its own encoding rules, and they are not interchangeable.

encodeURI vs encodeURIComponent: What's the Difference?

JavaScript provides two built-in functions for URL encoding, and understanding the difference between them is essential for writing correct code.

encodeURI is designed for encoding a complete URI. It preserves characters that are part of the URI structure, such as colons, slashes, question marks, and hash symbols. This means you can pass a full URL like https://example.com/path?name=value through encodeURI, and the structural characters will remain intact while unsafe characters are encoded. Use encodeURI when you have a complete URL that needs cleaning up, such as one that contains spaces or Unicode characters.

encodeURIComponent is designed for encoding a single component of a URI, such as a query parameter value or a path segment. It encodes all characters that have special meaning in URLs, including colons, slashes, question marks, and ampersands. This is the function you should use for encoding query parameter values. For example, encodeURIComponent("coffee & tea") returns coffee%20%26%20tea. If you used encodeURI instead, the ampersand would not be encoded and would break the query string.

The rule of thumb is simple: use encodeURIComponent for encoding parameter values and path segments, and use encodeURI only when you need to clean up a full, already-constructed URL. When in doubt, encodeURIComponent is almost always the safer choice because it is more aggressive in its encoding. Most URL encoding bugs in web applications stem from using encodeURI where encodeURIComponent was needed.

Frequently Asked Questions About URL Encoding

Why does my URL show %20 instead of a space?

URLs cannot contain literal space characters. The %20 is the percent-encoded form of a space, as defined by RFC 3986. Some older systems may also encode spaces as "+" (plus sign), which is the application/x-www-form-urlencoded convention used in HTML forms. Modern URLs should use %20 for spaces in most contexts, though the "+" form is still accepted in query strings for compatibility reasons.

What is the difference between %20 and + in URLs?

Both represent a space, but they are used in different contexts. %20 is the standard percent-encoding for a space per RFC 3986 and works in any URL segment. The "+" sign is a shorthand that only has special meaning in the query string portion of a URL, specifically for application/x-www-form-urlencoded form data. In the path portion of a URL, "+" is treated as a literal plus sign, not a space. When in doubt, use %20 for maximum compatibility.

How do I encode a URL in a query parameter?

If you need to include a full URL as a query parameter value, you must encode it to prevent the URL's special characters from interfering with your query string. For example: https://example.com/redirect?target=https%3A%2F%2Fexample.com%2Fpage. Use your language's URL encoding function on the inner URL before appending it as a parameter value. This is commonly needed for OAuth flows, redirect URLs, and webhook callbacks.

Are modern browsers smart enough to fix my encoding mistakes?

Modern browsers are quite forgiving. If you type a URL with spaces or Unicode characters into the address bar, the browser automatically encodes them. However, this only applies to user-entered URLs in the address bar. When constructing URLs programmatically via JavaScript (fetch, XMLHttpRequest, window.location), the browser does not fix your encoding mistakes. API calls, AJAX requests, and dynamically generated links will break if you do not encode them correctly. Never rely on the browser to fix your encoding.

URL encoding is a small but critical piece of web development knowledge. Getting it right ensures your links work, your API requests succeed, and your form data arrives correctly. Bookmark a reliable URL Encoder for those moments when you need to quickly encode or decode a URL string.

Related Tools

These complementary tools will help you with encoding, formatting, and text processing in your development work.

• URL Encoder - Encode and decode URLs with proper percent-encoding for safe transmission.
• JSON Formatter - Format, validate, and beautify JSON data for debugging and API development.
• Base64 Encoder - Encode and decode text or binary data to and from Base64 format.
• Word Counter - Count words, characters, and lines in any text content.