SimpleWebUtils
ENKO

Document Workflow

Verify a file checksum with SHA-256

Verify the exact bytes of a downloaded file by comparing its complete SHA-256 checksum with a value from a trusted source.

Written and tested by Published: Reviewed:

How this workflow was checked

For the File Hash & Checksum Generator review, we preserved the source shown in “Verify a known three-byte file” and completed “Select exact file mode” and “Confirm the file identity”. The produced output was compared literally where possible, with “Comparing different algorithms” and “Trusting a checksum from the same unsafe source” checked against the linked failure evidence.

The original bytes 61 62 63 produced the known SHA-256 vector ba7816bf…15ad, and comparisons using another algorithm or altered bytes did not pass.

Open Hash Generator and File Checksum | SHA-256 and MD5

Problem

A file can be corrupted during download, replaced by a mirror, copied incorrectly, or mixed up with another version that has a similar name. A checksum gives you a compact fingerprint, but it only helps if you calculate it from the exact file, use the same algorithm, and compare every character carefully before running or forwarding the file.

Sources and standards

These authoritative references define the formats or security boundaries used in this workflow. Tool-specific verification is documented separately above.

When to use this

  • A release page lists a SHA-256 hash for a zip, tarball, or installer.
  • A backup file was transferred between machines and needs a quick integrity check.
  • A support ticket includes a checksum and you need to confirm whether your local file matches.
  • A teammate shared an installer and you want to confirm it matches the original release before running it.
  • You need an audit note showing which file, source URL, expected hash, and calculated hash were checked.

Steps

  1. Step 1

    Get the trusted checksum

    Copy the SHA-256 value from the release page, vendor documentation, or trusted message before calculating your local hash.

  2. Step 2

    Select exact file mode

    Open the hash generator, choose File, and select the downloaded file itself. File mode reads its original binary bytes without decoding them as text. The browser-memory safety limit is 100 MiB.

  3. Step 3

    Choose SHA-256 and paste the full value

    In the comparison section, choose SHA-256 and paste the complete 64-character hexadecimal checksum. Do not paste a filename, shortened prefix, or checksum for another algorithm.

  4. Step 4

    Generate and read the explicit result

    Select Generate. The tool calculates SHA-256 from the exact local bytes and reports match, mismatch, or invalid format after comparing every character.

  5. Step 5

    Confirm the file identity

    Check the filename, version, platform, extension, and file size against the release notes. A partial download, different build, or extracted copy will produce a different value.

  6. Step 6

    Investigate mismatches

    If the hashes differ, do not run or forward the file. Recheck the algorithm and version, then download it again from the official source.

  7. Step 7

    Record the verified source

    Keep the file name, version, size, official URL, expected checksum, calculated checksum, and date in your release notes or support ticket so the check can be audited later.

Example

Verify a known three-byte file

Input

checksum-demo.bin (exact bytes: 61 62 63)

Output

SHA-256: ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad

Common mistakes

Comparing different algorithms

An MD5 or SHA-1 hash will never match a SHA-256 value. Make sure the algorithm in the tool matches the algorithm listed by the source.

Trusting a checksum from the same unsafe source

A checksum is strongest when it comes from a trusted release page or signed announcement, not from the same unverified mirror as the file.

Hashing the wrong file after extraction

Compare the downloaded archive when the publisher lists a hash for the archive. Hashing an extracted app, installer, or renamed copy will produce a different value even when the download is correct.

Skipping filename and version checks

A matching-looking file name is not enough. Confirm the release version, platform build, and extension before deciding that a mismatch is a security problem.

Comparing only part of the hash

Short prefixes are useful for quick identification, but verification should compare the full SHA-256 string. One different character means the bytes differ.

FAQ

Is SHA-256 better than MD5 for file verification?

Yes. SHA-256 is generally preferred for integrity checks because MD5 is collision-prone and should not be used for security-sensitive verification.

Does a matching checksum prove a file is safe?

It proves the file matches the checked content. It does not prove the publisher is trustworthy or that the original file is free of malware.

Why does the same file sometimes produce a different hash?

Any byte difference changes the hash. Line endings, archive metadata, re-compression, or editing the file will produce a different checksum.

Where should I get the expected checksum?

Use the publisher's release page, signed checksum file, package registry, or official documentation. Avoid comparing against a value copied from an unknown mirror or comment thread.

Can I verify a large file in the browser?

This tool accepts one file up to 100 MiB because browser Web Crypto digest operations are not streaming and must keep the bytes in memory. Use an operating-system checksum command for larger files.

What should I do with a SHA256SUMS file?

Open the checksum list from the publisher, find the exact filename, and paste only its complete SHA-256 hexadecimal value into the expected-checksum field. Keep the signed or official checksum list as evidence of the source.