b2KIT

Code Signing Verifier

Verify code signatures and integrity hashes for downloaded files. Compare expected vs. computed SHA-256 digests.

Tested tool guide Tested browser tools Checked August 16, 2026

What Code Signing Verifier does, with a checked example

Choose a downloaded file and enter its expected SHA-256 digest. Code Signing Verifier calculates the file's digest in the browser and compares the two values, revealing whether the selected bytes match the published release. The most common mistake is treating a match as proof of publisher identity. It establishes integrity relative to the expected digest, but that digest must come from a trusted source. Verification of an embedded publisher signature is a separate security check.

Worked example

A concrete input and expected output from the current implementation.

Input

Select a file containing exactly the three ASCII bytes abc, with no newline. Enter expected SHA-256: ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad

Expected output

Computed SHA-256: ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad. Result: the digests match.

SHA-256 produces this 256-bit digest for the three bytes 61 62 63. Because the expected and computed 64-character hexadecimal values are identical, the comparison reports a match.

How the result is produced

1

File digest calculation

The verifier reads the selected file's exact bytes and calculates one SHA-256 digest. File contents determine the result, including line endings, archive metadata, and any trailing byte. Renaming an unchanged file does not alter its digest, while modifying even a single byte normally produces a different value. The file remains in the browser during this calculation.

2

Expected digest comparison

A SHA-256 digest is 256 bits, conventionally displayed as 64 hexadecimal characters. The tool compares its computed value with the expected digest entered for the download. Equality means the selected file has the expected byte-level digest. A mismatch means the two values differ, but it does not identify whether the file, expected value, or selected release was wrong.

Good uses

  • Checking an installer against the SHA-256 value published on its official download page.
  • Confirming that a release archive survived transfer, mirroring, or offline storage without changing.
  • Comparing a downloaded executable with a checksum supplied through a separately trusted release channel.

Limits and checks

  • A matching digest is useful only if the expected SHA-256 value came from a source you trust.
  • Version, operating-system, architecture, and packaging variants usually have different digests even when their filenames look similar.
  • Digest equality does not by itself validate an embedded code-signing certificate, its trust chain, or its revocation status.

Common questions

Can a matching SHA-256 result replace verification of an embedded code signature?

No. The digest comparison shows that the file matches the expected bytes associated with the supplied value. It does not, by itself, establish who published those bytes or whether an embedded certificate is valid. For signed executables, use the operating system's signature inspection facilities as an additional check and confirm the displayed signer.

Why does the file fail even though its name and version look correct?

The selected file may be a different build, architecture, package format, or point release. It may also have been altered, incompletely downloaded, or compared with a mistyped checksum. Obtain the expected digest for that exact artifact, then reselect or redownload the file. The mismatch alone cannot distinguish among these causes.

References and verification

The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools