Check whether a document was recorded by PDFengine and when an independent party first confirmed it existed.
This page is a convenience. The proof package that comes with a document verifies offline with standard tools, without PDFengine and without trusting us.
Dropping works too. The proof package carries the expected fingerprint, which is what lets us tell "changed" apart from "never seen".
Only the SHA-256 fingerprint goes into the lookup. Your file is not kept, and the result never names a filename, customer or content.
Bytes, tree and timestamp are reported apart. Anyone contesting a proof wants to know which part holds, not one tick summarising everything.
This is the real check. It runs on your machine, needs only openssl, and does not involve us.
Request the proof package that belongs to the document. It is a ZIP holding these files:
The result must match the sha256 field in proof.json exactly. If it differs, the file was altered or re-saved.
shasum -a 256 your-document.pdf
# Windows:
certutil -hashfile your-document.pdf SHA256
Your document is one leaf in a tree per RFC 6962. Hash a leaf as SHA256(0x00 || digest bytes) and each internal node as SHA256(0x01 || left || right), placing each sibling from sibling_hashes on the side its position field states. A node without a sibling is promoted unchanged and never duplicated. What you end up with must equal root_hash in proof.json.
leaf = SHA256(0x00 || sha256_of_your_document)
node = SHA256(0x01 || left || right)
# repeat with every sibling in sibling_hashes
# until you end up with root_hash from proof.json
From the EU Trusted List or the authority's own publication — not from our package. Checking a token against a certificate that travelled with it proves only that the package is internally consistent. proof.json records the fingerprint of the root we used, so you can confirm you fetched the same one.
For an anchored round you verify the token over the root. If proof.json states an anchor_type other than merkle, skip step 2 and verify the token directly over the document.
openssl ts -verify -digest <root_hash> -in timestamp.tsr \
-untrusted tsa-chain.pem -CAfile <root you fetched yourself>
# separately stamped document (no tree):
openssl ts -verify -data your-document.pdf -in timestamp.tsr \
-untrusted tsa-chain.pem -CAfile <root you fetched yourself>
Careful: re-saving changes the bytes. Even a document you merely open and save in Acrobat gets a different fingerprint, while nobody touched the content. Keep the original file exactly as you received it.
What this check proves: that the document existed no later than the moment shown, in exactly this form, and has not changed since. Not who created it, and not that its content is true.
Usually you are not the author of the document, but the recipient.
There is a code at the bottom of the document. Paste it here and you see when an independent party confirmed this document existed — without having to take the sender at their word.
Bring the proof package along. Then we can tell "this file has been changed" apart from "we do not know this file". Without the package those two look identical.
A lawyer, auditor or judge does not want a web page but a check they can run themselves. Hand over the proof package and point at the steps above.
That the document existed no later than the moment shown, in exactly this form, and has not changed since. Not who created it, and not that its content is true.
No. A SHA-256 fingerprint is computed to run the lookup; the file itself is not kept. A lookup also never shows a filename, customer or content — only anchoring data.
For a bare file we look up the fingerprint. One changed byte — including a re-save in Acrobat — produces a different fingerprint and therefore no record. If you have the proof package or the verification code, use those: with them "changed" can be told apart from "never seen".
No, and that is the point. The proof package verifies offline with openssl, against a root certificate you fetch yourself via the EU Trusted List. This page is a convenience, not a link in the proof.
That the timestamp was issued by a qualified trust service provider on the EU Trusted List. Under Article 41 of eIDAS the date, time and integrity then enjoy the legal presumption of accuracy — the other side has to show it is wrong.
Documents are anchored in rounds. We record your document immediately; the independent confirmation follows in the next round. The real moment of existence is therefore at or before the time shown, never after it.
Yes. The check runs on the bytes of the file, so the file type does not matter. An .eml or .msg works just as well as a PDF, as long as the file is exactly as it was recorded.
They look alike but do not answer the same thing. Here is which one you need when.
| Property | Fingerprint | You are here Proof package | Qualified timestamp |
|---|---|---|---|
| Answers the question | Does this version differ from that one, and in what respect? | Did this file already exist at that moment, and is it unchanged since? | Did this document already exist at that moment — and can the recipient see it straight away? |
| Where the proof lives | In a token and a JSON file you keep yourself. | In a separate ZIP alongside your document, verifiable offline. | Inside the PDF itself, as a PAdES DocTimeStamp. |
| When it is ready | Immediately. | Anchored in the daily run; requesting one stamps immediately. | Immediately. |
| Visible in Acrobat | No. | No. | Yes, green check mark. |
| Works on | PDF, Office, images and email with attachments. | Anything you convert here. | Any PDF you upload, including files from elsewhere. |
| Cost | 1 credit per file. | Included with the conversion; downloading needs a paid subscription. | 20 credits, paid account. |
They do not exclude each other: one document can carry a fingerprint, a proof package and an embedded timestamp at the same time.
Recording, comparing and stamping belong together.