Encoding research · Version 1.0.0 · 15 October 2026

UTF-8 Bits: A 36-Case Byte Identity Casebook

The same-looking text can have different bits. Check the encoding, the code points and the decoder before calling a round trip lossless.

Here are 36 deliberately chosen cases, tested against Binary Translator and independently recomputed in Python. Every input byte and output is available to inspect.

One letter, two byte sequences

In our disclosed cases, precomposed é is C3 A9 (2 bytes). The canonically equivalent e + combining acute is 65 CC 81 (3 bytes). They may render alike, but a byte comparison will distinguish them.

Precomposed · U+00E9é11000011 10101001C3 A9 · 2 bytes · 16 bits

Decomposed · U+0065 U+0301é01100101 11001100 1000000165 CC 81 · 3 bytes · 24 bits

Unicode normalization defines NFC and NFD to handle canonical equivalence. Our converter does not normalize your input: each of these examples preserves its own bytes. Choosing normalization is a separate operation that may change those bytes.

For a reproducible check, use "\u00E9" and "e\u0301" rather than relying on how a font draws the accent. Count encoded bytes, not visible letters or JavaScript string length.

UTF-8 bits in letters, symbols and emoji

UTF-8 uses one to four bytes per Unicode scalar value. A displayed character can contain multiple scalar values; that is why an emoji sequence can exceed four bytes. ASCII uses one byte in UTF-8. W3C’s encoding guide explains the distinction between a character, its code point and its encoded bytes.

Selected text cases; byte count × 8 gives the encoded bit count.
Input	Code points	UTF-8 hex bytes	Bytes / bits
ASCII A	U+0041	41	1 / 8
Precomposed e with acute	U+00E9	C3 A9	2 / 16
Decomposed e plus acute	U+0065 U+0301	65 CC 81	3 / 24
Euro sign	U+20AC	E2 82 AC	3 / 24
One Han code point	U+4E2D	E4 B8 AD	3 / 24
Single emoji	U+1F600	F0 9F 98 80	4 / 32
Woman technologist ZWJ sequence	U+1F469 U+200D U+1F4BB	F0 9F 91 A9 E2 80 8D F0 9F 92 BB	11 / 88

The woman-technologist sequence U+1F469 U+200D U+1F4BB takes 11 bytes (88 bits): four for the first emoji, three for the zero-width joiner and four for the second emoji. A count of visible symbols would miss that structure.

Try your own non-sensitive example in Text to Binary with 8-bit output. The 7-bit option accepts ASCII only. For the place-value arithmetic, use the manual binary reading guide.

Valid text is not the same as byte identity

23 of these 36 selected byte sequences survived decode → re-encode unchanged; 13 changed. Ten of the changing cases are invalid UTF-8. The other three contain an initial byte order mark (BOM). These counts describe this constructed corpus, not a failure rate for everyday text.

A leading BOM disappears on decoding

EF BB BF 41 is valid UTF-8. The decoder consumes the initial BOM and returns A. Re-encoding gives 41, so byte identity is lost even though the visible letter survives. An interior U+FEFF is preserved; a double leading BOM loses only its first occurrence in this test.

This follows the default TextDecoder BOM handling. A BOM is an encoding signature in UTF-8, not an instruction to swap byte order. See the Unicode BOM FAQ for format-specific considerations.

An invalid byte triggers a whole-input fallback

The single byte E9 is not valid UTF-8 on its own. This site maps it to U+00E9 using a Latin-1 code-point fallback, then UTF-8 encoding produces C3 A9. The fallback makes the byte readable; it does not identify the original encoding or preserve its original bytes.

The rule applies to the entire byte sequence. In the selected case 41 FF 42, all three bytes go through that fallback. It maps byte 80 to U+0080, unlike the Windows-1252 mapping used by the web’s latin1 decoder label. Do not use it as a file-encoding detector.

Inspect all 36 exact round-trip results

Input and re-encoded bytes are hexadecimal; an empty result is shown as ∅.
Case	Input bytes	Strict UTF-8	Re-encoded bytes	Identical?
ASCII A	41	Valid	41	Yes
ASCII word	48 65 6C 6C 6F	Valid	48 65 6C 6C 6F	Yes
Precomposed e with acute	C3 A9	Valid	C3 A9	Yes
Decomposed e plus acute	65 CC 81	Valid	65 CC 81	Yes
Euro sign	E2 82 AC	Valid	E2 82 AC	Yes
One Han code point	E4 B8 AD	Valid	E4 B8 AD	Yes
Two Han code points	E4 BD A0 E5 A5 BD	Valid	E4 BD A0 E5 A5 BD	Yes
Single emoji	F0 9F 98 80	Valid	F0 9F 98 80	Yes
Woman technologist ZWJ sequence	F0 9F 91 A9 E2 80 8D F0 9F 92 BB	Valid	F0 9F 91 A9 E2 80 8D F0 9F 92 BB	Yes
United Nations flag sequence	F0 9F 87 BA F0 9F 87 B3	Valid	F0 9F 87 BA F0 9F 87 B3	Yes
Keycap sequence	31 EF B8 8F E2 83 A3	Valid	31 EF B8 8F E2 83 A3	Yes
Ordinary space	20	Valid	20	Yes
Nonbreaking space	C2 A0	Valid	C2 A0	Yes
Zero-width space	E2 80 8B	Valid	E2 80 8B	Yes
Line feed	0A	Valid	0A	Yes
CRLF	0D 0A	Valid	0D 0A	Yes
Tab	09	Valid	09	Yes
NUL	00	Valid	00	Yes
Leading BOM followed by A	EF BB BF 41	Valid	41	No
Interior U+FEFF	41 EF BB BF 42	Valid	41 EF BB BF 42	Yes
ASCII byte	41	Valid	41	Yes
UTF-8 e with acute	C3 A9	Valid	C3 A9	Yes
Single Latin-1 e with acute byte	E9	Invalid	C3 A9	No
Single Latin-1 NBSP byte	A0	Invalid	C2 A0	No
Byte 80 is not the Windows-1252 euro mapping	80	Invalid	C2 80	No
Byte FF	FF	Invalid	C3 BF	No
Overlong slash encoding	C0 AF	Invalid	C3 80 C2 AF	No
Isolated continuation byte	BF	Invalid	C2 BF	No
Truncated four-byte sequence	F0 9F 92	Invalid	C3 B0 C2 9F C2 92	No
Encoded surrogate	ED A0 80	Invalid	C3 AD C2 A0 C2 80	No
Above Unicode scalar range	F4 90 80 80	Invalid	C3 B4 C2 90 C2 80 C2 80	No
Valid ASCII surrounding an invalid byte	41 FF 42	Invalid	41 C3 BF 42	No
UTF-8 BOM only	EF BB BF	Valid	∅	No
Two BOMs then A	EF BB BF EF BB BF 41	Valid	EF BB BF 41	No
Literal replacement character	EF BF BD	Valid	EF BF BD	Yes
Highest Unicode scalar value	F4 8F BF BF	Valid	F4 8F BF BF	Yes

How to diagnose a mismatch

Compare the exact input and output bytes. A copied visible string is insufficient evidence of identity.
Record the intended encoding. A byte such as E9 can be legitimate in another encoding while remaining invalid UTF-8.
Inspect code points for combining marks, non-breaking spaces, line endings and invisible characters.
Check for an initial EF BB BF and decide whether your file format expects a BOM.
If original bytes matter, keep the original byte stream. Do not reconstruct a binary file from a fallback text rendering.

Methods, scope and limitations

We selected 20 text cases and 16 explicit byte sequences to exercise ASCII, accented forms, CJK, emoji, whitespace, BOMs and malformed UTF-8 boundaries. Text cases contain Unicode scalar values; malformed JavaScript surrogate strings and automatic direction detection are outside scope.

Encode text cases with the actual site encodeText function and compare with explicit bytes.
Feed every byte case to actual decodeBinary in strict 8-bit grouping.
Record strict UTF-8 validity separately from the site output and notices.
Re-encode the returned text and compare the exact byte sequence.
Independently validate every row using Python standard-library codecs; UTF-8-sig models the initial BOM removal.

Results come from the site’s conversion core pinned at commit dfd9459db521ad3eab5f8b25afd81b67ab224930. The independent Python verifier checks all 36 rows with standard-library codecs, including initial-BOM removal. Full provenance is in the methods file.

This is a deterministic coverage casebook, not random sampling, a survey or a comparison of competing tools. No visitor input was collected. Rendering varies by font; the code points and bytes are the reference. The site owner produced this research, and the external standards do not endorse its findings.

Download the data and reproduce it

Save the cases, JSON results and verifier in the same folder, then run python3 reproduce-v1.py. No package installation or network connection is needed. The CSV offers the same results for a spreadsheet.

cases-v1.json6,335 bytesSHA-256 23ce72d40fb570b9c50977ec8abb252492600edd13e62202af8f59ab4e7a216c
limitations-v1.md725 bytesSHA-256 fd6a8764e1f9a425c4e8156cdcbc0947c85a4c70fbc21303e8fd46808e7dca29
methodology-v1.json1,949 bytesSHA-256 da616928b1aabd83244b25ec8a61a12b449b4a19bbce91ce16a9078848aa7e30
reproduce-v1.py3,006 bytesSHA-256 b1fcb49ea84b8ef881af11d033c93a1688ae3aa6c04b209f0f17b5773998ac2d
results-v1.csv3,527 bytesSHA-256 81f04ae91a44b0a29342ea57aab9c0dd7965a1b64bb4d2399ceac3e0dbcd99a4
results-v1.json19,532 bytesSHA-256 cdb230da06dd084642d83aa51cd7febe5f8debbf217192a89c26c5e00d423378
sources-v1.json1,569 bytesSHA-256 31a55e7d9bf564f9cad2757435cfb013cfc8f21ca2f88dc082930ac625c117e5

Constructed cases and result tables: CC0-1.0. Verifier: MIT. External standards retain their own licenses. Version 1.0.0 is the initial release; future changes will receive new versioned files and a change note.

To cite a specific result, link to the normalization example or the round-trip results and include “Binary Translator, version 1.0.0, 15 October 2026.” Report a correction through Contact with the case ID and the bytes you expected.

Sources

Character encodings for beginners — Characters, code points and encoded bytes are distinct.
Python Unicode HOWTO — Unicode encoding and normalization background.
MDN TextDecoder — Decoder API, fatal mode and ignoreBOM; links to WHATWG specifications.
Unicode Normalization Forms — Canonical normalization forms; not a promise of visual identity in every font.
WHATWG Encoding Standard — Normative TextDecoder serialization and initial BOM handling.
Unicode UTF and BOM FAQ — A BOM can change byte equality without changing displayed content.

Primary sources checked 15 October 2026. They support the encoding explanation; the downloadable corpus supports the reported counts.