One visible letter, two sequences
The word Café can contain a single composed é, U+00E9, or an e followed by a combining acute accent, U+0065 U+0301. Many fonts draw them similarly. In UTF-8 the composed é uses bytes C3 A9, while the decomposed ending uses 65 CC 81. SHA-256 hashes the input bytes, so these two spellings give different digests even though a reader may see the same word. This is not a hash failure. It is a mismatch between visual comparison and byte comparison. Preserve the source form when investigating an unexpected digest.
Normalise under an explicit agreement
Unicode NFC composes eligible sequences into a canonical form; NFD decomposes them. If two systems agree to normalize to NFC before encoding as UTF-8 and hashing, the two Café spellings in the example reach the same canonical byte sequence. The embedded NFC tool lets you test the decomposed input. The order matters: normalise characters, encode those characters to UTF-8 bytes, then hash the exact bytes. Hashing first destroys the information needed to reconcile equivalent spellings. Document the normalization form in the data contract so every participant performs the same operation.
- Café: composed é or e + accent
- NFC → one chosen character sequence
- UTF-8 bytes → SHA-256 digest
Do not normalize everything blindly
Normalization can change the exact source text, and the compatibility forms NFKC and NFKD make broader substitutions than NFC and NFD. That may be useful for a search index but inappropriate for a legal transcript, a digital signature over an existing document or a system that promises byte-for-byte archival. Case folding, trimming spaces and changing line endings are additional choices, not automatic parts of NFC. A protocol’s specification may demand the original bytes or define a different canonicalization procedure. Follow that rule instead of applying normalization after discovering a mismatch.
Check the bytes with a controlled test
Create two short strings: one with composed é and one with e plus the combining mark. Run each through the UTF-8 byte viewer and note C3 A9 versus 65 CC 81 at the end. Hash the raw strings separately; their digests should differ. Then apply NFC to each, inspect their bytes again and compare the SHA-256 digests. Keep an eye on spaces, newlines and hidden characters in copied input, which can also change a digest. The test should compare identical algorithms and encodings; a SHA-256 value cannot be compared directly with SHA-512.
Choose the comparison you actually need
For a file-integrity check, hashing original bytes is usually the point: any byte change should be visible. For deduplicating human-entered names, a documented text normalization policy may make sense before hashing, though names also have case and language issues that a single Unicode form does not solve. For passwords and authentication, dedicated security designs govern normalization and password hashing; a plain SHA-256 of a password is not sufficient storage. State whether the goal is byte identity, normalized text equivalence or human similarity. These are different promises, and no converter can infer the intended one from appearance alone.