URL Encoder / Decoder,
percent-encode any text, decode any URL.

Developer guide

What URL encoding is and why it matters.

A URL can only contain a limited set of characters from the ASCII range — letters, digits, and a small number of special characters with defined structural roles. Every other character (spaces, non-ASCII Unicode, reserved delimiters used in a non-structural context) must be encoded before it appears in a URL. This process is called percent encoding (formally defined in RFC 3986), and it is one of the most common encoding operations in web development.

How percent encoding works

Each character that needs encoding is replaced by a percent sign followed by two hexadecimal digits representing the byte value of that character in UTF-8:

Multi-byte Unicode characters first have their code point encoded as UTF-8 (which may require 2, 3, or 4 bytes), and then each byte is individually percent-encoded. This is why emoji and non-Latin characters produce long sequences like %F0%9F%9A%80 for 🚀.

encodeURIComponent vs. encodeURI

JavaScript provides two encoding functions, and choosing the wrong one is a common source of bugs:

• encodeURIComponent(value) — encodes everything except: A–Z a–z 0–9 - _ . ! ~ * ' ( ). Use this for individual values: query string parameters, path segments, fragment identifiers. It encodes &, =, /, ?, and #, which are all structurally meaningful characters that must not appear unencoded inside a component value.
• encodeURI(url) — encodes everything except: A–Z a–z 0–9 ; , / ? : @ & = + $ - _ . ! ~ * ' ( ) #. Use this for complete URLs that you want to make valid without breaking their structure. It intentionally preserves the characters that separate URL components.

The two ways to encode a space: %20 vs. +

RFC 3986 (the modern URI standard) defines %20 as the canonical encoding for a space in any URL context. The + sign as a space encoding comes from an older standard (HTML 2.0 / RFC 1866) for the application/x-www-form-urlencoded content type used in HTML form submissions. Within a query string submitted via a form, + means space, but in all other URL contexts and in modern REST APIs, + is a literal plus sign and %20 is a space. Mixing these up is a perennial source of bugs in web applications.

When you need URL encoding

• Building query strings programmatically. Every dynamic value in a query string must be encoded: ?q={search term} must become ?q=search%20term. Libraries like URLSearchParams (browser), urllib.parse (Python), and query-string (Node) handle this automatically.
• Embedding URLs inside other URLs. If a redirect target or a callback URL is a query parameter, the inner URL must be encoded with encodeURIComponent, otherwise its own & and = characters will break the outer URL’s parsing.
• International domain names (IDN) and paths. URLs with non-ASCII characters in path segments (e.g., /products/résumé) must be percent-encoded: /products/r%C3%A9sum%C3%A9.
• Debugging network requests. When inspecting HTTP request logs or encoded API responses, decoding the URL makes it immediately readable.

Characters that are always safe (unreserved)

RFC 3986 defines four classes of unreserved characters that are safe in any URL context without encoding:

Privacy: client-side only

This tool runs entirely in your browser using the native encodeURIComponent(), encodeURI(), decodeURIComponent(), and decodeURI() JavaScript functions. No data is transmitted to any server. This is especially important when encoding URLs that contain credentials, tokens, or other sensitive parameters.