URL Encoder Decoder
Quickly encode and decode URLs with multiple encoding modes
Select Conversion Method
What is URL Encoding?
URL encoding (also known as percent-encoding) is a mechanism for converting characters into a format that can be safely transmitted in a URL. Since URLs can only contain specific characters from the ASCII character set, other characters (such as non-ASCII characters, spaces, and special symbols) need to be encoded as %XX format, where XX is the hexadecimal value of the character. For example: a space is encoded as %20, and the Chinese character 你 is encoded as %E4%BD%A0. URL encoding converts characters into a form that can be safely transmitted inside URLs. Spaces, non-ASCII text, reserved characters, and symbols may be percent-encoded depending on context. The key detail is distinguishing a full URL from a path segment, query parameter, form body, or fragment, because each position has different escaping rules. Double encoding or missing encoding can break links, API requests, signatures, redirects, and search parameters, so the encoded result should match the exact place where it will be used.
How to Use
How to use
- Enter or paste the text to encode/decode in the input box
- Select encoding method: encodeURIComponent or encodeURI
- Results appear automatically, one-click copy or swap input/output
- For decoding, select the corresponding decode method
URL Context
- Use component encoding for query values and path segments; encoding a whole URL with the wrong function can break separators like /, ?, and &.
- When decoding, check for double-encoding such as %2520, which means a percent sign was encoded again.
Use Cases
Technical Principle
URL encoding (percent-encoding) is defined by RFC 3986 §2.1 and transforms characters into %XX format, where XX is the two-digit uppercase hexadecimal representation of the byte value in UTF-8. The RFC defines two character classes: unreserved characters (A-Z a-z 0-9 - _ . ~) that are never encoded, and reserved characters (gen-delims : / ? # [ ] @ and sub-delims ! $ & ' ( ) * + , ; =) whose encoding depends on context — they carry structural meaning in some URL components but are literal data in others. JavaScript provides two built-in functions with different scopes. encodeURIComponent() encodes every character except A-Z a-z 0-9 - _ . ! ~ * ' ( ) — this is the correct choice for encoding individual query parameter values, path segments, and fragment identifiers. encodeURI() additionally preserves the structural characters : / ? # [ ] @ ! $ & ' ( ) * + , ; = and is designed for encoding entire URIs while keeping their syntactic structure intact. The critical distinction is that encodeURIComponent() encodes / and &, which would break a URL if applied to the whole string, while encodeURI() preserves them. Space handling is the most common interoperability trap. RFC 3986 specifies %20 as the canonical percent-encoding for the space character (U+0020). However, the application/x-www-form-urlencoded MIME type (used by HTML form submissions since HTML 4.01) encodes spaces as +. The two are not interchangeable: a server expecting %20 will interpret + literally, and a server expecting + will treat %20 as a literal percent sign followed by 20. The tool uses encodeURIComponent() which produces %20, matching RFC 3986. Users decoding x-www-form-urlencoded payloads (from POST bodies or query strings parsed by legacy middleware) should be aware of this difference. Multi-byte character handling is automatic but worth understanding: the input string is first encoded to UTF-8 bytes, then each byte is individually percent-encoded. A CJK character like '你' (U+4F60) occupies 3 UTF-8 bytes (E4 BD A0), producing %E4%BD%A0. If the server parses with a different charset like GBK, the same character encodes to %C4%E3 (2 bytes), and the decoded result will be garbled unless both sides agree on UTF-8. Double-encoding is another common bug: %2520 means a literal percent sign (%25) followed by 20, indicating the input was already percent-encoded and was encoded a second time. The decode mode catches malformed sequences (incomplete %XX) and surfaces the error rather than silently producing garbage.
- encodeURIComponent vs encodeURI: encodeURIComponent encodes / ? & # and is correct for query values, path segments, and fragments; encodeURI preserves these structural characters and is correct for full URLs — using the wrong function is the single most common URL encoding bug.
- RFC 3986 reserved character sets: gen-delims (: / ? # [ ] @) carry URL syntax; sub-delims (! $ & ' ( ) * + , ; =) may be delimiters or data depending on the URL component — context determines whether a reserved character is percent-encoded.
- Space encoding: RFC 3986 canonical form is %20 (produced by encodeURIComponent); application/x-www-form-urlencoded uses + (HTML form default) — the two are semantically incompatible and mixing them breaks server-side parsers.
- UTF-8 multibyte encoding: '你' (U+4F60) → UTF-8 bytes E4 BD A0 → %E4%BD%A0 (3 percent-encoded octets); the same character under GBK → %C4%E3 (2 octets) — charset agreement between client and server is mandatory for non-ASCII text.
- Double-encoding detection: %2520 decodes first to %20 and then to space — the decode mode's output reveals this pattern; malformed sequences like %ZZ or %2 (incomplete) are caught and reported as errors.
- IRI (RFC 3987): Internationalized Resource Identifiers allow Unicode characters directly in URLs; browsers display the decoded form in the address bar but transmit the percent-encoded UTF-8 form on the wire — the tool's encode mode shows what actually goes over HTTP.
- decodeURIComponent error handling: Passing a string with an incomplete percent sequence (% followed by fewer than 2 hex digits) throws a URIError — the tool wraps the call in try/catch and surfaces the error message rather than silently returning an empty string.
Examples
Encoding Chinese characters (UTF-8 percent-encoding)
Input: 你好世界 (4 CJK characters, 12 UTF-8 bytes)
Output: %E4%BD%A0%E5%A5%BD%E4%B8%96%E7%95%8C
Each UTF-8 byte (E4, BD, A0, ...) becomes %XX
RFC: RFC 3986 section 2.1 defines percent-encoding for URIs
Use: query parameters, path segments, form data submissionEncoding query string separators
Input: name=张三&age=20
Output: name%3D%E5%BC%A0%E4%B8%89%26age%3D20
%3D encodes '=' (delimiter between key and value)
%26 encodes '&' (delimiter between parameters)
RFC: RFC 3986 section 3.4 defines query component reserved charsEncoding a full URL (partial encoding)
Input: https://example.com/search?q=你好&type=web
Output: https://example.com/search?q=%E4%BD%A0%E5%A5%BD&type=web
Note: the scheme, host, and existing separators are NOT encoded
Only the non-ASCII query value is percent-encoded
RFC: RFC 3986 section 3 defines hierarchical URI componentsEncoding space characters (two conventions)
Path segment: %20 (RFC 3986 compliant)
Query string: + (historical HTML form convention)
Example: /search for me -> /search%20for%20me
Example: q=hello world -> q=hello+world
Both decode to the same result; encodeURI uses %20, encodeURIComponent uses %20 for path, + for query in some implementationsFAQ
What does URL encoding do?
Replaces unsafe characters in URLs with % sequences: space → %20, & → %26, # → %23, etc. RFC 3986 lists which characters are safe (alphanumerics plus -, _, ., ~) and which need encoding. Browsers, servers, and HTTP libraries all apply or expect URL encoding at the right boundaries.
What's the difference between encodeURI and encodeURIComponent?
encodeURI keeps URL syntax characters (: / ? # & =) intact - it expects a whole URL. encodeURIComponent encodes those too - it expects one parameter value. The page exposes both modes; pick component-encoding for query parameters and URI-encoding for whole URLs.
Why does space become %20 sometimes and + sometimes?
%20 is the URI standard. + is the legacy convention for the application/x-www-form-urlencoded MIME type used by HTML form submissions. They look the same to most servers but are not strictly equivalent - in modern URLs use %20.
Should I encode Unicode characters?
RFC 3986 only allows ASCII; non-ASCII must be UTF-8 encoded then percent-escaped (中 → %E4%B8%AD). Modern browsers display the Unicode form in the address bar but send the encoded form on the wire. The page does the UTF-8 encoding step automatically.
What characters should never be encoded?
Unreserved characters per RFC 3986: A-Z, a-z, 0-9, -, _, ., ~. Encoding them is technically allowed but produces a different URL string; servers may treat 'a' and '%61' as equivalent or as different depending on canonicalisation rules.
Why does my decoded URL have weird characters?
Likely double-encoded: %2520 decodes to %20, then to space - meaning someone encoded the URL twice. Decode it twice in that case. Some servers double-encode automatically; check your client's encoding behaviour.
Is the encoding done locally?
Yes. encodeURIComponent and decodeURIComponent run in your browser. URLs are not uploaded.