File Hash Generator

A checksum comparison has three essential parts: the exact file bytes, the named hash algorithm, and a reference digest obtained through a trustworthy channel. If any one of them differs, the hexadecimal strings should not match.

This makes hashing useful after a download, backup, copy, migration, or evidence handoff. A filename can stay the same while the contents change, and two different files can share a familiar name. A cryptographic hash maps the complete byte stream to a fixed-length digest, so even a small content change normally produces a very different value.

Algorithm names are part of the reference. SHA-256 and SHA3-256 both produce 256-bit digests, but they are different functions and will not produce the same value for one file. Digest length can expose a mismatch in algorithm choice, yet two algorithms may share a length, so the published name must still be checked.

MD5 and SHA-1 remain common in older manifests and archives. They can still identify an accidental mismatch against a required legacy reference, but their collision resistance is unsuitable for new security decisions. SHA-2 or SHA-3 is the safer choice when creating a new checksum workflow and no outside system requires another algorithm.

Salted file hashes are a specialized convention, not the normal format for software release checksums. Adding text before or after the file changes the byte stream and therefore the digest. Both parties must agree on the exact text, UTF-8 encoding, position, and algorithm. This construction is not a password-hashing function, key derivation function, or keyed message authentication code.

A complete comparison is all-or-nothing. Do not compare only the beginning or end of a long digest, and do not dismiss a difference in letter case until confirming that the underlying hexadecimal characters are otherwise identical. One changed hex character means the displayed values do not match.

How to Use This Tool:

Begin with the algorithm named beside the trusted checksum, then hash the exact file object that reference describes.

1. Choose or drop one Source file. If several files are dropped, only the first is used and the remainder are reported as ignored.
2. Select the exact Hash algorithm named by the reference. SHA-256 is the default for a new ordinary check; MD5 and SHA-1 are marked for legacy compatibility.
3. Leave Salt text blank for normal release and download checksums. If an established workflow requires salt, enter no more than 256 characters and match whether its UTF-8 bytes come before or after the file.
4. Wait for 100% completion, then compare every character in the Checksum record with the trusted value. Confirm the filename, file size, algorithm, and salt rule in the verification record before accepting a match.

Interpreting Results:

A matching digest means the complete input byte stream produced the same value under the selected algorithm. Confidence depends on the reference: a checksum copied from the same untrusted download location does not provide independent proof.

• A mismatch should stop the handoff until the file, algorithm, reference, and salt rule are checked again.
• Uppercase hexadecimal changes presentation only. ab12 and AB12 represent the same hexadecimal digits.
• The digest-width profile is a size comparison, not a security score. Equal width does not make SHA-256 and SHA3-256 interchangeable.
• For MD5 or SHA-1, a match can satisfy a legacy checksum requirement but should not be promoted into a new collision-resistant security claim.

Technical Details:

A hash function accepts a byte string of arbitrary length and returns a digest with a fixed width determined by the algorithm. File names and modification times are not included in the hashed byte stream.

Transformation Core:

An ordinary checksum hashes the file bytes directly. Salted modes concatenate UTF-8 salt bytes before or after those bytes.

H is the selected hash algorithm, B is the exact file byte sequence, S is the UTF-8 encoding of the salt text, and D is the hexadecimal digest. The concatenation order is part of the rule.

Files are read in 2 MiB browser chunks and fed to one incremental hash state in byte order. Chunking reduces peak read size without changing the digest because the byte sequence remains continuous. Empty files are valid inputs and finalize the selected algorithm without any file chunks.

Algorithm and Width Map:

Each byte becomes two hexadecimal characters after hashing, so the displayed length is the digest width divided by four. Uppercase mode changes only the letters a to f; it does not recompute a different digest.

Privacy and Security Notes:

The selected file is read and hashed in the browser. Its bytes are not uploaded or placed in the shareable URL; the file remains available only in the current page session for rehashing. Salt text also stays out of shareable page state.

• Large files still require local disk reads and processing time even though they are handled in bounded chunks.
• A checksum match is only as trustworthy as the reference source and algorithm choice.
• MD5 is not appropriate where collision resistance is required, and NIST recommends transitioning away from SHA-1 in favor of SHA-2 or SHA-3.
• A raw salted hash does not provide the protections of a password-specific key derivation function or HMAC.

Worked Example:

References:

• Hash Functions, National Institute of Standards and Technology.
• NIST Policy on Hash Functions, National Institute of Standards and Technology, updated September 9, 2024.
• RFC 6151: Updated Security Considerations for MD5, RFC Editor, March 2011.
• How to check a certificate fingerprint using OpenSSL, Simplified Guide.