# What is the SHA-256 fingerprint on a carbon report, and how do I check it myself?

Canonical: https://senseible.earth/answers/verify-sha-256-fingerprint-carbon-report

A SHA-256 fingerprint is a 64 character code calculated from the exact bytes of a file. Change one byte and the code changes completely. To check it, get the original file, run a built-in command such as sha256sum, certutil or shasum, and compare your result with the code on the report. A match means it is the same file.

## The command for each computer

Each prints 64 hexadecimal characters, 0 to 9 and a to f. Upper or lower case does not matter when you compare.

- Windows (Command Prompt): certutil -hashfile invoice.pdf SHA256
- Windows (PowerShell): Get-FileHash invoice.pdf -Algorithm SHA256
- Mac (Terminal): shasum -a 256 invoice.pdf
- Linux: sha256sum invoice.pdf

## Steps to check a report line

1. Ask the supplier for the original file they uploaded: the same PDF or photo, not a printout, a rescan or a copy forwarded through a chat app that recompresses images.
2. Run the command on that file.
3. Compare all 64 characters with the fingerprint in the report or audit export. If the report shows only the first characters, compare those and ask for the full export.
4. Record the result in your working papers.

## What a match proves, and what it does not

- It proves the file you hold is byte for byte the file the figure was calculated from, and that it has not been edited since.
- It does not prove the invoice is genuine or that the quantity on it is right. That still needs normal checks against the vendor, payment and stock records.
- It only catches identical files. A second scan or photo of the same paper invoice has a different fingerprint, so duplicate checks by hash alone will not catch it.

## If the fingerprints do not match

Most mismatches are innocent: the file was re-saved, compressed or exported again. Ask for the file exactly as uploaded. If the supplier cannot produce a file that matches, treat the line as unsupported until other evidence backs it.

## Test the tool on a known value

- Create an empty file and run the command on it
- Every correct SHA-256 tool returns e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
- The three letters abc, with no line break, return ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad

These are the standard test values for SHA-256 under NIST FIPS 180-4; if your tool returns them, it works.

## What Senseible does here

Senseible records the SHA-256 fingerprint of every uploaded source file. Framework reports show the first characters next to each emission line and the audit ledger export carries them in full, so anyone holding the original file can recompute and compare. A fingerprint shows the file is unchanged, not that its contents are true.

- [Making carbon data tamper-evident](https://senseible.earth/answers/how-to-make-carbon-data-tamper-evident)
- [How auditors use Senseible reports](https://senseible.earth/answers/auditors-and-senseible-reports)
- [Duplicate invoices and double counting](https://senseible.earth/answers/duplicate-invoices-double-counting-emissions)
- [Trust and security](https://senseible.earth/trust)

Sources: [NIST FIPS PUB 180-4, Secure Hash Standard (2015)](https://csrc.nist.gov)

Last reviewed 2026-10-15.