URL Encode & Decode

Convert text into a form that is safe to put inside a URL, or decode a percent-encoded string back into readable text. Both encoding styles are available, because choosing the wrong one is the single most common cause of broken links and mangled query parameters.

UTF-8 is handled throughout, so accented characters, emoji and non-Latin scripts encode and decode correctly.

How it works

URLs may only contain a restricted set of ASCII characters. Anything outside it — spaces, most punctuation, and every non-English character — must be percent-encoded: replaced by % followed by the byte's hexadecimal value. A space becomes %20, and é becomes %C3%A9, two bytes because it is two bytes in UTF-8.

There are two encodings in common use, and they differ in exactly one place:

• RFC 3986 (percent encoding) encodes a space as %20. Use this for path segments, and generally anywhere that is not a form submission.
• Form encoding (application/x-www-form-urlencoded) encodes a space as +. This is what HTML forms produce and what query strings traditionally use.

The mismatch causes a specific, recognisable bug: a value encoded with + for spaces, then decoded by something following RFC 3986, arrives with literal plus signs where the spaces should be. If you have ever seen John+Smith appear in your database, this is why.

Two further traps worth knowing. First, encode each component separately, never a whole assembled URL — encoding the complete string will also escape the :// and the separators, breaking it entirely. Second, double encoding: running an already-encoded string through again turns %20 into %2520, because the % itself gets encoded.

Frequently asked questions