How hash compare works
Verifying integrity usually means comparing a digest you computed locally against one published by a download page, a package manager or a colleague. Reading two 64-character strings by eye is error-prone — one transposed character looks almost identical — so this tool does the comparison for you and returns a clear match or mismatch verdict, along with the details that explain the verdict.
Before comparing, both inputs are normalized the same way: surrounding whitespace is trimmed, an optional algorithm prefix such as sha256: or md5= is removed, a 0x prefix is dropped, and spaces, colons, dots and dashes used as visual separators are stripped. Letters are lowercased, because hex case carries no meaning. Only after normalization are the two strings compared character by character using an XOR-fold that reads every position, so the same amount of work happens whether the hashes match or not — and the output keeps a constant shape in every case: verdict, lengths, algorithm families and the normalized values, with no partial-match hints.
The tool also identifies the likely algorithm of each digest from its length: 32 hex characters suggest MD5, 40 SHA-1, 64 SHA-256 (or SHA-512/256), 96 SHA-384 and 128 SHA-512. If the two sides have different lengths they cannot be the same digest, and the verdict says so immediately. That makes the tool a quick sanity check when two sources publish hashes in different formats — one upper-case with colons, one lower-case without — and you need to know whether they really agree.