URL Encoder / Decoder

URL encoding (percent-encoding) explained

URLs were originally designed for ASCII only, with a tight set of reserved characters that have structural meaning: : separates the scheme, /divides path segments, ? begins the query, # starts the fragment, and & + = structure key/value pairs. Anything outside that ASCII alphabet — spaces, accented letters, emoji, control bytes — has to be represented indirectly. Percent-encoding does that: it takes the UTF-8 byte sequence of a character and emits each byte as % followed by two hex digits. So café (where é is two bytes 0xC3 0xA9) becomes caf%C3%A9. The same scheme escapes reserved characters when you want them treated as data instead of structure — useful when a search term contains a literal & or ?.

encodeURI vs encodeURIComponent: when to use which

JavaScript ships two built-ins that look interchangeable but aren't. encodeURI assumes you're handing it a complete URL and leaves structural characters alone — it will not touch :, /,?, #, &, or =. That's perfect for fixing up an already-shaped URL like https://x.com/search?q=hello world, which becomes https://x.com/search?q=hello%20world. encodeURIComponent is for individual pieces — a single query value, a path segment, a fragment ID — and encodes everything non-alphanumeric, including /, ?, and &. The rule of thumb: if you're building a URL by concatenation, encode each value withencodeURIComponent and then join them with the literal ?,&, and = separators yourself. If you got handed a URL that just needs cleaning up, encodeURI is what you want.

Reserved characters in URLs and what they mean

The RFC 3986 reserved set splits into gen-delims (: / ? # [ ] @), which mark the major structural boundaries of a URL, and sub-delims(! $ & ' ( ) * + , ; =), which can have meaning inside specific components. : separates scheme from authority and host from port. /delineates path segments. ? kicks off the query string. #starts the fragment, which is browser-only. Inside the query, & joins key/value pairs and = separates each key from its value. If your data contains any of these characters and you want them treated as literal text instead of structure, you must percent-encode them — that's why encodeURIComponentis so aggressive.

Form data encoding vs URL encoding (+ vs %20)

There are two coexisting conventions for encoding spaces. The modern URI spec says a space becomes %20, full stop. The older application/x-www-form-urlencoded spec — what HTML forms use when they POST, and what most browsers use when building query strings from form fields — encodes a space as +. Both are common in the wild. Most servers and frameworks decode either one, but a few are strict. The big gotcha: a literal + in form-encoded data will be decoded back to a space. If your value contains a real plus sign (a phone number like +44, a math expression, a tag likeC++), you must encode it as %2B so the server doesn't silently turn it into a space. Use the encode tab here and watch the warnings — we flag this exact case.

Common URL encoding bugs and how to spot them

Double-encoding is the classic: a value gets encoded once at the client, once at a proxy, and arrives at the server as %2520 instead of %20— that %25 is the percent sign itself, encoded. If you see %25sequences where you expect plain encoded text, something in the chain ranencodeURIComponent twice. Wrong helper is the next: passing a full URL toencodeURIComponent mangles the slashes and question marks; passing a single value to encodeURI leaves & and = in the value, which breaks query parsing. Lost fragments happen because fragments (#section) are client-side only — they never reach the server, so logging frameworks and analytics can't see them. Plus-vs-space bugs strike when client and server disagree about form encoding. The pitfall checker on this page flags all four patterns as soon as you paste an input.