Is my contract uploaded anywhere?

No. The file is streamed and hashed inside your browser, so its contents never leave your machine. Obtaining a trusted timestamp sends exactly one thing: the 32-byte Merkle root of your batch plus a random nonce. A hash cannot be turned back into the document, and because the root covers the whole batch, the timestamp authority never even sees an individual contract's own digest.

What does a proof of existence actually prove?

A proof of existence establishes that the exact bytes you hashed existed no later than the moment the authority signed. Change a single character afterwards and the digest no longer matches, so the proof separates the original from any later revision. It says nothing about authorship, consent, or legal validity — those are different claims and this tool does not make them.

Why is a timestamp from a Timestamp Authority better than a file date?

A file's modification date and a computer's clock are both trivially changed, and so is a screenshot of them. An RFC 3161 authority signs a statement that it saw your digest at a given moment, using a certificate issued for timestamping alone. Verifying that signature needs nothing but the token itself, so the proof does not depend on trusting you, us, or any continuing service.

How can someone else check the receipt?

Open the Verify tab, drop in the receipt and the document, and everything is re-derived offline: the file is re-hashed, the Merkle path is re-climbed to the root, the root is compared with the imprint inside the signed token, and the token's signature is checked against the certificate it carries. No network request is made. The raw token is also attached to the PDF, so it can be verified with OpenSSL instead.

What is the Merkle root for?

The Merkle root commits a whole batch to one 32-byte value, so fifty contracts need one timestamp rather than fifty. Each document keeps a short inclusion path proving it belongs to that batch, and the path reveals only hashes of the other branches — never the other documents. Leaves and interior nodes are hashed with different prefixes so an interior node cannot be passed off as a document.

Can I stamp a document without using a timestamp authority at all?

Yes, in offline mode, and the receipt then says plainly that it is a fingerprint rather than proof of a time, because the only date available is your own clock. The digests are identical either way, so the same documents can be re-stamped with an authority later — dated from when that happens.

Does it check whether the authority's certificate was revoked?

No, and the receipt states that. Revocation checking needs OCSP or CRL lookups, and trust anchoring needs the operating system's root store — a web page has access to neither. What is verified offline is the signature itself, the timestamping extended key usage, the certificate's validity at the stamped time, and that the supplied chain is internally consistent. Compare the certificate against the authority's published one for an independent trust decision.

Documents (0/50)Choose contracts (hashed in your browser)

Proof type

Timestamp Authority

Free community authority. Returns its signing certificate, so receipts verify offline.

Additional digests

SHA-256 (required)SHA-384SHA-512

SHA-256 is what the Merkle tree and the timestamp commit to. The others are recorded alongside it for counterparties whose policy names a different algorithm — one pass over the bytes computes them all.

Matter reference (optional)

Holder (optional)

What leaves this browser

Your documents do not. They are streamed and hashed here. Getting a trusted timestamp sends one request containing the batch's 32-byte Merkle root and a random nonce — about sixty bytes, no filenames, no account. Because the root covers the whole batch, the authority never sees an individual document's own digest.

Add one or more contracts. They are streamed and hashed in your browser — never uploaded — committed to a single Merkle root, and that root is bound to an RFC 3161 trusted timestamp. You get a signed receipt and a PDF certificate that anyone can verify offline.

Choose one or more documents to begin.

Contract Hash Stamper — Cryptographic Proof of Existence

Prove that a contract, NDA or agreement existed in a particular form at a particular moment, without showing it to anyone. The document is streamed and hashed inside your browser, a batch of documents is committed to a single Merkle root, and that root — and nothing else — is bound to a signed timestamp from an RFC 3161 Timestamp Authority. The result is a receipt and a certificate that a counterparty can verify years later, offline, without trusting you or this website.

The chain of custody

Streaming multi-digest — the file is read in chunks through a ReadableStream in a Web Worker and absorbed by incremental SHA-256, SHA-384 and SHA-512. Memory stays flat regardless of file size, so a multi-hundred-megabyte package hashes without exhausting the heap.
Domain-separated Merkle commitment — leaf = SHA-256(0x00 ‖ digest), node = SHA-256(0x01 ‖ left ‖ right). The distinct prefixes are what stop an interior node being passed off as a document. An unpaired node is promoted, not duplicated, so two different batches cannot share a root.
RFC 3161 request — a DER TimeStampReq is built in the browser from the root and a 63-bit random nonce, and relayed to the authority. Public TSA endpoints serve no CORS headers, which is the only reason a relay exists; it carries about sixty bytes and no document.
Verification before trust — the returned TimeStampToken is checked before anything is written into a receipt: the imprint must equal our root, the nonce must be echoed, the CMS signature must verify, the signing certificate must carry id-kp-timeStamping as its only extended key usage, and it must have been valid at the asserted genTime.
Signed receipt — a canonical JSON payload (orilami.poe.v1) holding every digest, every inclusion path, the raw token as base64 DER and the limits of the claim, signed with Ed25519 or ECDSA P-256 via WebCrypto.

Why a Merkle root rather than one stamp per file

Stamping fifty contracts individually means fifty requests and fifty document fingerprints disclosed to the authority. Hashing them into a tree means a single value is stamped, and each contract keeps a short inclusion path proving it belonged to that batch. The path contains only hashes of the other branches, so a document can be proven without revealing — or even naming — the others. One request, fifty provable contracts, less disclosed.

What leaves your browser, exactly

In offline mode, nothing. In timestamped mode, one POST containing a DER TimeStampReq: an algorithm identifier, the batch's 32-byte Merkle root and a nonce. No filenames, no sizes, no account identifier and no document bytes. The relay cannot aim anywhere but a fixed allow-list of authorities, does not log bodies, and does not verify the token — your browser does that, against the nonce and root it generated itself, so a compromised relay could not slip a forged token past it.

What the proof honestly establishes

A proof of existence binds bytes to a time. It establishes that the exact document you hashed existed no later than the authority's asserted moment, and that any later revision is a different document. It does not establish who wrote it, who agreed to it, whether the signatory had authority, or whether the agreement is enforceable — those are claims about people, and no hash can make them. Revocation status is not fetched and the authority's chain is not anchored to an operating-system root store, because a web page has access to neither; the receipt says so in its own signed text rather than leaving it to be discovered.

Verifying without this tool

The PDF certificate carries the signed receipt JSON and the raw .tsr token as file attachments, so the proof survives independently of this site. The token verifies with standard tooling — openssl ts -verify -token_in against the authority's certificate — and the receipt's own signature verifies with any WebCrypto or JOSE implementation after re-canonicalizing the payload (recursively key-sorted, minimal-whitespace JSON, orilami-jcs-v1).

FAQ

Does the contract itself ever get uploaded?

No. Hashing happens in a Web Worker on your device, streamed chunk by chunk, and the plaintext never reaches a network call. The only value that can leave is the batch's Merkle root — a 32-byte hash that cannot be reversed into the document.

Why can't the browser talk to the Timestamp Authority directly?

Public TSA endpoints send no CORS headers, so a browser refuses the request before it is made. A minimal server-side relay forwards the DER request bytes and hands back the response verbatim. It is the only network hop in the tool, and the token it returns is verified in your browser against the nonce and root your browser generated.

What stops the authority — or the relay — returning a token for something else?

The token is verified before it is written into a receipt: the message imprint inside it must equal the Merkle root computed locally, and the nonce must match the one just generated. A token for other content, or a token captured from an earlier exchange, fails both checks and is discarded with a reason shown.

Can I prove one contract from a batch without revealing the others?

Yes — that is what the inclusion path is for. It contains the sibling hashes needed to climb from your document's leaf to the root, which reveals nothing about the other documents beyond the existence of hashed branches. Hand over the one document, its path and the receipt.

How large a file can it hash?

There is no fixed ceiling, because nothing is held in memory. The file is read through a stream and absorbed block by block by an incremental SHA-2 implementation, so the footprint stays flat whether the input is 4 KB or several gigabytes. Progress is reported in bytes as it goes.

Why implement SHA-2 rather than use the browser's own?

The Web Crypto API's digest function is one-shot: it takes an entire buffer and offers no incremental mode. Using it would mean materialising the whole document in memory first, which is exactly what breaks on large files and makes progress impossible. The implementation here is differential-tested against the platform's digest across every message length from 0 to 600 bytes and over many chunk schedules.

Is the PDF a PDF/A archive?

No. It is a portable, branded PDF with the signed receipt JSON and the raw timestamp token attached and a fingerprint QR on the page — not a certified PDF/A-1b file, which would require embedded fonts and ICC/XMP metadata. The certificate never claims PDF/A conformance.

Does verifying cost tokens?

No. Verification is free and offline, including for someone who has never used this site before — a proof nobody else can check would not be worth issuing. Tokens are charged when a receipt or certificate is exported, at 300 per contract covered.

Contract Hash Stamper at a glance

Key facts about Contract Hash Stamper: where it runs, what it costs, what it accepts and produces, and its limits.
Where it runs	Entirely in your browser. Files are never uploaded.
Cost	300 tokens per contract (about $3.00 at the base rate)
Accepts	Any file — contracts, NDAs, agreements, scans, archives. Up to 50 per batch, any size
Produces	A signed proof-of-existence receipt as JSON and a PDF certificate, both carrying the RFC 3161 timestamp token, each document's digests and its Merkle inclusion path.
Batch	Up to 50 files per run.
Account needed	Only to spend tokens. Browsing and previewing are free.
What it does not do	It proves specific bytes existed at a time. It proves nothing about who wrote them, who agreed to them, or whether the agreement is binding.

Common questions

Is my contract uploaded anywhere?: No. The file is streamed and hashed inside your browser, so its contents never leave your machine. Obtaining a trusted timestamp sends exactly one thing: the 32-byte Merkle root of your batch plus a random nonce. A hash cannot be turned back into the document, and because the root covers the whole batch, the timestamp authority never even sees an individual contract's own digest.
What does a proof of existence actually prove?: A proof of existence establishes that the exact bytes you hashed existed no later than the moment the authority signed. Change a single character afterwards and the digest no longer matches, so the proof separates the original from any later revision. It says nothing about authorship, consent, or legal validity — those are different claims and this tool does not make them.
Why is a timestamp from a Timestamp Authority better than a file date?: A file's modification date and a computer's clock are both trivially changed, and so is a screenshot of them. An RFC 3161 authority signs a statement that it saw your digest at a given moment, using a certificate issued for timestamping alone. Verifying that signature needs nothing but the token itself, so the proof does not depend on trusting you, us, or any continuing service.
How can someone else check the receipt?: Open the Verify tab, drop in the receipt and the document, and everything is re-derived offline: the file is re-hashed, the Merkle path is re-climbed to the root, the root is compared with the imprint inside the signed token, and the token's signature is checked against the certificate it carries. No network request is made. The raw token is also attached to the PDF, so it can be verified with OpenSSL instead.
What is the Merkle root for?: The Merkle root commits a whole batch to one 32-byte value, so fifty contracts need one timestamp rather than fifty. Each document keeps a short inclusion path proving it belongs to that batch, and the path reveals only hashes of the other branches — never the other documents. Leaves and interior nodes are hashed with different prefixes so an interior node cannot be passed off as a document.
Can I stamp a document without using a timestamp authority at all?: Yes, in offline mode, and the receipt then says plainly that it is a fingerprint rather than proof of a time, because the only date available is your own clock. The digests are identical either way, so the same documents can be re-stamped with an authority later — dated from when that happens.
Does it check whether the authority's certificate was revoked?: No, and the receipt states that. Revocation checking needs OCSP or CRL lookups, and trust anchoring needs the operating system's root store — a web page has access to neither. What is verified offline is the signature itself, the timestamping extended key usage, the certificate's validity at the stamped time, and that the supplied chain is internally consistent. Compare the certificate against the authority's published one for an independent trust decision.