Security and architecture
How the system works, what it guarantees, and what it does not.
A tamper-evident access log.
Every access event is hashed and chained to the one before it, in a ledger kept per gate. Editing a past record breaks the chain, which is what makes the log checkable.
Zero-knowledge payload
The browser encrypts the destination URL, or the file itself, before it leaves the device, and our servers store only the ciphertext. The key travels in the link fragment, which browsers never send to a server. Anyone holding the full link holds the key.
- Algorithm
- AES-256-GCM
- Key location
- Link fragment only
- Server access
- Ciphertext only
- Scope
- Payload, not the access log
Access log
When a recipient opens a link, ten values are recorded together and hashed into the gate's chain: who, when, from where, which file, and the exact terms or notice they were shown. If the link has terms, accepting them is the signature. A later edit to any one of them breaks verification.
- Signer email and IP
- Hashed as ciphertext
- Timestamp
- UTC, microsecond
- Terms or notice shown
- SHA-256 of the exact text
One ledger per gate
Each link keeps its own hash chain rather than sharing one global ledger, so every record links only to earlier records on that same document. Archiving or deleting a link leaves the integrity of the others intact.
- Hash function
- SHA-256
- Architecture
- Isolated per-gate chains
- Output
- Verifiable audit log
Integrity demo: a SHA-256 hash chain
A tamper-evident access log.
The access log is append-only, and each record is hashed together with the one before it. Edit a historical record and every hash after it stops matching, as below. On its own that catches an edit, not a rewrite: anyone able to rewrite the whole table could recompute the later hashes too. So each chain is also copied to separate write-once storage, and a scheduled job re-checks the live records against those copies. A rewrite has to disagree with a copy it cannot reach. Each daily copy now also carries a qualified electronic timestamp (eIDAS Art. 41) over its exact contents, which the same job checks: a copy changed afterwards no longer matches it.
Architecture
Genesis seed — sha256(gate id)
2af6f231702098d477213328551d3599b9b8316dc05874b6407446c69ceff48a
Derived from this gate's id, so no other gate's chain can start here.
Hashed together, in this order
SHA-256 of the ten values above, joined by “|”
717fa72d6406582319c7238b36c4f26010e6b687f26f85770dfbdf0b2f0928e7
Hashed together, in this order
SHA-256 of the ten values above, joined by “|”
4b8f9020da15f3222ff926ef8624bec1208ac81155de0ad660644931f578e7c2
Hashed together, in this order
SHA-256 of the ten values above, joined by “|”
77985ea970e135c0bc15ec5c722a6cc2086d4e142fe3884e377fe39b4e7e2666
The records are invented, the hashes are not. Each digest above is the real SHA-256 of the ten values shown in that block, in that order, joined by “|”. Copy them out and check for yourself.
“Can SignToSee view what I am sharing?”
No. We can read the access log, not what you share.
The destination URL and any file you upload are encrypted in your browser before they reach us, so we cannot read them. The access log is a different matter: we can read who opened what and when, because that record is the evidence. Here is exactly where the line falls.
1. You paste your destination URL
Your Figma, Notion or Drive link, or a PDF. Your browser generates a random encryption key, which does not leave your device at this point.
2. Encryption happens in your browser, before anything leaves
AES-256-GCM runs in your browser and turns the URL or file into unreadable ciphertext. Only the ciphertext travels to our server; the key does not.
3. Our server stores only the ciphertext, never the plaintext
This is what sits in our database. Without the key, it can't be read.
4. The key lives in the URL fragment, the part the server never sees
The link you send to your client has two parts. The browser knows about both. The server only ever receives what comes before the #: the fragment is a browser-only mechanism defined in the URL standard.
5. After the recipient confirms their email (and accepts any terms), the key is used — in their browser
The recipient's browser reads the key from the fragment, decrypts the content, and opens the file in the viewer or forwards them to your link. Decryption happens in their browser, so our servers never see the destination.
Result: we hold no key to the payload
This applies to both links and uploaded files: we store the ciphertext, never the key. A disclosure request reaches only what we actually hold, which is the ciphertext and the access log. The access log is readable to us by design, and it contains the recipient's email, their IP address and the terms or notice they were shown.
Terminology explained
The terms used across this site, in plain English.
Zero-knowledge (payload only)
Applies to the payload: the destination URL and any file you upload are encrypted in your browser, and the key stays in the link fragment, which browsers never send to a server. We store and serve only ciphertext. It does not apply to the access log, which we can read.
AES-256-GCM
Advanced Encryption Standard with a 256-bit key in Galois/Counter Mode. An authenticated cipher: it keeps the payload confidential and detects modification, so altered ciphertext fails to decrypt rather than decrypting to something wrong.
Envelope encryption and crypto-shredding
Each signer's email and IP is encrypted under a key unique to that signer and that customer. Those keys are themselves encrypted under a master key held only in the running server's environment. Destroying one signer's key makes their data permanently unreadable without touching anyone else's. The hash chain is unaffected, because it covers the ciphertext, which stays exactly where it is.
SHA-256 hash chains
Each new record is linked to the one before it with the SHA-256 algorithm, so every link you share has its own unbroken, tamper-evident history.
Passkeys and two-step sign-in
A sender can add a second step after their password: a passkey, unlocked by the device's fingerprint, face or PIN, or a six-digit code from an authenticator app. A passkey can also sign in on its own. It is optional, and off until the account owner turns it on. Every change to it needs the password and is emailed to the owner.
Standards and frameworks
The European rules this product operates under, and what it does about each.
eIDAS Regulation No 910/2014
Art. 25, legal effect
When a link carries an agreement, accepting it meets the definition of a Simple Electronic Signature. Art. 25(1) prevents a court from dismissing one solely because it is electronic; it does not fix its evidential weight.
The access log
What we can read
Signer email, IP and the identity details they enter are encrypted at rest under a key we hold, so we can decrypt them; the user agent, timestamps, the customer's own terms text and the hash chain are stored in the clear. This is deliberate: a record nobody can read is not evidence.
Erasure
What we keep, what we destroy
The access record is append-only and retained for the establishment, exercise or defence of legal claims, which Art. 17(3)(e) permits. The signer's identity inside it is kept for 10 years after their last access record with that customer, or until a valid erasure request or the customer deletes their account, whichever comes first, unless a legal hold for a specific dispute covers it. It is not stored in the open: their email, IP address and any company, representative, address and registration details they entered are encrypted under a key unique to that signer and that customer, and on a valid erasure request we destroy the key. The record stays verifiable and the accepted terms stay readable; the identity becomes unreadable, including in the executed agreement, which is assembled on demand rather than stored. Copies already emailed at signing cannot be recalled.
Hosting in the EU
EU data residency
All servers are physically located in the EU and operated by EU-incorporated providers. We do not use US hyperscalers for core hosting.
Check it on
your own link.
The encryption described here runs in your browser. Share a link for free and inspect it yourself.
Start on the Free plan. No credit card required.