Chinese Character Encoding Lookup (Big5/GB/Unicode)

简繁 EN

About this tool

Unicode, UTF-8, UTF-16, Big5, GBK and GB18030 for any character

Chinese character encoding lookup. Enter any text → per-character Unicode code point, UTF-8, UTF-16, Big5, GBK/GB2312, GB18030 hex, plus HTML entity and decimal code point. Computed locally in your browser — nothing uploaded.

RT-DEV-095 · Developer Tools

Enter Chinese characters / text

Parsed per character — computed locally in your browser; nothing is uploaded.

How to use

Paste or type characters

Paste or type one or more characters in the box — Hanzi, punctuation, ASCII, emoji, or rare extension-block characters all work. The tool splits per Unicode code point, so surrogate pairs (e.g. Ext-B rare characters) stay intact as a single character.

Read the per-character encodings

Each character renders as a card: Unicode code point (U+), UTF-8 bytes, UTF-16 (BE) code units, Big5, GBK/GB2312, GB18030, plus the HTML entity (&#x…;) and the decimal code point.

Understand the Big5 and GB columns

Big5 covers Traditional characters only, so Simplified characters show "not in Big5". GBK/GB2312 covers Simplified plus many Traditional; GB18030 equals GBK (2 bytes) where the character is in GBK, and shows a 4-byte code only for characters outside GBK.

Copy with one click

The Copy button beside each value puts that hex / code point on your clipboard, ready to paste straight into code, a database, or a terminal. Everything is computed locally in your browser.

Chinese Character Encoding: Big5, GB and Unicode, Untangled

For anyone who writes code that touches Chinese text, the classic trap is that the same character is different bytes in different encodings. A single Hanzi is usually 3 bytes in UTF-8, 2 bytes in Big5 or GBK, and its Unicode code point is yet another number. This tool lays out the hexadecimal representation of any character across all of these mainstream encodings at once, so you can cross-check during data migration, mojibake debugging, or protocol integration. Every conversion runs locally in your browser — your text is never uploaded to any server.

Big5 and the GB family: two parallel legacy encodings

Big5 is the traditional encoding for Traditional Chinese in Taiwan and Hong Kong. It only includes Traditional characters and symbols, so Simplified characters simply "do not exist" in Big5 — the tool labels them "not in Big5". On the mainland side sits the GB family: the original GB2312 held only about 6,763 common Simplified characters; GBK is backward-compatible with GB2312 and expands to roughly 20,000 characters, including many Traditional ones; and GB18030 is the mandatory national standard, using a variable-length 1/2/4-byte scheme that covers the entire Unicode range. When a character is already in GBK (2 bytes), its GB18030 encoding is byte-for-byte identical to GBK — only characters outside GBK ever use the 4-byte form. Grasping this compatibility layer explains why so many "GBK files" can safely be read as GB18030.

Unicode, UTF-8 and UTF-16: code points vs. bytes

Beginners often conflate "Unicode code point" with "UTF-8 bytes", but they live at two different levels. A code point is a character's abstract number in the Unicode character set (中 is U+4E2D), while UTF-8 / UTF-16 are concrete schemes for serialising that code point into bytes. UTF-8 uses 1 byte for ASCII and 3 bytes for common Hanzi; UTF-16 uses one 16-bit code unit for Basic-Plane characters and a surrogate pair for supplementary-plane characters (such as rare Ext-B Hanzi). This tool splits input at Array.from code-point granularity, so even a four-byte character that needs a surrogate pair is shown correctly as a single character rather than being chopped in half.

"Mojibake isn't a broken character — it's the wrong decoder." — a lesson every multi-encoding developer learns eventually.

When you reach for a tool like this

Typical situations include: checking bytes while migrating an old Big5 / GBK database to UTF-8; debugging URL-encoding, HTTP-header, or filename mojibake; hand-writing HTML numeric entities (中) for a front-end; or confirming whether a rare character falls inside GBK's repertoire, which decides whether you need GB18030 or should go straight to Unicode. This is a pure front-end developer aid: it calls no model, makes no network request beyond the encoding table, and contains no randomness — the same input always yields the same output, exactly the determinism a trustworthy encoding reference should have.

10 Facts about Chinese Character Encoding

A common Hanzi takes 3 bytes in UTF-8 but only 2 bytes in Big5 / GBK. That is why the same Chinese text has different file sizes under different encodings.

A "Unicode code point" is the abstract number of a character; "UTF-8" is the scheme that turns that number into bytes. U+4E2D is 中's code point, while E4 B8 AD are its UTF-8 bytes.

Big5 only encodes Traditional characters, so Simplified characters do not exist in Big5 at all — saving Simplified text as Big5 simply drops characters or produces mojibake.

GB2312 (1980) holds only ~6,763 common Simplified characters; GBK expands to ~20,000 and is backward-compatible with GB2312; GB18030 covers all of Unicode. The three nest inside one another.

For characters already in GBK, GB18030 is byte-identical to GBK (2 bytes). Only characters outside GBK ever use GB18030's 4-byte form.

GB18030 has been China's mandatory national standard since 2001, required of software sold in China — which is why it covers the whole of Unicode.

UTF-16 uses one 16-bit code unit for Basic-Plane characters and a "surrogate pair" for supplementary-plane ones (like rare Ext-B Hanzi) — which is why some characters "count as two chars".

Counting Chinese characters with string.length in JavaScript can be wrong: a supplementary-plane character has .length 2. Iterate real characters with Array.from() or for...of instead.

The HTML numeric entities 中 and 中 both denote the same 中 — one hexadecimal, one decimal. They reference the Unicode code point, independent of the page's encoding.

The same Hanzi almost always has different bytes in Big5 vs. GBK (e.g. 繁: Big5 C163, GBK B7B1). That is exactly why cross-encoding migration must map character-by-character and cannot just copy bytes.

Frequently Asked Questions

A code point is the abstract number of a character in the Unicode set (中 = U+4E2D); it does not dictate how to store bytes. UTF-8 is one concrete scheme for encoding that code point into bytes — 1 byte for ASCII, 3 for common Hanzi. The same code point has different bytes in UTF-8, UTF-16, and UTF-32, yet all point to the same character.
Big5 is the legacy Traditional-Chinese encoding; it only contains Traditional characters and symbols, with no Simplified characters at all. So when you enter a Simplified character (or certain rare / extension-block characters), the Big5 column shows "not in Big5", meaning the character has no Big5 code. Such characters should be stored in GBK, GB18030, or UTF-8.
GBK is a fixed 2-byte encoding holding ~20,000 characters. GB18030 is variable-length (1, 2, or 4 bytes), covers all of Unicode, and is China's mandatory national standard. The key point: for characters already in GBK, the two are byte-identical; only characters outside GBK use GB18030's 4-byte form. This tool shows a dedicated GB18030 value in that 4-byte case; otherwise it matches GBK.
BE means Big-Endian — the high-order byte comes first. The tool shows UTF-16 code units (one 16-bit unit per group, e.g. 中 is 4E2D) written big-endian. On a little-endian (LE) system the byte order is reversed (2D4E). Basic-Plane characters are one code unit; supplementary-plane characters are a surrogate pair of two units.
Yes. The Unicode code point, UTF-8, UTF-16, HTML entity, and decimal columns work for any character, including ASCII letters, punctuation, and emoji. The Big5 / GB columns only show values for characters in their repertoire; the rest show "not in …". Emoji live in supplementary planes and render correctly as 4-byte UTF-8 and a UTF-16 surrogate pair.
The tool splits your input per Unicode code point and renders a separate encoding card for each character. Splitting uses Array.from, so four-byte characters that need a surrogate pair (e.g. rare Ext-B Hanzi) are treated as a single character and never cut in half. Plain whitespace is skipped so it does not create empty cards.
No. All encodings (Unicode, UTF-8, UTF-16, entity, decimal) are computed locally in your browser with JavaScript. The only network request is a one-time, cacheable download of the Big5 / GB lookup table (encmap.json) used to look values up — your text itself never leaves your device.
It degrades gracefully: the Unicode code point, UTF-8, UTF-16, HTML entity, and decimal columns still work (they are computed locally in JS and need no table). Only the Big5, GBK, and GB18030 columns become temporarily unavailable, with a notice above the results that the table failed to load. Refreshing the page usually recovers it.
Because the same character almost always has different bytes across encodings (繁 is C163 in Big5 but B7B1 in GBK). Reading Big5 bytes as if they were GBK or UTF-8 produces mojibake. The correct approach is to decode bytes to Unicode characters using the source encoding, then re-encode with the target — and this tool lets you verify the mapping at every step.
No. HTML numeric entities (hex 中 or decimal 中) reference the Unicode code point, independent of the page's declared charset. This means you can represent any Unicode character with an entity even on an ASCII-saved page — handy in email templates, config files, or environments where you cannot type Chinese directly.

Related News

You may be interested in these recent stories from our newsroom.

View all news →

Chinese Character Encoding Lookup (Big5/GB/Unicode)