UTF-8 maps each Unicode scalar value to one unique sequence of one, two, three or four bytes. ASCII stays byte-for-byte compatible, while larger values distribute their bits across a leading byte and continuation bytes. This variable width is why the same number of scalar values can occupy different storage or protocol sizes. UnicodeLens calculates the sequence directly after validating the scalar.
The scalar range selects the byte count
U+0000 through U+007F uses one byte. U+0080 through U+07FF uses two, U+0800 through U+FFFF uses three except that surrogates are excluded, and U+10000 through U+10FFFF uses four. The first byte identifies the sequence length; later bytes begin with the continuation pattern. UnicodeLens prints every byte as two uppercase hexadecimal digits, preserving leading zeroes and using one space between bytes.
A, Ć© and š occupy 1, 2 and 4 bytes
The reviewed tuple AĆ©š makes the width change concrete. A is U+0041 and byte 41. The precomposed Ć© is U+00E9 and bytes C3 A9. The emoji is U+1F600 and bytes F0 9F 98 80. Together they contain three scalar values, four UTF-16 units and seven UTF-8 bytes. Copying the aggregate byte sequence yields exactly 41 C3 A9 F0 9F 98 80.
Byte evidence does not identify visual meaning
A valid UTF-8 sequence proves only the encoded scalar sequence. Fonts can render the same scalar differently, several scalars can combine into one perceived symbol, and canonically related spellings can use different bytes. UnicodeLens therefore reports representation rather than calling the byte count a character count, display width or security result. Use the destination system and a pinned Unicode data set for properties outside this narrow conversion.