URL Encoder / Decoder

About URL Encoding

URL encoding — also called percent-encoding — is defined in RFC 3986 (Uniform Resource Identifier: Generic Syntax). It is the mechanism that lets a URL safely carry characters that would otherwise be illegal, ambiguous, or have structural meaning. Whenever you put user input, search terms, file names, or non-ASCII text into a URL, you almost certainly need to URL-encode it first.

The encoding scheme is simple: take the byte value of each unsafe character, write it in hexadecimal, and prepend a %. A space (byte 0x20) becomes %20. The at sign @ (byte 0x40) becomes %40. Multi-byte UTF-8 characters get encoded one byte at a time, so the rocket emoji 🚀 (U+1F680) becomes %F0%9F%9A%80.

encodeURIComponent vs encodeURI

JavaScript ships with two built-in functions that handle URL encoding, and choosing between them is the most common source of bugs:

• encodeURIComponent encodes everything that is not an unreserved character, including reserved delimiters like / ? # & = +. Use it when encoding individual pieces of a URL — a query string value, a path segment, a form field.
• encodeURI assumes the input is already a complete URL and leaves the structural delimiters alone. Use it when encoding a fully-formed URL that just happens to contain a few characters that need escaping (like spaces or non-ASCII letters).

A practical example: building a search URL with the term a&b=c. With encodeURIComponent('a&b=c') you get a%26b%3Dc, which is correct because the & and = are part of the value, not delimiters. With encodeURI, those characters would be left as-is and the receiving server would parse them as additional query parameters — a real-world bug that breaks search analytics.

Common Pitfalls

Double-encoding is the most frequent mistake. If a value is already URL-encoded and you encode it again, %20 becomes %2520 and the receiver sees a literal %20 instead of a space. Always know whether your input is plain or already encoded.

Plus signs in query strings are a legacy quirk. The application/x-www-form-urlencoded format used by HTML forms encodes spaces as + instead of %20. Both representations decode to a space in query strings on most servers, but a literal plus character must be encoded as %2B to survive round-tripping.

Hash fragments and slashes behave differently in different libraries. encodeURIComponent escapes /, but most servers and browsers treat unescaped slashes inside a query string as harmless. If you are building deep paths, prefer encodeURI on the full URL or build path segments individually with encodeURIComponent and join them with literal slashes.

Code Examples

Here is how URL encoding looks across common languages, all producing identical output:

// JavaScript
encodeURIComponent('hello world & more')
// → "hello%20world%20%26%20more"

// Python 3
from urllib.parse import quote
quote('hello world & more', safe='')
# → 'hello%20world%20%26%20more'

// Go
import "net/url"
url.QueryEscape("hello world & more")
// → "hello+world+%26+more"  (note: + for space, x-www-form-urlencoded style)

// Ruby
require 'cgi'
CGI.escape('hello world & more')
# → "hello+world+%26+more"

When to Encode

Encode whenever user-controlled or non-ASCII text is concatenated into a URL: search terms, redirect destinations, OAuth state values, signed token parameters, file names being downloaded, and analytics tracking parameters. Failing to encode is one of the leading causes of broken share links, mis-attributed clicks, and accidentally truncated query strings — and in some cases it can become a security issue if user input breaks out of an expected URL component into a different one.