Base64 encodes bytes, not abstract characters. A text tool must first define how characters become bytes. Base64Lens uses WHATWG UTF-8 for that boundary, so Latin, Cyrillic, accented text and emoji have one explicit byte sequence. It also rejects isolated UTF-16 surrogate units before browser encoding can replace them. On decode, a fatal UTF-8 decoder rejects malformed byte sequences rather than inserting a replacement character that would hide corruption.
UTF-8 creates the byte evidence
The text Hello, мир 🌍 contains ASCII characters, Cyrillic letters and one supplementary-plane emoji. Its UTF-8 bytes are 48 65 6C 6C 6F 2C 20 D0 BC D0 B8 D1 80 20 F0 9F 8C 8D. Encoding those exact 18 bytes as standard Base64 produces SGVsbG8sINC80LjRgCDwn4yN. The output happens to need no equals signs because 18 divides evenly by three. That is a byte-count fact, not a property of the visible character count.
Fatal decoding prevents silent replacement
A Base64 string can be structurally valid and still represent bytes that are not valid UTF-8 text. For example, /w== is valid standard Base64 for the single byte FF, but FF cannot begin a UTF-8 scalar sequence. Base64Lens reports INVALID_UTF8 and clears the previous result. It does not show U+FFFD, guess a legacy character set or reinterpret the byte as a file. This keeps the text-only promise narrow and reproducible.
Round-trip the exact scalar sequence
A reliable text check compares the decoded scalar sequence with the original, including spaces, line endings, combining marks and normalization form. Base64Lens does no trimming, newline conversion or Unicode normalization. Two visually similar strings may therefore produce different bytes and different Base64. That difference is evidence, not an error. Copy the output only after confirming the intended text boundary in the receiving system.