Encoding and character sets
What text is hidden in these UTF-8 bytes?
Tools to use
A log contains e3 81 82 rather than readable text. Knowing that it is hexadecimal does not tell you whether three bytes represent one character or several. Decoding needs a character encoding. Text/Bytes uses UTF-8, so start from known text and relate characters, bytes and their written representation.
Encode あ into three bytes
あEncoding gives hex e38182 (grouped here as e3 81 82), binary 11100011 10000001 10000010 and byte length 3. These are different notations for the same bytes: two hex digits or eight binary digits per byte. Display spaces separate bytes; they are not spaces in the original character.
Switch to decode, select hex and paste only the hex bytes, not the surrounding result JSON or field name. It should return あ. Binary decoding instead needs the corresponding eight-bit groups; changing the selector does not convert the input's notation automatically.
Add ASCII, Japanese and an emoji
Aあ😀A is one byte, あ three and 😀 four (f0 9f 98 80), totaling eight bytes. Remove one character at a time to observe the change. Text Counter can compare visible characters, code points, UTF-16 units and UTF-8 bytes for the same input.
Eight bytes need sixteen hex digits, but that does not turn the original data into sixteen bytes. Saving the hex notation as text creates a separate representation with its own size. Distinguish payload bytes from the length of a diagnostic string when considering logs or limits.
Truncating bytes can break a character
e3 81Removing the final 82 leaves incomplete UTF-8, so decoding fails. Appending arbitrary bytes to suppress the error does not recover the original character. If logging or transport truncated the data, return to a source that still has it. Refusing silent replacement helps expose the damage.
An odd number of hex digits or a nonhex character fails before character decoding: it is not a valid byte representation. Check notation first, then UTF-8 validity. This separates transcription errors, truncation and encoding mismatch instead of calling all of them garbled text.
Unreadable bytes are not necessarily encrypted
Decoding here means UTF-8. The tool does not identify and recover compressed data, images, ciphertext or arbitrary encodings. If the source encoding is known, use the character-encoding converter. Obtaining readable-looking text by trying guesses does not establish the correct encoding.
U+3042 is a code point, not the UTF-8 byte sequence e3 81 82. Entering 3042 as hex bytes does not encode あ. Check whether the log field describes character numbers or encoded bytes before selecting the tool.
Invisible line endings still occupy bytes
A is 41; A followed by LF is 41 0a, while CRLF gives 41 0d 0a. They may look similar but differ as hash or signature inputs. Inspect trailing bytes before removing line endings, otherwise the evidence of the original difference disappears.
Record the original text, evidence for UTF-8, notation and expected byte length. Similar appearance does not prove byte equality, while differing bytes can still reflect normalization variants of equivalent text. Separate byte comparison from human-readable equivalence to choose the next investigation.