URL Encoder / Decoder

About URL Encoder / Decoder

What Is It?

URL encoding, formally called percent-encoding, is a mechanism for representing characters in a URL that would otherwise be ambiguous or illegal. URLs can only safely contain a limited set of characters from the US-ASCII character set: letters, digits, and a handful of special characters like -, _, ., and ~. Anything else — spaces, non-ASCII characters like é or 中, or reserved characters like & and = when used as data rather than syntax — must be percent-encoded. An encoded character looks like %HH where HH is the two-digit hexadecimal representation of the byte value. For example, a space becomes %20 and the ampersand & becomes %26.

How Does It Work?

The encoding process works at the byte level. Each character that needs encoding is converted to its UTF-8 byte representation (for non-ASCII characters), and each byte is then written as %XX. The character é (U+00E9) in UTF-8 is the two-byte sequence 0xC3 0xA9, so it encodes as %C3%A9. There's an important distinction between encoding a full URI component versus a segment: JavaScript's encodeURIComponent() encodes all reserved characters (including /, ?, &, =), making it suitable for query parameter values, while encodeURI() preserves characters that have structural meaning in a URL — useful when you're encoding a full URL that should remain syntactically valid. This tool uses the stricter encodeURIComponent approach, which is what you want for encoding individual values destined for query strings or path segments.

Common Use Cases

The most frequent use is building query strings dynamically. If a user searches for "coffee & tea", that ampersand must be encoded as %26 in ?q=coffee%20%26%20tea, otherwise the server would interpret it as a second query parameter. Similarly, when constructing REST API URLs that include user-generated content — like /users/jane%20doe/profile — the space must be encoded. Form submissions via GET method automatically encode all field values. Beyond web forms, URL encoding is used in OAuth redirect URIs, where callback URLs containing query parameters must be double-encoded, and in mailto: links where the body, subject, and CC fields all need encoding.

Tips and Best Practices

Don't double-encode: The biggest pitfall is encoding an already-encoded string. %20 becomes %2520 (the % itself gets encoded to %25), which decodes to the literal string "%20" instead of a space. If you're not sure whether a string is already encoded, check for % characters; a properly encoded string will have them followed by two hex digits. Decoding is lossy: Once you decode %2F back to /, you can't tell whether the original was a literal slash or an encoded one — so be careful decoding URL paths for security checks. Plus vs. %20: In the query string portion only (application/x-www-form-urlencoded), spaces can also be represented as +. This tool uses %20 which works everywhere.

Frequently Asked Questions

Do I always need to encode URLs? If you're typing a URL directly into a browser's address bar, modern browsers handle encoding for you. But when generating URLs programmatically — in JavaScript, server-side code, or when composing API requests — you must explicitly encode any dynamic values. Which characters are safe without encoding? Unreserved characters: A-Z, a-z, 0-9, hyphen (-), underscore (_), period (.), and tilde (~). Everything else should be encoded when used as data. What about non-Latin characters? Internationalized domain names and UTF-8 characters in paths must be percent-encoded to their UTF-8 byte sequences. For example, the German word "schön" encodes as sch%C3%B6n.