URL Encoder

How to URL encode text

1. Paste the text or URL into the box above.
2. Choose component mode for a query value, or whole-URL mode for a complete address.
3. Decide how spaces should be encoded, %20 for paths, + for form data.
4. The encoded result appears immediately below.
5. Copy it into your URL, request or configuration.

What the two modes do

• Component escapes every reserved character, including slashes and ampersands.
• Whole URL leaves the structural characters that make a URL work.
• Optional plus-sign encoding for spaces, matching form submission conventions.
• Full Unicode support, accented characters and emoji encode as UTF-8 bytes.
• Live updating with no button to press.
• No upload, so URLs containing tokens stay on your machine.

Why URLs need encoding at all

A URL is a structured string, and a handful of characters carry structural meaning. A question mark starts the query. An ampersand separates parameters. A slash separates path segments. A hash starts the fragment. When one of those characters appears inside a value rather than as structure, it has to be escaped or the URL falls apart.

Search for "coffee & cake" without encoding and the ampersand is read as a parameter separator: the server sees a query of "coffee " and a mysterious parameter called "cake". Percent-encoding replaces it with %26, and the value arrives intact.

Component or whole URL?

This is the choice people get wrong, and both directions cause problems.

Use component mode for anything going inside a URL, a search term, a redirect target, a filename in a path segment. It escapes every reserved character, which is what you want, because those characters are data rather than structure.

Use whole URL mode when you have a complete address containing a few illegal characters, such as spaces, and want the rest left alone. It leaves slashes, colons, question marks and ampersands intact so the URL still functions.

Encoding a whole URL in component mode produces something like https%3A%2F%2Fexample.com, which is correct only when that URL is itself a parameter value, a redirect target, for instance. Encoding a search term in whole-URL mode leaves the ampersand unescaped and breaks the query.

%20 or plus?

• %20: correct everywhere, and required in path segments.
• +: means a space only in application/x-www-form-urlencoded data, which is what HTML forms send.

A plus sign in a path segment is a literal plus, not a space. That mismatch is the cause of a specific and maddening bug: a filename with a space works when submitted through a form and breaks when constructed by hand. When in doubt, use %20.

Unicode and double encoding

Non-ASCII characters are converted to UTF-8 bytes and each byte is percent-encoded, so "é" becomes %C3%A9: two escapes for one character. That is correct and is what every modern system expects.

The commonest mistake after that is encoding twice. A % is itself reserved, so encoding an already-encoded string turns %20 into %2520. If a URL contains %25 followed by more hex digits, something has been encoded one time too many, the URL decoder has a repeat option that unwinds it. To inspect a URL's structure instead, the URL parser breaks it into parts.

Encoding in code rather than by hand

Doing this by hand is fine for a one-off. In code, always use the language's own function rather than string replacement: encodeURIComponent in JavaScript, urllib.parse.quote in Python, rawurlencode in PHP. Hand-written escaping misses characters, and the ones it misses are exactly the ones an attacker looks for.

The other rule worth following is to build URLs with a URL object rather than by concatenating strings. Appending "?q=" + value means remembering to encode every time; setting a search parameter on a URL object encodes automatically and cannot be forgotten. Most injection through query strings traces back to concatenation somebody did once without thinking.