URL Encode & Decode: Complete Guide

```html URL Encoding and Decoding: A Complete Guide

URL encoding (also called percent-encoding) converts special characters into a format that can be safely transmitted over the internet. When you need to include spaces, symbols, or non-ASCII characters in URLs, query strings, or API parameters, encoding ensures those characters don't break your request or cause unexpected behavior. URL Encode & Decode provides a free, instant way to handle this conversion without uploading data or creating an account.

Understanding URL Encoding: The Format and Rules

URL encoding uses a percent sign (%) followed by two hexadecimal digits to represent special characters. This format was defined in RFC 3986, the standard that governs URI syntax. Every character in a URL either has a special meaning, is safe to use as-is, or must be percent-encoded before transmission.

The original URL specification (RFC 1738) divided characters into three categories:

• Unreserved characters: These are safe to use directly without encoding. They include uppercase letters (A-Z), lowercase letters (a-z), digits (0-9), hyphen (-), underscore (_), period (.), and tilde (~). These 66 characters never need encoding in URLs.
• Reserved characters: These have special meaning in URLs and query strings. They include ! # $ & ' ( ) * + , / : ; = ? @ [ ]. Depending on context, you may need to encode these or use them for their intended purpose. For example, ? separates the path from the query string, and & separates individual parameters within a query string.
• Unsafe characters: These include spaces, quotation marks, control characters, and any characters outside the ASCII range. These must always be percent-encoded because they can cause parsing errors or security vulnerabilities.

The encoding process replaces each special character with its byte value in ASCII, expressed as %XX where XX is the two-digit hexadecimal representation. A space (ASCII 32) becomes %20. An ampersand (ASCII 38) becomes %26. A plus sign (ASCII 43) becomes %2B. This systematic approach ensures every character can be represented unambiguously.

Verified Worked Example

Let's walk through encoding the string "a b&c" step by step. This example demonstrates three common scenarios: a space, an ampersand, and the letter "c".

Input:

a b&c

Output:

a%20b%26c

Breaking this down: the space between "a" and "b" (ASCII 32) becomes %20. The ampersand between "b" and "c" (ASCII 38) becomes %26. The letter "c" remains unchanged because it's an unreserved character. When decoding, the reverse process applies: %20 becomes a space, %26 becomes an ampersand, and the letters a, b, and c pass through unchanged.

Common Mistakes and Errors

Mistake 1: Double Encoding

One of the most frequent errors is encoding a string that has already been encoded. If you encode "hello%20world", you get "hello%2520world" because the percent sign in %20 itself gets encoded as %25. This creates corrupted data that's difficult to debug. Fix: Always check whether your input has already been encoded before processing. If you see % followed by two characters, the string may already be encoded.

Mistake 2: Encoding Already-Safe Characters

Some developers encode characters that don't need encoding, like letters or digits. While encoding safe characters technically produces valid output (a becomes %61), it creates unnecessarily long strings and can cause comparison failures when the encoded version doesn't match the original. Fix: Only encode characters that genuinely need it: spaces, symbols with special meaning in query strings, and non-ASCII characters.

Mistake 3: Confusing URL Encoding with HTML Encoding

URL encoding uses %XX format, while HTML encoding uses &name; or &#nnn; format. A space in a URL query string is %20, but that same space in HTML content is  . Confusing these two systems leads to visible text like "%20" appearing on web pages instead of actual spaces. Fix: Use URL encoding for URL components and query parameters. Use HTML encoding only for content that will be rendered in a browser.

Mistake 4: Forgetting to Encode Before Sending to APIs

When building API requests, many developers forget that query parameter values must be encoded. A search for "San Francisco & Oakland" sent as a raw query parameter would break the URL structure because the ampersand would be interpreted as a parameter separator. Fix: Always encode query parameter values before appending them to URLs. Most programming languages provide built-in functions like encodeURIComponent() in JavaScript or urllib.parse.quote() in Python.

Mistake 5: Inconsistent Encoding of Unicode Characters

Unicode characters like é, ñ, or Chinese characters need special handling. Some systems expect UTF-8 bytes to be percent-encoded individually, while others may have different expectations. Fix: Always use UTF-8 encoding for Unicode characters, and verify your API or service documentation for their specific requirements. The string "café" becomes "caf%C3%A9" when UTF-8 encoded (é is C3 A9 in UTF-8).

When and Why to Use URL Encoding

Building Query Strings for Search

When users search for terms with spaces or special characters, URL encoding ensures the search query reaches the server intact. A search for "best pizza & burgers" must become "best%20pizza%20%26%20burgers" in the URL. Without encoding, the ampersand would be misinterpreted as a parameter separator, corrupting the query.

Passing Data in API Requests

REST APIs commonly use query parameters or path segments to pass data. If your API expects a product ID that might contain special characters, encoding prevents the URL from being parsed incorrectly. For example, a product code "PROD-123&STOCK" must be encoded as "PROD-123%26STOCK" to be treated as a single value.

Handling Form Submissions

HTML forms submitted via GET method append form field values to the URL as query parameters. If a user enters text with special characters, the browser automatically encodes these before navigating. Understanding encoding helps you debug why certain characters appear as percent-codes in your server logs.

Preventing Injection Attacks

URL encoding is a defense layer against injection attacks. By encoding user input, you prevent malicious values from being interpreted as URL structure. However, encoding alone isn't sufficient—you should also validate and sanitize input on the server side.

Working with Redirect URLs

When building redirect URLs that include dynamic parameters, every component must be encoded appropriately. The target URL inside a redirect must be URL-encoded if it's being passed as a parameter, preventing the redirect destination from being manipulated.

Frequently Asked Questions

What's the difference between encodeURI and encodeURIComponent?

In JavaScript, encodeURI() encodes a complete URI while preserving characters that are legal in a full URL, including /, ?, and &. It doesn't encode unreserved characters (A-Z, a-z, 0-9, -, _, ., !, ~, *, ', (, ), :, @, $, and ,). Use encodeURI() when encoding a full URL. Use encodeURIComponent() when encoding a single component value that will be inserted into a URL—it encodes all special characters including &, =, /, ?, and spaces. For safety, always use encodeURIComponent() for query parameter values.

Why do some URLs show + instead of %20 for spaces?

The application/x-www-form-urlencoded format, used by HTML forms, historically replaced spaces with plus signs (+) rather than %20. While technically deprecated in favor of UTF-8 percent-encoding, this legacy format still appears in some contexts. Modern web APIs should use percent-encoding throughout, but you may encounter + signs in older systems or form submissions. When decoding, your decoder should handle both %20 and + as spaces for compatibility.

How do I decode a URL that's already been encoded multiple times?

If you receive a string like "hello%2520world", it's been encoded twice (the first encoding turned the space into %20, then the % was encoded as %25). To decode, apply your decoder repeatedly until the string stops changing. In practice, this usually means decoding once or twice at most. If you see a string like "hello%25252520world", you have deeply nested encoding that indicates a bug in the encoding pipeline that should be fixed rather than blindly decoded.

URL Encode & Decode

```