URL encoder and decoder: percent-encoding online.

URL encoding, properly called percent-encoding, is how characters that are not allowed in a URL, or that have a special meaning there, are written safely. Each byte of the character's UTF-8 form becomes a percent sign followed by two hexadecimal digits: a space becomes %20, & becomes %26, é becomes %C3%A9 and the rupee sign ₹ becomes %E2%82%B9.

RFC 3986, the URI standard, defines unreserved characters that never need encoding: the letters A to Z and a to z, the digits 0 to 9, and - . _ ~. Reserved characters such as : / ? # [ ] @ ! $ & ' ( ) * + , ; = separate the parts of a URL, so they must be encoded whenever they appear inside a value rather than as structure. Everything else, including spaces, quotes, % itself and all non-ASCII text, is always encoded. Browsers follow the WHATWG URL Standard, which describes the same encoding in terms of how real browsers parse URLs.

encodeURIComponent, the Component mode here, escapes everything except letters, digits and - _ . ! ~ * ' ( ). Because it also escapes / ? & = # and +, it is the right choice for one value you are placing into a URL: a search term, a path segment, a redirect URL passed as a parameter.

encodeURI, the Full URL mode, leaves the characters that give a URL its structure alone and escapes spaces, non-ASCII text and a few unsafe characters such as double quotes, angle brackets and %. Use it on a complete URL that you know is otherwise well formed.

Mixing them up causes two classic bugs. Encoding a whole URL with encodeURIComponent turns https:// into https%3A%2F%2F and breaks it. Encoding a value with encodeURI leaves its & and # unescaped, so a search for 'salt & pepper' silently becomes a parameter called pepper. In JavaScript, the URL and URLSearchParams APIs handle this for you and are usually the best way to build URLs.

Both appear in the wild. In a URL path and in RFC 3986 a space is always %20. HTML form submissions use a separate format, application/x-www-form-urlencoded, in which spaces in the query string are written as +. URLSearchParams, PHP's urlencode, Python's quote_plus and Java's URLEncoder all produce that form style.

The catch is the literal plus sign. In form-encoded data + means space, so a phone number like +971 or an email address like name+tag@example.com is corrupted unless the plus is encoded as %2B. This decoder treats + as a space, matching how query strings are normally produced; encode real plus signs as %2B and they come back correctly.

Double encoding happens when already-encoded text is encoded again: %20 becomes %2520, because the % itself is encoded as %25. It usually means two layers of code each encoded the value. Decode until the text stops changing, then make sure only one layer encodes.

'URIError: URI malformed' or 'Malformed percent-encoding' means a % is not followed by two hex digits, or the bytes do not form valid UTF-8, such as a truncated %E0%A4. This tool points to the bad sequence. A literal percent sign must be written %25, so '50% off' encodes to 50%25%20off.

Full URL mode decodes with decodeURI, which deliberately leaves escapes for structural characters such as %2F, %3F, %23 and %26 untouched, because decoding them would change what the URL means. Use Component mode when you want everything decoded. International domain names are not percent-encoded at all: they use Punycode, so café.com is sent as xn--caf-dma.com.

Every language has its own functions, and they disagree about spaces. Python's urllib.parse.quote gives %20 and keeps / by default, while quote_plus gives + and is meant for form data. PHP's rawurlencode follows RFC 3986 with %20, and urlencode uses +. Java's URLEncoder.encode produces form encoding with +. Go has url.PathEscape for %20 and url.QueryEscape for +. In .NET, Uri.EscapeDataString is the equivalent of encodeURIComponent.

When two systems disagree about a value, compare their outputs here: Component mode shows the %20 style and the parameter table shows how a form-style query string is read by browsers and most servers. If you are moving binary data or tokens rather than text, Base64, usually its URL-safe variant, is the better fit.

Paste any URL and the table lists each parameter's key, its decoded value and the raw text exactly as it appeared. Repeated keys such as tag=ai&tag=web are kept in order, which is how frameworks build arrays. The base URL and the #fragment are shown separately; the fragment is never sent to the server. 'Copy as JSON' gives you an object to paste into a test, where a repeated key keeps its last value.

Encoding is not a security control. It makes text safe to place in a URL, but it does not stop cross-site scripting when the decoded value is later written into a page: that needs output escaping for HTML, attributes or JavaScript, plus validation on the server. Clean, readable URLs also help technical SEO, so prefer simple lowercase slugs with hyphens over long encoded strings. Everything on this page runs in your browser, so internal URLs and tokens stay on your device.

OAuth redirect_uri values, signed URLs and campaign links are where encoding causes the most support tickets. A redirect_uri passed as a parameter of the authorisation URL must be encoded in Component mode, and after decoding it must match the registered value exactly, or the authorisation server rejects the request.

Signed URLs, such as pre-signed cloud storage links or webhook signatures computed over a query string, break if a proxy or library re-encodes a single character after signing, for example turning %7E back into ~ or a space from %20 into +. Sign the exact string you send and avoid re-encoding it later. For UTM tags, use lowercase values with hyphens so they never need encoding: analytics tools treat Spring%20Sale and spring-sale as different campaigns.