URL Encoder / Decoder

encodeURI vs. encodeURIComponent — The One Simple Rule

This is the most confusing part, but the rule is simple: are you working with an entire URL or a piece of a URL? If it's a piece, use `encodeURIComponent`. If it's a whole URL, use `encodeURI`.

The difference is whether it preserves URL structural characters. `encodeURI` sees characters like `:`, `/`, `?`, `&`, `=`, and `#` as part of the URL's syntax and leaves them alone. `encodeURIComponent` assumes they might be part of the value itself and converts them all to `%XX` format. The note at the top of the tool updates to show you exactly what each mode does when you switch between them.

Double Encoding — If You See %25, It's Already Happened

Encoding an already-encoded string will encode the `%` character itself into `%25`. This turns `%EA%B0%80` into `%25EA%25B0%2580`. The result is that the literal text `%EA%B0%80` might show up on screen, or a link will lead to a 404 error.

This tool helps you catch this. In Encode mode, if it sees a `%XX` pattern in your input, it warns that the input appears to be already encoded. In Decode mode, if it sees `%25XX`, it will warn that it looks like double encoding. If you get the latter warning, just click '⇅ Result to Input' to decode it one more time to get the original string.

• Where does it happen? Common scenarios include the front-end creating a value with `encodeURIComponent` and the back-end encoding it again before passing it to another API, or a proxy server in the middle applying another layer of encoding.
• The rule: Encoding should happen only once, at the last possible moment before a value is placed into a URL. Intermediate layers should pass the original, raw string.

Is + a Space or Not?

It depends. This is why the "Space ↔ +" checkbox exists. The official URL standard (RFC 3986) says a space should be `%20`. However, the `application/x-www-form-urlencoded` format, used by HTML forms, represents a space with a `+` sign. As a result, the same search term might appear as `q=cordless%20drill` in some places and `q=cordless+drill` in others.

• When you need a literal `+` sign in the value (like in a phone number `+1` or a formula `1+1`), it must be encoded as `%2B`. If you leave it as a raw `+`, the receiving end might interpret it as a space.
• When decoding with this checkbox on, the tool will convert `+` characters into spaces. Use this when decoding data that came from a form.
• When encoding with this checkbox on, the tool will replace `%20` with `+`. Only enable this when you need to mimic the `x-www-form-urlencoded` format.

Non-ASCII URLs — What Happens with Special Characters

You've probably seen this before: you copy a URL that contains special or non-ASCII characters from a site like Naver or KakaoTalk, and when you paste it, what looked like readable text in your browser's address bar becomes a long string of `%EA%B0%80`... This happens because the browser is just showing you a decoded, user-friendly version; the actual URL is encoded. A single Korean character, like '가' (ga), is 3 bytes in UTF-8, so it expands to three `%XX` triplets, or 9 characters total: `%EA%B0%80`.

The table at the bottom of this tool shows this mapping directly. It lists the Character, its Unicode Codepoint, its Percent Encoding, and its UTF-8 Bytes all on one line, so you can visually confirm that your input is being encoded correctly.

• URL Length: Putting non-ASCII text in a URL can make it grow by 3x or more. This can easily hit the URL length limits (around 2,000 characters) of some browsers, share links, or gateways.
• Can't decode data from an old system? Values encoded in legacy charsets like EUC-KR (e.g., `%B0%A1`) will cause a decoding error in this tool, which assumes UTF-8. As a rule of thumb, if one character is represented by two `%XX` pairs, suspect a legacy Korean encoding like EUC-KR.
• Non-ASCII characters in the domain name itself (e.g., 한글.한국) use a different system called Punycode (e.g., xn--...), not percent-encoding. This tool is for paths and queries, so it does not convert domain names.

When is the 'Strict RFC 3986' Option Needed?

JavaScript's `encodeURIComponent` does not encode five specific characters: `!`, `'`, `(`, `)`, and `*`. While most web servers handle this fine, this discrepancy can cause problems when you need to match the output of a system that strictly follows RFC 3986.

A classic example is API request signing. Some cloud and open APIs require you to calculate a signature based on the encoded string of parameters. If the server expects those five characters to be encoded (as `%21%27`, etc.) but your client doesn't encode them, the signatures won't match, and authentication will fail. This is an incredibly difficult bug to track down.