URL Encoding Explained: What Percent-Encoding Does

URL encoding, also called percent-encoding, is the standard way to safely place text inside a web address. URLs can only contain a limited set of ASCII characters, and several characters such as / ? # and & already carry special structural meaning. This guide explains what URL encoding is, why URLs need it, how percent-encoding turns each unsafe byte into a %XX sequence, which characters are reserved versus unreserved, the difference between %20 and a plus sign, when to use encodeURIComponent versus encodeURI, and the common pitfalls like double-encoding. You can test any string with the URL Encoder / Decoder as you read.

What is URL encoding?

URL encoding is a method of escaping characters so that arbitrary text can be carried inside a URL without breaking it. When a character is not allowed in a particular part of a URL - or when it would be misread as part of the URL's structure - it is replaced with a percent sign followed by two hexadecimal digits. For example, a space is not allowed directly in a URL, so it is written as %20. The process is fully reversible: decoding turns %20 back into a space. Importantly, URL encoding is not encryption. Anyone can decode it, so it provides no secrecy or security - it only makes text safe to transmit.

Why URLs need encoding

A URL is parsed by browsers, servers, and proxies that all rely on a small, agreed-upon set of ASCII characters. Two problems arise without encoding. First, many characters - spaces, accented letters, emoji, and most non-English text - are simply not part of the allowed URL character set. Second, certain ASCII characters are reserved because they delimit parts of the URL: a ? starts the query string, a # starts the fragment, an & separates query parameters, and a / separates path segments. If you want one of those characters to be literal data rather than a delimiter, you must encode it so the parser does not act on its special meaning.

How percent-encoding works

Percent-encoding operates on bytes, not on characters directly. Each byte that needs escaping is written as %XX, where XX is that byte's value in hexadecimal. For plain ASCII the byte maps to one character, so a space (byte 0x20) becomes %20 and an at-sign (byte 0x40) becomes %40. For non-ASCII text, the character is first converted to its UTF-8 byte sequence, and then each of those bytes is written as its own %XX. For example, the euro currency name character is three UTF-8 bytes, so it appears as three percent groups in a row. This is why a single accented letter can expand into two or more %XX sequences.

Reserved vs unreserved characters

Characters fall into two groups. Unreserved characters are always safe and are never encoded; reserved characters have structural meaning and must be encoded when you want them treated as literal data.

• Unreserved (never encoded): A-Z, a-z, 0-9, hyphen ( - ), underscore ( _ ), period ( . ), and tilde ( ~ ).
• Reserved (encode when used as literal data): : / ? # [ ] @ ! $ & ' ( ) * + , ; =
• A reserved character left unencoded is interpreted as part of the URL structure - for instance, a literal & inside a value would split it into two parameters.

Spaces: %20 vs plus

Spaces are a frequent source of confusion because they have two valid encodings depending on context. In a URL path or a generic component, a space becomes %20. In query data submitted as a form - the application/x-www-form-urlencoded format used by HTML forms - a space is commonly written as a plus sign ( + ) instead. Both represent a space, but they are not interchangeable in every position. A literal plus sign in form-encoded data must itself be encoded as %2B so it is not mistaken for a space. When in doubt, %20 is the safer, more universal choice.

How to encode a value the right way

JavaScript provides two functions, and choosing the wrong one is a common mistake. Use encodeURIComponent for a single piece of data, such as one query parameter value or one path segment; it encodes aggressively, escaping reserved characters like / ? # & = so the value cannot disturb the surrounding URL. Use encodeURI only when you have an entire, already-structured URL and just need to escape stray illegal characters; it deliberately leaves reserved structural characters unescaped so the URL still works. The reliable workflow is short:

1. Identify the single value you need to insert, such as a search term or a path segment.
2. Run that value through encodeURIComponent (or paste it into the URL Encoder / Decoder) to escape every reserved character.
3. Build the rest of the URL as plain text, keeping the structural :, /, ?, #, and & intact.
4. Drop the encoded value into place, and decode it once to confirm the round trip returns your original text.

Common pitfalls

Two mistakes account for most broken links. Double-encoding happens when you encode text that was already encoded, turning a percent sign into %25 and producing values like %2520 where you meant %20. The fix is to encode each value exactly once, at the point where you build the URL. The second pitfall is encoding a whole URL when you only meant to encode one parameter value - this escapes the :, /, ?, and & that the URL needs to function, leaving a string that no longer points anywhere. Encode the individual value, then place it into the otherwise plain URL.

Try it yourself

The quickest way to understand percent-encoding is to experiment. Paste a string with spaces, ampersands, or non-English text into the URL Encoder / Decoder and watch each character convert to its %XX form, then decode it back to confirm the round trip. If you also work with data that needs to travel as text but is not encryption, see What Is Base64 Encoding? for a related transformation. Bookmark the URL Encoder / Decoder for the next time a link breaks on a stray special character.