URL Encoding: When, Why, and How

You paste a search query into a URL and spaces become %20. Ampersands turn into %26. That + you typed is suddenly %2B. Welcome to URL encoding, the percent-riddled transformation that makes the web actually work.

URL encoding (officially called "percent-encoding") is one of those things every developer encounters but few take the time to fully understand. Let's fix that.

Why URLs Need Encoding

URLs have a strict character set. According to RFC 3986, a URL can only contain:

• Letters: A-Z, a-z
• Digits: 0-9
• A handful of special characters: -, _, ., ~
• Reserved characters with specific meanings: :, /, ?, #, [, ], @, !, $, &, ', (, ), *, +, ,, ;, =

Everything else — spaces, Unicode characters, curly braces, angle brackets, and most of what you'd type in everyday text — must be percent-encoded.

The encoding is simple: take the byte value of the character in UTF-8, and represent each byte as %XX where XX is the hexadecimal value.

Space     → %20
@         → %40
é         → %C3%A9 (two bytes in UTF-8)
🎉        → %F0%9F%8E%89 (four bytes in UTF-8)

Our URL Encoder handles all of this automatically — paste any text and get the properly encoded version.

Spaces: %20 vs. +

This is the most common source of confusion. There are two different encoding standards for spaces:

%20 — defined by RFC 3986 for general URL encoding. Used in path segments:

https://example.com/my%20document.pdf

+ — defined by the application/x-www-form-urlencoded format, used specifically in query strings from HTML forms:

https://example.com/search?q=hello+world

Both are valid, but in different contexts. If you're encoding a URL path, use %20. If you're encoding form data for a query string, + for spaces is traditional (and %20 also works).

In practice, most modern systems accept both everywhere. But if you're debugging a URL that isn't working, check whether spaces are encoded correctly for the context.

What Needs Encoding (and What Doesn't)

A common mistake is encoding too much or too little. Here's the breakdown:

Never encode these (they're part of URL structure):

:  /  ?  #  @

These characters have special meaning in URLs (protocol separator, path delimiter, query indicator, fragment indicator, userinfo separator). Encoding them breaks the URL structure.

Always encode these in values:

Space  "  <  >  {  }  |  \  ^  `

Encode these when they appear in data, not as delimiters:

&  =  +

For example, if a query parameter value contains &, it must be encoded as %26 to distinguish it from the & that separates parameters:

// Wrong — parser thinks there are two parameters:
?message=bread&butter

// Right — one parameter with value "bread&butter":
?message=bread%26butter

URL Encoding in Practice

Query Parameters

The most common encoding scenario. Say you're building a search URL:

const query = "price < $50 & free shipping";
const url = `https://shop.com/search?q=${encodeURIComponent(query)}`;
// https://shop.com/search?q=price%20%3C%20%2450%20%26%20free%20shipping

Without encoding, the <, $, and & would break the URL. The & is particularly dangerous — it would be interpreted as a parameter separator, splitting your search query into multiple parameters.

File Paths with Spaces

File names with spaces in URLs need encoding:

https://cdn.example.com/uploads/my vacation photo.jpg
→ https://cdn.example.com/uploads/my%20vacation%20photo.jpg

Internationalized URLs

Non-ASCII characters in URLs require encoding. A page about café culture:

https://example.com/topics/café
→ https://example.com/topics/caf%C3%A9

Modern browsers display the decoded version in the address bar for readability, but the actual HTTP request uses the encoded form.

URL Slugs: The Clean Alternative

Instead of encoding messy strings, a better approach for URLs you control is to create slugs — clean, lowercase, hyphenated versions of text:

"The Complete Guide to URL Encoding!"
→ "the-complete-guide-to-url-encoding"

Slugs strip special characters entirely rather than encoding them. They're more readable, better for SEO, and don't have encoding issues. Compare:

example.com/articles/What%20is%20URL%20Encoding%3F
example.com/articles/what-is-url-encoding

The second is cleaner in every way. Use our Slug Generator to convert any title into a URL-friendly slug.

Slug best practices:

• Lowercase only
• Hyphens instead of spaces (Google treats hyphens as word separators)
• Strip special characters and accents
• Keep it concise — 3-5 words is ideal for SEO
• Avoid stop words when the meaning is preserved

URL Encoding vs. HTML Entities

These are different encoding systems for different contexts, and mixing them up causes bugs.

URL encoding (%XX) is for URLs. It encodes byte values.

HTML entities (&, <, <) are for HTML content. They prevent characters from being interpreted as HTML markup.

You need both in different situations. A link in HTML:

<!-- The href uses URL encoding, the display text uses HTML entities -->
<a href="/search?q=Tom%20%26%20Jerry">Tom &amp; Jerry</a>

If you put HTML entities in a URL, they won't be decoded. If you put URL encoding in HTML text, it'll display literally as %26.

Our HTML Entities tool handles the HTML side of this equation.

Double Encoding: The Classic Bug

Double encoding happens when already-encoded text gets encoded again:

Original:         hello world
First encoding:   hello%20world
Double encoded:   hello%2520world   ← %25 is the encoding of %

The % itself gets encoded to %25, so %20 becomes %2520. This is one of the most common URL bugs. It happens when:

• A framework encodes a URL, then you encode it again manually
• Data passes through multiple encoding layers
• You copy an already-encoded URL and encode it "just to be safe"

If a URL has %25 in it, something has been double-encoded. Decode once and check if the result is valid.

Try It Yourself

URL encoding issues are easier to debug when you can quickly encode and decode strings. Keep these tools handy:

• URL Encoder/Decoder — encode and decode percent-encoded strings
• Slug Generator — create clean, SEO-friendly URL slugs
• HTML Entities — encode and decode HTML entities (for the HTML side)

All processing happens in your browser. Your text stays private.