Checksum Verifier

Paste your data and an expected checksum to confirm they match. The algorithm is auto-detected from the digest length (MD5, SHA-1, the SHA-2 family, SHA-3, BLAKE2 and BLAKE3), or pick one. Runs entirely in your browser, no server, no sign-up.

Verification result

About this tool

This checksum verifier confirms that a piece of data matches an expected hash, right in your browser. The hashing runs locally in WebAssembly — your input is never uploaded to a server, which makes it safe for sensitive content such as keys, archives, or downloaded files pasted as text.

Software publishers ship a checksum (also called a hash or digest) next to a download so you can prove the file you received is byte-for-byte the one they released — that it was not truncated, corrupted in transit, or tampered with. This tool recomputes the hash of your data and compares it, character for character, with the value you expected.

How it works

  1. Paste your data and the expected checksum.
  2. Leave the algorithm on auto to have it inferred from the checksum's length, or choose a specific one.
  3. The tool reports MATCH or MISMATCH, the algorithm used, and both the expected and the freshly computed digests so you can eyeball any difference.

The expected checksum can be hexadecimal (optionally 0x-prefixed, any case, surrounding whitespace ignored) or standard base64 — both forms are accepted automatically.

Algorithm auto-detection

Each algorithm produces a digest of a fixed width, so the length of your expected checksum narrows down the family:

When several algorithms share a width, auto mode tries each one and reports whichever matched. If you already know the algorithm — common for published download checksums — selecting it explicitly is faster and unambiguous.

Supported algorithms

Tips

FAQ

How does auto mode choose between SHA-256, SHA3-256 and BLAKE3?

It can't tell them apart from the checksum alone — all of them produce a 32-byte digest. So auto mode simply computes every algorithm of that width against your data and reports MATCH with whichever one agreed. If none match, you get a MISMATCH with all the candidates' digests. When you already know the algorithm, selecting it explicitly is both faster and unambiguous.

Why do I get MISMATCH when I'm sure the data is right?

The comparison is byte-exact, so the usual culprits are an invisible trailing newline or spaces picked up when copying, Windows CRLF line endings versus LF, or data that is actually an encoded blob — in that case set Interpret input as to hex or base64 so the raw bytes are hashed instead of the encoded characters. The tool shows both digests so you can compare them directly.

Can the expected checksum be base64 instead of hex?

Yes. Both are accepted automatically: hexadecimal (any case, an optional 0x prefix, surrounding whitespace ignored) and standard base64 — handy for Content-MD5 headers or subresource-integrity-style values.

Is an MD5 or SHA-1 match still meaningful?

For accidental corruption, yes — a matching MD5 still proves the bytes came through intact. But both algorithms are cryptographically broken, so a match is no defense against deliberate tampering; for that, insist on a SHA-256 (or stronger) checksum from the publisher.

Developer & Automation Access

Run it from the terminal

Same engine as this page, headless — via the gizza CLI:

gizza tool verify-checksum "Hello, world!" 'expected=ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad'

New to the CLI? Get gizza →

Open it by URL

Pre-fill and auto-run this tool with query parameters — the names match the API/CLI:

https://gizza.ai/tools/verify-checksum/?text=Hello%2C%20world%21&expected=ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad&algorithm=auto&input_encoding=text

Machine-readable descriptor: tool.json — title + parameters JSON Schema for agents.