When to use this
Encode any user-supplied or free-text value before placing it in a query parameter, path segment or fragment.
This page is a focused view of theURL Encode / Decode, which has the full set of options.
URL encode
Percent-encoding replaces each unsafe byte with a three-character %XX escape: a space becomes %20 (1 byte → 3 characters), and non-ASCII characters are UTF-8-encoded first, so é (2 bytes) becomes %C3%A9 (6 characters) and a 4-byte emoji becomes 12 characters. Only the 66 unreserved characters — letters, digits, and “-”, “_”, “.”, “~” — always survive unencoded.
The expansion is exact and worst-case bounded: every encoded byte costs 3 output characters, so a fully non-ASCII UTF-8 string grows by up to 200% (3 characters per byte, 2–4 bytes per character — “日本語”, 9 bytes, becomes 27 characters). ASCII text with occasional spaces grows far less; a query value with one space in ten characters grows 20%.
When it goes wrong
Encoding itself cannot fail — but encoding the wrong thing does: encode the value, never the whole URL, or the URL's own “:”, “/” and “?” become literals and the link breaks. If the receiving server shows “+” where you meant spaces, it treated your %20 form as form-encoding — or vice versa; %20 is safe in every context, “+” only inside form query strings.
Next steps
Frequently asked questions
Why did my space become %20 and not +?
Both exist: %20 is standard percent-encoding, while + means space only inside application/x-www-form-urlencoded form data. %20 is safe everywhere; + is only safe in form query strings.
Which characters survive unencoded?
Unreserved characters: letters, digits, and - _ . ~. Everything else may be percent-encoded, and reserved characters like & = ? # must be when they appear inside a value.
How are non-ASCII characters like é encoded?
They are encoded as UTF-8 first, then each byte is percent-encoded — é becomes %C3%A9, exactly tripling its byte count.