Yueser

URL Encode / Decode

Convert Chinese parameters into %E4%B8%AD%E6%96%87, or restore a link that has turned into mojibake.


  
Difference between the two encodings

encodeURIComponent is escaped / ? & = and similar delimiters, which suits a single parameter value;encodeURI keep them — that suits a whole link. The "whole string" option above uses the first method (most common); "encode parameter values only" will ? and & Split apart and handle them one by one.

When to use it

  • A link carries Chinese characters, spaces, or a value holding an already-encoded %26: value-only mode leaves the ? and & separators alone and re-encodes the value once instead of doubling it into %2526, so the link stays clickable.
  • A log, analytics event or email gives you %E4%B8%AD%E6%96%87 and you need readable text — including emoji, whose four-byte UTF-8 sequences decode correctly.

When not to

  • You are building an application/x-www-form-urlencoded body or a string that will be signed, where a space must be +. This tool emits %20, and strict implementations treat the two differently. Use URLSearchParams.
  • You want to encode a whole URL while keeping https:// and the path separators. That is encodeURI; this tool's whole-string mode is encodeURIComponent and turns :// into %3A%2F%2F.
Limits and privacy

Encoding and decoding happen locally in your browser; nothing is uploaded. Limits: it uses the native encodeURIComponent / decodeURIComponent (UTF-8), so a space is %20 and + is not treated as a space; parameter mode only splits on ? and &, ignores the # fragment and does not recognise ; separators; an invalid percent sequence fails the whole decode; the URL is not validated.

Frequently asked

Why does a space become %20 instead of +?

encodeURIComponent follows RFC 3986 and writes a space as %20. Writing it as + comes from the HTML form rules for application/x-www-form-urlencoded. Most frameworks accept either inside a query string, but strict implementations only honour their own: signature schemes, OAuth and some older gateways read + as a literal plus. When you need +, build the body with URLSearchParams rather than replacing characters by hand — a manual replace also damages %2B sequences that were already correct.

Decoding fails with invalid percent-encoding — what now?

decodeURIComponent throws the moment it meets a lone %, a %ZZ, or a truncated sequence such as %E4. There are three usual causes: the link was double-encoded, a chat app cut it off, or the text genuinely contains something like 100%. Check that every % is followed by two hex digits; a literal percent must be written %25. The tool fails as a whole instead of returning a partly decoded string, so you never get output that looks plausible while being misaligned.

One decode still looks garbled — do I need to click twice?

Yes, that means the value was encoded twice, common when a callback URL is nested inside a redirect parameter. Each decode strips one layer: %25E4%25B8%25AD becomes %E4%B8%AD, then 中. Clicking repeatedly works, but know how many layers you are peeling. Better, fix the source so it encodes once: double encoding also makes the meaning of + and & unpredictable during debugging.