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.
Chinese Character Encoding Lookup (Big5/GB/Unicode)
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 is a Traditional-Chinese encoding, so MOST Simplified-only characters show "not in Big5" — but not all of them: 万, 与, 厂 and 气 have Big5 code points, and this table lists them. GBK/GB2312 covers Simplified plus many Traditional. GB18030 covers the whole of Unicode, so it always has a value: 1 byte for ASCII, byte-identical to GBK (2 bytes) where the character is in GBK, and 4 bytes for everything outside it — each value is tagged with which of the three you are looking at.
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 is built around Traditional characters, so most Simplified-only forms are absent and the tool labels them "not in Big5" — though the common claim that Simplified characters do not exist in Big5 at all is too strong, and this table is the evidence. 万 (C945), 与 (C94F), 厂 (C944) and 气 (C961) all have Big5 code points. Others, such as 几 and 儿, are in Big5 as Traditional characters in their own right and merely happen to double as Simplified forms. 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 is built around Traditional characters, so most Simplified-only forms are absent and saving Simplified text as Big5 drops characters or produces mojibake. The stronger claim that Simplified characters do not exist in Big5 at all is wrong: 万, 与, 厂 and 气 have Big5 code points, and 几 and 儿 are Big5 Traditional characters that happen to double as Simplified forms.
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.
GB18030 is variable-length: 1 byte for ASCII, byte-identical to GBK (2 bytes) for anything already in GBK, and 4 bytes only for characters outside it — 𠀀 (U+20000) is 95 32 82 36.
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, built around Traditional characters and symbols, so most Simplified-only forms are absent — though not all of them: 万, 与, 厂 and 气 have Big5 code points, and 几 and 儿 are Big5 Traditional characters that happen to double as Simplified forms. When a character really is outside the repertoire the Big5 column shows "not in Big5", meaning it has no Big5 code. Store such characters in GBK, GB18030, or UTF-8 — GB18030 always has a code for them, because it covers the whole of Unicode.
-
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 computes whichever of the three forms applies and labels it: enter 𠀀 (U+20000, an Ext-B character outside GBK) and the GB18030 column reads 95 32 82 36 while Big5 and GBK both read "not in".
-
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. An ASCII letter is the same single byte in all three (A is 41), because Big5, GBK and GB18030 are all ASCII-compatible. Beyond ASCII, the Big5 and GBK columns only show values for characters in their repertoire and read "not in …" otherwise, while the GB18030 column always has one, because GB18030 covers the whole of Unicode — 4 bytes for a supplementary-plane character such as an emoji. Emoji also 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). The Big5 and GBK columns become temporarily unavailable, with a notice above the results that the table failed to load. Only GB18030's 2-byte case depends on the table: its 1-byte ASCII form and its 4-byte form for characters outside GBK are computed from the standard's own formula and are unaffected. 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.
-
One Generated Prompt Beat Up to 63 Per Cent of a Top Conference's LLM Techniques
A University of Virginia team reproduced 35 ICSE 2026 techniques and outperformed 37 to 63 per cent of them with a single prompt to a newer...
-
The Sixth Exploited Langflow Flaw This Year Is Not a Vulnerability Story
VulnCheck has recorded 360 attacks on a Langflow flaw fixed in January. It is the sixth separately identified Langflow vulnerability exploit...
-
Broadcom Already Maintains Spring and RabbitMQ. Now It Will Sell You Clean Builds.
A reproducible build proves the binary matches the source. It says nothing about whether the source is safe, which is where the damaging inc...
Method & sources
How it computes
For each character the tool reports its Unicode code point, its UTF-8 bytes, its UTF-16 big-endian code units with surrogate pairs kept intact, its Big5 bytes where the character exists in Big5, its GBK/GB2312 bytes, its GB18030 form — two bytes where that equals GBK, four where it does not — plus the HTML numeric entity and the decimal code point. The Unicode and UTF forms are computed in the browser; the legacy encodings come from a compiled table of 20,902 characters.
What this tool implements
- UTF-16 is reported as code units with surrogate pairs left intact rather than collapsed, because a character outside the Basic Multilingual Plane is two units and pretending otherwise is how CJK string bugs start.
- Big5 covers Traditional characters only. A Simplified-only character has no Big5 representation and the tool reports its absence rather than inventing a mapping.
- GB18030 is shown separately from GBK because they coincide in the two-byte range and diverge in the four-byte one; showing only "GBK" hides that a character needs four bytes.
- 20,902 characters are covered — the CJK Unified Ideographs base block. A character outside it returns its Unicode forms without a legacy mapping rather than a guess.
Sources
- The Unicode Standard: https://www.unicode.org/versions/latest/ — code points, planes, and the surrogate mechanism that makes the UTF-16 column non-obvious.
- WHATWG Encoding Standard: https://encoding.spec.whatwg.org/ — the specification of Big5, GBK and GB18030 as implemented on the web, including the index tables these byte values correspond to.
- GB 18030 is the Chinese national standard for character encoding and is mandatory for software sold in mainland China; GBK and GB 2312 are its predecessors, and Big5 is the de-facto Traditional encoding from Taiwan and Hong Kong. The tool reports all of them because a CJK developer still meets all of them.
What can make this go out of date
- The legacy encoding table is a compiled snapshot of 20,902 characters and nothing refetches it. Unicode adds characters with each release; the legacy encodings do not grow, so the gap is in newer characters having Unicode forms and no legacy mapping — which is correct, not missing data.
Pick up where you left off
Stored only in this browser — never sent to our servers.