URL Encode / Decode
Percent-encode text so it’s safe to use inside a URL, or decode it back to plain text. Choose component mode for a single query value or path segment, or full-URI mode to keep structural characters like / and ? untouched. Invalid input shows a clear error, not garbage.
How percent-encoding works
URLs can only safely carry a limited set of US-ASCII characters. Anything outside that set — spaces, punctuation like & and #, or non-English letters — gets rewritten as a percent sign followed by two hexadecimal digits representing its byte value, so a space becomes %20 and ‘&’ becomes %26. Because this method uses the % character, it’s formally called percent-encoding; “URL encoding” is the common, slightly looser name for the same thing.
How it’s calculated
Component mode uses JavaScript’s encodeURIComponent, which escapes every character except A–Z, a–z, 0–9, and - _ . ~ — appropriate for a value that will be placed inside a single query parameter or path segment. Full-URI mode uses encodeURI, which additionally leaves the reserved delimiter characters ; , / ? : @ & = + $ # untouched, since those are assumed to already be structuring a complete URL. Characters outside the basic ASCII range are first converted to UTF-8 bytes, then each byte becomes its own %XX group. Decoding reverses this with decodeURIComponent or decodeURI, wrapped in a try/catch so malformed sequences produce a readable error instead of a crash.
Component and full-URI decoding both accept either style of encoded input; choose the encode mode based on what you’re building, not what you’re reading.
Worked example
Encoding “encode / and ?” in component mode gives encode%20%2F%20and%20%3F — every non-alphanumeric character is escaped. The same text in full-URI mode gives encode%20/%20and%20?, leaving the structural / and ? alone and only escaping the spaces. Non-English letters expand based on their UTF-8 byte count: Ω (Greek omega, 2 bytes in UTF-8) becomes %CE%A9, and β (Greek beta) becomes %CE%B2. Decoding either result returns the exact original text.
Reserved vs. unreserved characters
Per RFC 3986, unreserved characters never need encoding in any context: A–Z a–z 0–9 - _ . ~. Reserved characters have special meaning as URL structure — : / ? # [ ] @ (the “gen-delims”) and ! $ & ' ( ) * + , ; = (the “sub-delims”) — and only need encoding when used literally as data rather than as a delimiter. That’s exactly the line between the two modes above: component mode treats all reserved characters as data and escapes them, while full-URI mode assumes they’re already doing their structural job and leaves them alone.
Common mistakes
- Using full-URI encoding on a single query value that itself contains & or = — those will be misread as separating parameters.
- Double-encoding a string that’s already percent-encoded, turning %20 into %2520.
- Assuming a + means space in every context — that’s only true for form-encoded query strings, not general percent-encoding.
- Manually editing an encoded string and breaking a %XX group, which then fails to decode.
Where it is used
- Building query strings and API request URLs with user-entered text.
- Passing special characters (spaces, &, #, non-English text) safely inside links.
- Debugging why a URL parameter isn’t being read correctly by a server.
- Preparing text for embedding in HTML href attributes or redirect URLs.
Frequently asked questions
What's the difference between the component and full-URI modes?
Component mode (encodeURIComponent) escapes everything except letters, digits, and - _ . ~ — meant for a single query parameter or path segment where / : ? & would otherwise break the URL structure. Full-URI mode (encodeURI) also leaves reserved delimiters like / : ? # & alone, since it assumes you’re encoding an entire URL that should keep its structure intact.
Why is a space sometimes %20 and sometimes a plus sign?
Percent-encoding (RFC 3986) always uses %20 for a space. The + for space convention comes from an older, separate standard (application/x-www-form-urlencoded, used in HTML form submissions and query strings), not from percent-encoding itself. This tool always produces %20, which is correct in both contexts.
How are non-English characters like Ω or β encoded?
Any character outside the basic unreserved set is first converted to its UTF-8 byte sequence, then each byte is written as %XX in hexadecimal. Ω is one Greek letter but two UTF-8 bytes, so it becomes %CE%A9; β becomes %CE%B2. Multi-byte encoding is why some single characters expand into two or three %XX groups.
Why did decoding fail with an error?
Decoding requires every % to be followed by exactly two valid hexadecimal digits, and any multi-byte sequences must form complete, valid UTF-8. A stray % (like a literal percent sign that wasn’t itself encoded as %25), a cut-off sequence, or a mismatched byte count will make the browser’s decoder throw a “URI malformed” error — this tool catches that and reports it instead of crashing.
Does this need an internet connection?
No. Encoding and decoding run entirely in your browser’s built-in JavaScript functions — no data is sent anywhere, so it works offline once the page is loaded and is safe for text you’d rather not transmit.