Convert a string

Use this converter for strings containing percent-u escapes, including older text representations of Chinese characters. Decoding also recognizes %XX values and semicolon-terminated hexadecimal references such as 你. Conversion runs in browser JavaScript without sending the input in conversion requests.

  1. Encode Aé你😀 to get Aé%u4F60%uD83D%uDE00. The A and é remain literal; the emoji uses two UTF-16 units.
  2. Decode %u4F60 or 你 to get 你. A phrase such as left; A becomes left; A, keeping its punctuation and space.
  3. Copy the plain-text result. Editing the input clears the previous output; Clear empties both fields. A decoding error also removes the old result.

Which representation is being read?

%XX values are not decoded as UTF-8 bytes

%E4%F6%FC becomes äöü, with each pair mapped separately to U+00XX. A UTF-8 URL sequence such as %E4%BD%A0 therefore does not become 你 here. Use the URL decoder for UTF-8 percent-encoded text.

Encoding preserves spaces, punctuation, percent signs and all characters up to U+00FF. It is neither a full escape() implementation nor a JavaScript backslash-escape encoder.

References and decoding boundaries

Terminated hexadecimal references are converted directly to Unicode scalar values: A becomes A and 😀 becomes 😀. Surrogate reference values and values above U+10FFFF are rejected. This is not a full HTML parser; named and decimal references stay literal.

For compatibility, the older four-digit form &#x4F60 without a semicolon also decodes to 你, as one UTF-16 unit. It requires lowercase x and exactly four hex digits with no following hex digit; other unterminated references stay literal.

Decoding makes one pass: %25u0041 becomes the literal %u0041. Incomplete percent escapes, uppercase %U and backslash forms such as \u0041 remain unchanged. Legacy %u escapes and unterminated four-digit references retain UTF-16 unit semantics, including isolated surrogates; this tool is not a Unicode validity checker.

Questions About This Format

Is an encode/decode round trip always exact?

No. Literal supported escapes are left untouched during encoding and interpreted on decoding: text containing %41 comes back as A. The input field also normalizes actual CR and CRLF line endings to LF. No Unicode normalization is performed.

Why was this page called UTF-8 to GBK?

That older label did not match the implementation. The retained operation converts textual escapes, not file bytes or character-set encodings. Results that contain HTML tags are displayed as text and are not executed.

Recent tools: