Skip to content
UniKit

Hash compare

Compare two hash values in constant time: it recognises MD5 / SHA-1 / SHA-256 / SHA-384 / SHA-512 digests written in hex or base64, can ignore case and algorithm prefixes, and diffs many pairs at once with a per-line reason.

Runs in your browserEvery computation happens in your browser — your data never leaves this device.

Comparison options

Comparison uses a self-written constant-time routine: differences are accumulated with XOR and a shorter value is still scanned to the length of the longer one, so the position of the first difference is not leaked through timing. Everything runs locally in the browser and no value is uploaded.

Result

Paste two hash values, then press Compare.

A JS engine cannot give a strict timing guarantee, so treat this as best effort; compare real secrets with a native implementation on the server.

What this tool does

  • A download page lists a SHA-256 checksum: paste the published value and the one you computed locally to confirm the file was not tampered with or truncated in transit.
  • When comparing a stored digest with a submitted one, small differences (case, colon separators, a `sha256:` prefix) are easy to miss — the tool normalises both sides first.
  • Bulk verification: paste dozens of “expected actual” lines and get a per-line match/mismatch verdict with the reason instead of eyeballing every pair.
  • While writing tests or debugging, use it to confirm two digests really are equal — a truncated hash is reported as a length mismatch instead of silently looking different.

Example

Input

Hash A: 2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae
Hash B: sha256:2C26B46B68FFC68FF99B453C1D30413413422D706483BFA0F98A5E886266E7AE

Output

Match; both sides are recognised as SHA-256 (256 bits, 64 hex characters), 64 characters compared, input note “algorithm prefix ignored”

This is SHA-256("foo"): the right-hand value only adds a `sha256:` prefix and upper case, so both normalise to the same string.

Frequently asked questions

Why scan the whole value when the lengths already differ?

Because timing leaks information beyond the return value: bailing out on a length mismatch tells an attacker whether the guessed length was right. This implementation scans to the length of the longer side (padding the shorter one with zeros), accumulates differences with XOR and only looks at the accumulator at the end.

Is this really constant time?

The algorithm is constant time — a fixed loop count with no early return — but a JavaScript engine’s JIT and garbage collector give no strict timing guarantee, so treat it as best effort. Compare real secrets server-side with a native implementation, and prefer a slow hash with a random salt for passwords.

Does it recognise both hex and base64?

Yes. Hex is recognised by character count (MD5 32, SHA-1 40, SHA-256 64, SHA-384 96, SHA-512 128) and base64 — including the base64url alphabet with `-` and `_` — by decoded byte length (16 / 20 / 32 / 48 / 64 bytes). A length that matches no known digest is flagged but still compared.

Do case, colon separators or a `sha256:` prefix change the result?

Not by default: the tool strips algorithm prefixes, `0x`, quotes, and spaces/colons/hyphens inside hex values, then lower-cases hex. base64 is case sensitive and is never lower-cased. Turn off “Ignore hex case” when you need an exact byte-for-byte comparison.

Are the pasted values uploaded anywhere?

No. The comparison is plain string arithmetic in the browser, the page makes no network request and nothing is stored server-side. Reloading the page clears the inputs.

Keywords:hash comparehash checkchecksum compareconstant time comparesha256 comparemd5 compare哈希比对哈希校验摘要比对校验和比对常量时间比较SHA-256 校验

Related tools