Why URLs Can't Just Contain Any Character

Here's something most people don't realize: URLs were designed in the early 1990s to work with a very limited set of characters. The original specification (RFC 1738) only allowed letters, digits, and a handful of special characters like hyphens and underscores.

So what happens when you need a space in your search query? Or when you're building an Indian website with Hindi text in the URL? Those characters simply aren't allowed in their raw form.

That's where percent-encoding steps in. It converts each "unsafe" character into a percent sign followed by two hexadecimal digits representing that character's byte value. A space becomes %20. An ampersand becomes %26. Hindi text like "मुंबई" becomes a long string of percent-encoded UTF-8 bytes.

The Anatomy of a URL — What Gets Encoded and What Doesn't

Before you start encoding everything in sight, you need to understand URL structure. A URL has several parts, and each part has different encoding rules.

Breaking this down:

• Scheme: https:// — never encoded
• Host: example.com — uses different encoding (Punycode for internationalized domains)
• Port: :443 — never encoded
• Path: /path/to/page — slashes preserved, other special chars encoded
• Query: ?key=value&name=John Doe — values must be encoded, structural characters (? & =) preserved
• Fragment: #section — the hash is preserved, content after it may need encoding

The critical takeaway? You don't encode everything uniformly. The encoding strategy depends on which part of the URL you're working with.

encodeURI vs encodeURIComponent — The Most Common Mistake

If you've ever used JavaScript to build URLs, you've probably encountered both encodeURI() and encodeURIComponent(). Using the wrong one is the single most common URL encoding mistake developers make.

Here's what each one does:

Now here's the interesting part. If you use encodeURIComponent() on an entire URL like https://example.com/search?q=test, you'll get https%3A%2F%2Fexample.com%2Fsearch%3Fq%3Dtest — completely broken because the colons, slashes, and question marks got encoded too.

Conversely, using encodeURI() on a query parameter value like price=100¤cy=INR won't encode the ampersand, which means the URL parser will think currency=INR is a separate parameter instead of part of the value.

Rule of thumb: Use encodeURI() when encoding a complete URL. Use encodeURIComponent() when encoding individual query parameter keys or values.

How Unicode and Multi-Language Text Gets Encoded

URL encoding becomes especially interesting with non-Latin scripts. If you're working with Hindi, Tamil, Arabic, or Japanese text, each character first gets converted to its UTF-8 byte sequence, and then each byte is percent-encoded individually.

Let's look at a real example. The Hindi word "नमस्ते" (namaste) in UTF-8 consists of multiple bytes per character:

So "नमस्ते" becomes %E0%A4%A8%E0%A4%AE%E0%A4%B8%E0%A5%8D%E0%A4%A4%E0%A5%87 — quite a mouthful! This is why multilingual URLs can look intimidating, but they decode back perfectly.

Modern browsers are smart enough to display decoded Unicode in the address bar even when the actual request uses percent-encoded values. So users see readable text while the network layer handles the encoding transparently.

Real-World Scenarios Where URL Encoding Saves You

In our experience, most URL encoding bugs happen when developers concatenate URL strings manually instead of using proper encoding functions. The fix is almost always: encode each parameter value separately with encodeURIComponent(), then assemble the full URL.

Common Characters and Their Encoded Values

Here's a quick reference table you'll find yourself coming back to. These are the characters most frequently encountered in URL encoding:

Notice that the space character has two representations: %20 is the standard percent-encoding, while + is used specifically in form data (application/x-www-form-urlencoded). They're not always interchangeable, which catches many developers off guard.

URL Encoding in Different Programming Languages

Every language handles URL encoding slightly differently. Here's what you need to know if you work across multiple tech stacks.

JavaScript: Use encodeURIComponent() for values and encodeURI() for full URLs. For form-style encoding with + for spaces, use URLSearchParams.

Python: The urllib.parse module provides quote() for percent-encoding and unquote() for decoding. Use quote_plus() when you need + for spaces.

PHP: urlencode() encodes spaces as + (form-style), while rawurlencode() uses %20. For decoding, there's urldecode() and rawurldecode().

Java: URLEncoder.encode() produces form-encoded output. For RFC-compliant percent-encoding, you'll need to manually replace + with %20 or use a URI builder library.

But why does this matter? Because if your frontend encodes a value using JavaScript's encodeURIComponent() (which uses %20 for spaces), but your backend decodes it with PHP's urldecode() (which expects + for spaces), you might get unexpected results in edge cases.

URL Encoding and SEO — What You Need to Know

Here's a question we get asked frequently: do encoded URLs hurt SEO? The short answer is no — search engines handle encoded URLs just fine. But there are nuances worth understanding.

Google normalizes URLs during crawling. So /products/blue%20shoes and /products/blue shoes are treated as the same URL. However, using clean, human-readable URLs is still better practice for three reasons:

• Click-through rates: Users are more likely to click on a readable URL in search results
• Link sharing: Clean URLs look more trustworthy when shared on social media or messaging apps
• Debugging: Readable URLs are far easier to troubleshoot in server logs and analytics

That said, query parameters with encoded values are perfectly normal and expected. Don't worry about encoding in UTM parameters, search queries, or API endpoints — those are supposed to contain encoded values.

Five Mistakes That Break URLs (and How to Avoid Them)

After seeing thousands of URL encoding bugs, here are the patterns that keep repeating:

1. Double encoding. This happens when you encode a value, then encode the entire URL again. A space becomes %20, then the % gets encoded to %25, giving you %2520. The fix: encode each component once, then concatenate.

2. Not encoding at all. Trusting that raw user input will be URL-safe is a recipe for broken links. Always encode values that come from user input, databases, or external APIs.

3. Using the wrong function. We covered this earlier, but it bears repeating. encodeURIComponent() for values, encodeURI() for full URLs. Mixing them up is the number one source of encoding bugs.

4. Forgetting to decode on the server. If your server receives an encoded parameter but doesn't decode it before processing, you'll be searching your database for %E0%A4%A8%E0%A4%AE%E0%A4%B8%E0%A5%8D%E0%A4%A4%E0%A5%87 instead of "नमस्ते".

5. Encoding hash fragments. The # symbol and everything after it is never sent to the server — it's handled entirely by the browser. Encoding it as %23 will cause it to be sent as a literal string instead of being treated as a fragment identifier.

URL Encoding Across Languages

URL encoding is a universal web standard used across all languages and regions. Here's how the concept is referred to in different languages:

When to Use a URL Encoder Tool vs Writing Code

You might be wondering: should I just use an online tool or write encoding logic in my code? The answer depends on your situation.

Use an online tool when: you're quickly debugging a broken URL, verifying that an encoded string decodes correctly, encoding a one-off value for a configuration file, or checking how a Unicode string looks when encoded.

Write it in code when: you're building an application that processes URLs dynamically, handling user input that goes into URLs, constructing API request URLs programmatically, or building any system where encoding needs to happen automatically at scale.

For quick encoding and decoding tasks, we recommend keeping a reliable tool bookmarked. It's faster than opening a code editor and writing a throwaway script every time you need to check an encoding.