CRLF vs LF Hash – Why Line Endings Change SHA-256

Local only

Explain why Windows CRLF and Unix LF text produce different digests.

12 chars · 2 lines

Waiting for input

Loading hash algorithms…

Cross-platform hash mismatches

Why do CRLF and LF produce different hashes?

Windows-style CRLF uses two control characters while Unix-style LF uses one. The visible lines can be identical while the underlying bytes, and therefore their hashes, differ. This tool is free to use. No account or payment is required.

Last updated

What you can do here

  • MD5 text digests
  • SHA-1 text digests
  • SHA-256 text digests
  • SHA-512 text digests
  • Exact text byte sensitivity
  • Browser-local hashing

Steps

  1. Inspect the file's line-ending convention.
  2. Normalize CRLF/LF only if your workflow defines a canonical form.
  3. Hash the normalized or original bytes consistently on every system.

Line endings are bytes, not display-only formatting

CRLF is carriage return plus line feed; LF is line feed alone. Hash functions see that byte-level difference even when editors render both as a normal new line.

CRLF vs LF SHA-256

Both inputs display as two lines but use different line-ending bytes.

Input comparison

CRLF: hello\r\nworld
LF: hello\nworld

SHA-256 digests

CRLF: 4739e65e5ea45fcd394e1ca6dc39e603f59fb6cf3f4f31fc7b6a1f6c4715be8e
LF: 26c60a61d01db5836ca70fefd44a6a016620413c8ef5f259a6c5612d4f79d3b8

Common questions

Frequently asked questions

Can Git change file hashes by normalizing line endings?

Line-ending normalization changes bytes, so a hash of working-tree text can differ from another representation when CRLF and LF are converted.

Should I normalize line endings before hashing?

Only if the format or protocol defines normalized text as the data being hashed.

Debugging a specific Hash issue? Browse Hash troubleshooting.