URL Encode a String: Encoding Values Safely

Encode values, not URLs

Encode each value separately, then assemble the URL. Encoding an already-assembled URL destroys it — the ?, & and / that give it structure get escaped along with everything else.

The reverse mistake is more common: not encoding a value at all. A search term containing & silently splits into two query parameters, and the second half of the term disappears.

The function to use

// JavaScript — for a value
encodeURIComponent('a b&c');    // 'a%20b%26c'

# PHP — RFC 3986, spaces as %20
rawurlencode('a b&c');          // 'a%20b%26c'
urlencode('a b&c');             // 'a+b%26c'  (form style, + for space)

# Python
from urllib.parse import quote, urlencode
quote('a b&c', safe='')         # 'a%20b%26c'
urlencode({'q': 'a b&c'})       # 'q=a+b%26c'

# shell
jq -rn --arg v 'a b&c' '$v|@uri'

PHP has two functions for a reason: rawurlencode follows RFC 3986 and encodes a space as %20, while urlencode follows form rules and uses +. Use rawurlencode for path segments and anything going into a signature.

What gets encoded

Unreserved characters are always left alone: A-Z a-z 0-9 - _ . ~. Everything else that could be structural gets escaped — space, &, =, ?, #, /, :, @, +, %.

Non-ASCII is converted to UTF-8 bytes first, then each byte becomes %XX. So é becomes %C3%A9 and one emoji becomes four escapes. That expansion is correct, not a bug.

Encoding exactly once

A value encoded twice shows %2520 where %20 belongs, because the % itself got escaped. If you see %25 in your URLs, an encoder ran twice — usually once in application code and once in a client library or template helper.

Pick one layer to encode at, and log the final URL to confirm. Prefer a URL builder (URLSearchParams, http_build_query, urlencode) over manual concatenation; they encode each value exactly once by construction.