ITBox

URL encode and decode, handling Chinese and special characters.

Switch tool
encodeURIComponent — encodes all special chars
Input
Encoded

How to use

Purpose

Online URL encoder/decoder (URL Encode / Decode / Percent Encoding) that converts special characters in URLs (CJK, spaces, & ? = /) to %XX form per RFC 3986. Supports full-URL mode (encodes only the query, preserves scheme/host), component mode (encodes the entire string), and double encoding (for nested redirect URLs). Switchable UTF-8 / GBK charsets for legacy backends. All processing local.

Steps

  1. Paste a URL or string into the editor
  2. Pick mode: full URL (smartly preserves scheme/host/path separators) or component (encode everything)
  3. Click Encode for percent-encoded output
  4. Reverse: paste %XX form to auto-decode
  5. Charset: UTF-8 (default, international standard) or GBK (legacy Chinese backends)
  6. Double encoding: for nested scenarios (e.g., OAuth redirect_uri inside another URL)
  7. Batch mode: one URL per line, encode/decode line by line
  8. Quick reference: %20=space %2F=/ %3F=? %3D==

FAQ

Do I need to encode Chinese characters in URLs?
Modern browser address bars auto-encode for display, but in code (fetch/axios/backend routing) you must encode actively, or the URL gets truncated. RFC 3986 says URLs must be ASCII — Chinese must encode per UTF-8 as %E4%B8%AD%E6%96%87 etc.
How is URL encoding different from Base64? When to use which?
URL encoding only replaces unsafe characters with %XX, preserving most ASCII. Base64 encodes all bytes at a 4/3 ratio. URL encoding is for URLs/queries/form data. Base64 is for embedding binary in text (data URLs, JSON file uploads). Not interchangeable.
GBK-encoded URLs come out garbled in UTF-8 decode?
Legacy Chinese systems (some government, banks, early PHP) used GBK URL encoding, e.g. %D6%D0%B9%FA = "中国". Switch charset to GBK to decode correctly. Tell them apart by the first 3 bytes: %E4%B8%AD (UTF-8) vs %D6%D0 (GBK).
Is + a space or a plus sign in URLs?
In the query string (after ?), + means space (per application/x-www-form-urlencoded). Elsewhere in the URL, + is literal. Full-URL mode distinguishes by position. To preserve a literal +, encode it as %2B.
Why does OAuth callback URL look nested-encoded multiple times?
Double or triple encoding. A parent URL with a query containing a child URL must encode the child first. With redirects in between, encoding can go three levels deep. The double-encoding toggle lets you control levels manually — decode iteratively to reveal the original.

Use cases

  • Debugging OAuth redirects: decode nested-encoded redirect_uri to see the real target
  • Frontend URL building: search terms with CJK or special chars must be encoded before going into query params
  • QR code link generation: encode CJK URLs before generating QR so scanners decode correctly
  • Legacy garbled-Chinese triage: detect UTF-8 vs GBK source
  • mailto: subject lines with CJK must be encoded

Use cases

OAuth redirect debug, frontend CJK URL building, QR code link generation, legacy charset triage, mailto subject. Frontend, backend, security, ops. Full-URL smart mode, UTF-8/GBK charset switching, and double-encoding handling are the differentiators.