Sealing a Text

A seal is a device-signed promise about a message or a file: that it existed no later than a certain time, and that it was you who made it. It is not a legal signature.

What a seal proves

New seal opens the create screen directly. A seal holds a message, a file, or both — never nothing.

The reader opens the seal and reads your message. They see your name and your email address, and that nothing was changed. A file stays on your phone: the reader drops their own copy on the verify page, and the page says whether it is the original. Your device encrypts the message, the title and the file name, so we cannot read any of it.

Every seal also gets a description. Only you see it: it is encrypted on your phone, and we cannot read it. It is the name the seal has in your list.

We never send a seal by email, because we cannot read it. Send the link yourself, from the share sheet or your mail app.

Only you can recover a lost link. At link level the decryption key travels only in the link’s fragment; we never receive it and cannot recover or resend it. Your app keeps its own copy of the key, sealed to your account key, so your seals list shows the text and the full link again on every device of your account. Anybody else who loses the link has lost the seal.

Your own seals

The Seals list on the Codes tab shows every seal you made, newest first, by its description. Tap one to see the message, the title, the sealed file with its name, size and the start of its fingerprint, when you sealed it, how it ends, and the link to share, with a QR code.

The phone you made a seal on keeps a copy of its message, title and file name, encrypted on that phone. So it shows them for as long as the seal exists, also after the text was deleted on our side. Another device of your account shows them only while our copy still exists; after that it says Open this seal on the device you made it on to see its text and file name. The copy is lost when you remove the account from that phone or another person signs in on it.

The file itself is never uploaded. Only its fingerprint and size are stored, so the reader needs the same file to check it: they drop it on the verify page.

When a seal ends

You choose it on the create screen, under Ending, for each seal:

• Number of checks — the seal ends after about this many people have opened it. Each browser counts once; opening it again in the same browser does not count. Opening your own seal in the app never counts. Opening your own link in a browser counts like anybody else.
• Valid for — the seal ends after this many days.

Your plan may preselect values; you can change them. When either limit is reached, the seal shows Expired in your list, and the verify page says that it has expired. Its text is deleted at that moment. The seal still proves that it existed, and a reader who has the file can still check it.

The number of checks is “about”: anybody who has the link can use up checks, for example a mail program that opens links to scan them. One network can use up at most five checks of one seal per day; after that the page says Try again later.

A seal with no limit keeps the earlier rule: its text is deleted 24 hours after the first reader opens it, or after 30 days if nobody opens it. The seal then says The text was deleted after the retention period.

Seals marked Identity proof are an older kind. They contain no message and no file, and new ones can no longer be made. Existing ones work until they expire.

Approving a seal on your phone

The desktop client, the command line and MCP can ask your phone to approve a seal before it is signed. The requesting device encrypts the text, the title and the file name to your account. Your phone opens the request, shows you what you are about to seal, and signs only when you approve. We never see the text of a request.

A phone that cannot open a request cannot approve it. The screen then says This request cannot be read on this phone, so it cannot be approved here.

Who is named

Every seal shows the name of the account that made it, and its email address. An organisation’s provider seal shows the organisation’s name and no email address. Seals made before 13 October 2026 without a name now show the name and the email address too.

Because the seal names you, the reader can check the signature on their own device, with no need to trust our server for that check.

In an organisation

A seal made in a business organisation’s context speaks for that organisation. So the organisation must first prove that it owns a domain. Until an administrator has done that, the app refuses the seal and says why: Your organization must verify a domain before you can create seals for it. The domain is verified on the organisation’s Settings, under Public Page.

A seal made in your private context is never affected.

What “recorded” means

A sealed text is anchored into a public transparency log we do not control (Sigstore Rekor), on a short delay — usually about a minute.

A fingerprint of this seal is included in a summary published to the public Sigstore transparency log. The summary proves the seal existed no later than that time. It reveals nothing about the content, the sender or the recipient. trusted.codes checks its own record against that log. No independent party checks it.

While the anchor is still pending, the verification page shows that plainly — it never pretends the seal has been recorded before it has, and a seal is valid and checkable by its own signature from the moment it is made, whether or not the anchor has landed yet.

trusted.codes always knows which account made a seal.

What counts as the same file

A sealed file is checked by its contents only. The reader drops the file on the seal’s page, and the browser compares its fingerprint with the sealed one. Nothing is uploaded.

• No effect: a new name, another folder, another computer, or a different creation, change or opened date. These are not part of the file’s contents.
• The check fails: any change to the contents. This includes saving the file again in an application, even when it looks the same, editing its document properties or picture data, and a mail or chat service that compresses or converts it.

Keep the file exactly as you received it. You can rename it as you like.

If verification fails

If a reader’s device decrypts a seal and the result does not match the seal’s own signed fingerprint, the page shows a clear, unmissable warning and refuses to display the content as trustworthy. Do not act on a seal that fails this check.