Why identical-looking text can have different hashes

Try the exact sample files

Download abc.txt (3 bytes) and abc-lf.txt (4 bytes). Select each in File mode and compare the SHA-256 result with the examples below. The second file has one LF newline (0a); neither file has an encoding marker. These are harmless practice files, not reference values for your own downloads.

A text hash starts with bytes

A text hash is calculated from encoded bytes, not from the meaning of a sentence. LocalHash's Text mode uses UTF-8. A text editor's saved file can contain extra bytes, including a final newline or an encoding marker, so hashing that file can be a different test from pasting its visible contents.

This distinction matters when reproducing a reference from a script, a configuration file or another calculator. Agree on the exact characters and their encoding before treating a mismatch as an algorithm problem.

Reproduce the three-byte example

Select SHA-256 and switch to Text mode. Type exactly abc without quotation marks, spaces or a final Enter. Choose Generate. The three UTF-8 bytes are 61 62 63 in hexadecimal, and their SHA-256 value is shown below.

Text: abc
UTF-8 bytes: 61 62 63
SHA-256: ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad

Add one line feed and compare again

Now add a single line-feed character after the c and calculate again. In the notation below, \n means that line feed; it does not mean typing a backslash and the letter n. The extra byte is 0a, and the digest changes completely.

Capitalization also changes the input. ABC is a different byte sequence from abc, as is abc followed by a space. A Windows-style CRLF line ending contains two bytes, 0d 0a, rather than the single 0a used in this example.

Text notation: abc\n
UTF-8 bytes: 61 62 63 0a
SHA-256: edeaaff3f1774ad2888673770c6d64097e391bc362d7d6fb34982ddf0efd18cb

Compare files as files

Use File mode when the reference was created from a saved file. Pasting text can discard a byte-order mark or change line endings, so it is not a reliable way to reproduce every byte of the original file. Some Unicode characters can also be represented by different character sequences that look the same on screen.

Use a small known input first when diagnosing an integration. If both tools agree on abc but disagree on a real document, investigate the document's bytes rather than changing algorithms until one result looks plausible. The two examples here provide exact inputs and expected values; they do not imply that arbitrary documents are normalized before hashing.

1. Confirm the algorithm name in both tools.
2. Check the encoding and whether a byte-order mark is present.
3. Check capitalization, trailing spaces, the final newline and LF versus CRLF.
4. For a saved document, calculate from the original file bytes on both sides.

References and further checks

• MDN: UTF-8 text encoding
• NIST: Secure hash families