Prove your file existed. Without ever sharing it.

How it works

Four steps, none of which requires sending your file.

1. Fingerprint

   Your browser computes the file’s SHA-256 fingerprint: 256 bits, written as 64 hexadecimal characters. The slightest change to the file changes it completely.

2. Signature

   The service adds the date and time, then signs the whole twice, with Ed25519 and ML-DSA-65.

3. Anchoring and time-stamp token

   IIC TSA immediately issues an RFC 3161 token, a time to the second. OpenTimestamps then anchors, separately, the fingerprint of the file and that of the signed attestation in the Bitcoin blockchain, within a few hours.

4. Verification

   Anyone can check the proof with the file, here or with standard tools.

What it is for

Because nothing is sent, you can timestamp even confidential documents. A few typical uses:

• Design and artwork

  A logo, an illustration or a photo, before showing it to a client or posting it online. If a copy appears later, you can show that your file existed first.

• Contracts and agreements

  The version agreed before signature, or a draft sent for review. You can later show exactly which version existed, and when.

• Source code

  An archive of a project, a release or an algorithm, before publishing it or sharing it with a partner. The code itself stays private.

• Writing

  A manuscript, a screenplay, a thesis or an article, before sending it to publishers, a competition or a reviewer.

• Evidence photos

  Damage, the condition of a rented property, a defect on delivery. The proof shows the photo existed at that date; it does not certify what the photo depicts.

• Projects and research

  A business plan, a pitch deck, research data or a lab notebook, before a meeting, a submission or a disclosure.

In every case, the proof establishes that this exact file existed no later than a given date. It does not establish who created it, nor who owns the rights.

What the proof establishes

This is a simple electronic timestamp, not qualified within the meaning of the European eIDAS Regulation. Under its Article 41, it cannot be refused as evidence solely because it is not qualified; its value is assessed by the court.

Limits and good practice

1. Keep the exact bytes. A photo sent back by a messaging app, a re-exported PDF or a video recompressed by a cloud no longer matches the proof. Keep the original file untouched, with its .verifbox.json. VerifBox keeps no copy and cannot replace either.
2. Come back for the completed proof. Until the Bitcoin anchor is confirmed and saved, you hold a signature and a time-stamp token, not a public anchor. Use the reminder button, then return to Verify and keep the completed proof and the certificate.
3. “Valid” is not “anchored”. A verifier reports each proof separately. The part that survives VerifBox is the completed Bitcoin anchor, re-checked with the OpenTimestamps tools next to the original file. Anchors and the token can be removed from a proof without breaking the signatures: a proof without them is weaker, not forged.
4. The time to the second comes from this company. The IIC TSA token is issued by the same company and is not a qualified time stamp; the Bitcoin anchor gives an upper bound, not a second. The signed time and the token time must agree to within a few seconds: look at it.
5. Not a proof of authorship. Anyone holding a file can time-stamp it, including someone who copied your draft. The proof shows that these bytes existed, not who created them or who owns the rights. Do not present it as a copyright deposit, a notarised act or a qualified time stamp.
6. Publishing a proof publishes the fingerprint. The fingerprint reveals nothing about the content, but anyone who already has the file can link it. For a date that must carry a legal presumption, use a qualified trust service; VerifBox can sit alongside it, not replace it.