A freelance consultant emails a final report to a client on a Friday. Three months later the client's finance team asks which version was approved, and the thread turns into a hunt through attachments. The consultant could have ended that hunt before it started, by giving the client a way to verify a signed document online without asking anyone for help. This article walks through what a sealed document's certificate actually offers the person on the receiving end, based on how the product works today, and where that offer stops.
The short answer for the person who sends the file
When you download the certificate for a sealed document, it carries a blue QR code. Scanning it opens a public verification page in any browser. The person who scans needs no account and no login, and the page shows them the signature details straight away. That is the part you can rely on and hand to a client. The part to be careful about is what the page checks, and I cover that below.
What happens when your client scans the code
The QR code encodes a web address that points at one specific sealed record: a folder identifier plus a version identifier. The address opens a page called verify-certificate. That page is a public route, so the app does not send the visitor to a sign-in screen, and the request it makes to fetch the certificate is not behind a login check either. A client who receives your email on a phone can scan the code from a screen or a printout and land on the result in seconds.
What the client sees on the page
The page opens with either "Verification Successful" or "Verification Failed". Success comes with the line that the document has been verified and contains valid digital signatures. Failure says the verification failed or no signatures were found.
Below that, each signature is listed with its type and a "Valid" badge. For a standard signature the client sees the issuer (common name and organization), the signer, the signed date and the expiry date of the signing certificate. The certificate PDF itself is shown on the page, with a button to download it. Nothing on the page asks the client to log in, register or enter an email.
What the page does not tell them
Be exact with your client here, because they will repeat what you tell them. The QR code opens the certificate that the platform holds for that record. It confirms that the certificate's signatures are valid. It does not compare that certificate against the report sitting in your client's inbox. It also does not show who wrote the report or whether its contents are correct, and a seal does not show the file was unchanged before it was sealed. What it supports is narrower and still useful: the sealed record exists, who signed it, and when.
Checking the file the client actually holds
To check the PDF itself, the client uses the public validator. They upload the signed PDF, with no registration or login. It checks the signature chain, the issuing certificate authority, certificate expiry and timestamp integrity, and it shows who signed, when, and with which certificate. If the content was modified after signing, it says so. Only signature metadata is processed, and the document content is not stored. So the two checks answer two questions. The QR page answers "is there a valid sealed record for this?" and the validator answers "is this exact file the signed one?"
Where the link goes in your email
A certificate link belongs to one sealed document, built from that record's identifiers. A standing line in your email signature would point at one deliverable only, so it does not fit a signature. I also found nothing in the product code that promises how long a given link stays valid, so I would not tell a client it works forever. Put the certificate QR or link in the email that delivers each file, next to one sentence of context. The validator address, on the other hand, is one stable public page that does not depend on any record. That one can sit in your signature as a single line, such as "Check any signed document at swisstrustlayer.com/validate".
A short script you can paste
In the delivery email, write something like this: "The attached report is sealed. The certificate is attached too. Scan the blue QR code on it, or open the link below, to see the signer and the signing date on a public page. To check the PDF itself, upload it to the validator. No account is needed for either." Add the link, send, and keep the sealed original and its certificate stored in more than one place yourself, since the seal covers a fingerprint and cannot rebuild a lost file. If your client's lawyer ever asks, the answer to "can I verify this myself?" is already in the email you sent on the day.
Back to the Friday email
Return to the consultant and the finance team three months on. Instead of digging through attachments, the finance contact opens the original delivery email, scans the code on the certificate and sees the signer and signed date on a public page, then uploads the PDF to the validator to confirm it is the signed file. Nobody had to phone the consultant. The proof was handed over with the file.
Seal your next deliverable on Swiss Trust Layer, and read how the sealing step works on how it works.
