Convert text to UTF-8 bytes
See the exact UTF-8 bytes behind any text — space-separated hex or decimal, in your browser. 中 becomes E4 B8 AD. Free, instant, nothing uploaded.
Paste text and see what it actually looks like on disk: every character becomes its UTF-8 byte sequence, shown as space-separated hex (E4 B8 AD for 中) or decimal (228 184 173). ASCII stays one byte per character, accented letters take two, CJK and other BMP scripts take three, emoji take four — the whole width story of UTF-8, visible at a glance.
This is the reference view for debugging encoding: byte counts against length limits, verifying a file is really UTF-8 rather than Latin-1 wearing the name, building test fixtures, or comparing what a protocol expects with what you're sending. The decimal form matches byte arrays in code and JSON.
Going the other way, the UTF-8-to-text decoder accepts both formats — mixed, with commas, semicolons and 0x prefixes tolerated — and rejects broken sequences honestly instead of substituting garbage. Everything runs locally in your browser tab.
Frequently asked questions
- Why does 中 become three bytes but 🎉 four?
- UTF-8 is variable-width: U+0000–U+007F takes 1 byte, U+0080–U+07FF takes 2, U+0800–U+FFFF takes 3, and everything above (emoji, rare hanzi) takes 4. 中 (U+4E2D) lands in the 3-byte range; 🎉 (U+1F389) sits above it.
- Hex or decimal — which should I use?
- Hex is what hex editors, protocol docs and debugging output show (E4 B8 AD); decimal matches byte arrays in code (228, 184, 173). The converter emits either. The decoder prefers hex when both readings are possible, and falls back to decimal when tokens can't be hex pairs.
- Is this the same as escaping for JSON or URLs?
- No — those are different encodings on top of the bytes. \uXXXX escapes are UTF-16 code units and percent-encoding is a transport wrapper; here you get the raw UTF-8 bytes themselves, which is what files, network payloads and most databases actually store.