Question 1

When do I need to URL-encode something?

Accepted Answer

Any time a string with spaces, `&`, `=`, `?`, `#`, `/`, or non-ASCII characters goes into a URL — usually a query parameter. Without encoding, the server thinks `&` starts a new parameter, or `#` starts a fragment. Encoding rewrites those as `%` escapes that survive the trip intact.

Question 2

What's the difference between `encodeURI` and `encodeURIComponent`?

Accepted Answer

`encodeURI` preserves URL structure (it doesn't encode `/`, `?`, `#`), so it's for full URLs. `encodeURIComponent` encodes aggressively, so it's for individual parameter values. 99% of the time you want `encodeURIComponent`. This tool defaults to that behavior.

Question 3

Why is `+` sometimes a space and sometimes a literal plus?

Accepted Answer

In the query string of an `application/x-www-form-urlencoded` body, `+` means space. In the path portion of a URL, `+` is a literal plus. Which is why `%20` is the safe way to encode a space — it means space everywhere, with no ambiguity.

Question 4

What about emoji and non-ASCII characters?

Accepted Answer

They get encoded as multi-byte UTF-8 sequences — 🎉 becomes `%F0%9F%8E%89`. Browsers, servers, and languages that respect the URL spec will decode them correctly. If your target treats URLs as Latin-1, that's a them problem, not an encoding problem.

Question 5

Is double-encoding a real problem?

Accepted Answer

Constantly. Someone encodes, passes the URL through a middle layer that encodes again, and now `%20` is `%2520`. If decoding once gives you something that still has `%` in it, decode again. This tool just decodes once per click — run it twice if you need to.

URL 編碼/解碼

什麼是URL 編碼/解碼？

相關工具