Most explanations of an audit trail list the same fields in the abstract: who, when, IP address, a hash. This page walks through the actual document Pixasign produces, section by section, in the words it prints, and says what each line can and cannot be used to show.
The short answer
- Who: each signer’s name and the email address their signing link was sent to.
- When: when they opened the document, when they agreed to sign electronically and when they signed, each to the second, recorded by Pixasign’s server.
- On what, and from where: the device and browser, the IP address and an approximate location worked out from it.
- What: the SHA-256 fingerprint of the document before signing and of the sealed file.
- The chain: every step carries the hash of the one before, and the last hash, the chain head, is printed on the certificate.
- The seal: one RFC 3161 timestamp from DigiCert over the whole finished file, with its time, serial number and authority.
Where this page comes from
Every label and sentence quoted below is taken from the code that prints the certificate. The seal values are real: they are the ones recorded when we sealed the sample quotation we publish, and you can check the main ones yourself.
What you will not find here is a signer’s IP address, device or location from the sample. Nobody was sent the sample and nobody signed it, so it has no signing steps, and we have not invented any. Where a line describes a signer, this page says what it holds. To see a full certificate with a real trail, send a document to yourself on the free plan.
The certificate opens with its number, the document’s title, the business that issued it, and one line: “Who signed this document, when, and on what. All times are UK time.” Page 1 is written for whoever is handed it. Everything technical starts on page 2.
Page 1: who signed
One row per signer, under four headings.
| Heading | What it holds | What it does not show |
|---|---|---|
| Name | The name the sender gave for that signer, with the email address the signing link was sent to underneath, never cut short | That the person who opened the email is that person |
| Signed, UK time | The date and time they signed, to the second, as recorded by Pixasign’s server | A time from an outside source: only the seal’s time comes from DigiCert |
| Device | The device and browser in words, such as “iPhone, Safari” or “Windows PC, Chrome”, read from what the browser reported | Whose phone or computer it was |
| Location, approximate | A town and country code, looked up from the IP address | Where the person really was: a phone on mobile data, or a VPN, can show somewhere else |
Where something was not captured, the certificate says so in words, such as “Not recorded” or “Device not recorded”. It never fills a gap with a guess.
Page 1: what happened
Under the heading “What happened”, every step, in order, as a sentence with its time. A typical single-signer document reads like this, with the names filled in:
- Document created by the sender
- Sent for signature
- The signer opened it
- The signer agreed to sign electronically
- The signer signed
- Sealed by Pixasign
The moment a signer agrees to sign electronically is a step of its own, because it is part of the evidence that they meant to sign. If a signer opens the document several times, page 1 lists the first opening and page 2 lists them all. Under the list, when the seal’s time is DigiCert’s, the certificate adds: “Step times come from Pixasign’s server, and the seal time from DigiCert.”
Page 1: what this means
Three sentences, each printed only when the record supports it. These are the exact words.
| The certificate says | What it rests on |
|---|---|
| “Changing any byte the seal covers breaks it, and pixasign.co.uk/check reports anything added to the file afterwards as a change.” | The DigiCert timestamp covers every byte of the file as sealed. Bytes added to the end later leave it intact, which is why the checker also compares the whole file with the fingerprint recorded at sealing. |
| “The seal’s time, 12:42:14 UK time on 28 September 2026, comes from DigiCert, an independent time-stamping company.” | The time inside DigiCert’s timestamp. This is how the sentence reads for our sample’s seal. DigiCert is only called independent when the authority really is DigiCert. |
| “Every step is recorded and chained, so a later change would not match this certificate.” | The chain of hashes, explained below, and the chain head printed on the copy each party is sent. |
Then a panel that reads “Check the signed document free at pixasign.co.uk/check. No account needed.” At the foot of every page: “This certificate summarises the signed PDF. Keep both: the signed PDF is the proof.” That last line matters. The certificate is a summary with no seal of its own. The sealed PDF is the evidence.
The technical pages, section by section
Page 2 opens: “You do not need this page to rely on the document: page 1 says what happened. This is the detail a solicitor or expert may ask for.” Times from here on are UTC, not UK time. A strip of four facts comes first: Status, Signers, Sealed at and Audit chain. Then six numbered sections.
| Section | Lines | What they let you check |
|---|---|---|
| 01 Document | Certificate; SHA-256, original; SHA-256, sealed | The sealed fingerprint is the one to compare with your copy of the signed PDF. The original is the file as it went in to be sealed |
| 02 Signer | Name and email; Opened; Consent and intent; Signed; IP address; Location; Device | Device here is the full string the browser sent, the source of the words on page 1 |
| 03 Event timeline | Each step numbered, with who, the UTC time, and a line reading “hash … after …” | Each row’s “after” value should equal the hash of the row above |
| 04 Audit chain | Events recorded; Chain head, SHA-256; whether the chain verified | The last row’s hash should equal the chain head |
| 05 Cryptographic seal | Standard; Algorithm; Timestamped at; Time attested by; Timestamp token serial; Timestamp cert SHA-256; Long-term validation | What sealed the file, when, and by whose key |
| 06 How to check this | Four numbered steps | The proof is the signed PDF; its SHA-256 must equal the sealed hash in section 01; check it at pixasign.co.uk/check; walk the chain to the chain head |
Section 05 also says in words how the seal works: DigiCert time-stamped a hash of the whole signed PDF, and “No Pixasign certificate signs this PDF. Whether Pixasign sealed it is confirmed against Pixasign’s own records at pixasign.co.uk/check.”
The real seal values from our sample
These are the values recorded when the sample quotation was sealed, set out under the labels the certificate uses.
| Line | Value for the sample |
|---|---|
| Certificate | PXS-B8C8CAED0E86, the first twelve characters of the sealed fingerprint |
| SHA-256, sealed | b8c8caed0e86f5c2 |
| Standard | PAdES document timestamp (ETSI EN 319 142), with long-term validation data |
| Algorithm | RSA-4096 with SHA-384, DigiCert’s key |
| Timestamped at | 28 Sep 2026, 11:42:14 UTC, which is 12:42:14 UK time |
| Time attested by | DigiCert SHA384 RSA4096 Timestamp Responder 2026 1 (DigiCert, Inc.) |
| Timestamp token serial | 294281709232062492 |
| Timestamp cert SHA-256 | 711dd77b1c2e71b2 |
| Long-term validation | Embedded |
Two of these you can check in a minute. Take the SHA-256 of the downloaded file (on Windows, certutil -hashfile "file.pdf" SHA256; on a Mac, shasum -a 256 file.pdf) and it matches the sealed line. Drop it into the checker and the timestamp line reads “Time-stamped by DigiCert, 28 Sep 2026, 12:42:14 UK time”. We did both on 5 November 2026. The sample’s original fingerprint is not published, and neither is its certificate, since it has no signing steps to show.
How the chain of hashes works, and its limit
Each step is written as a set of fields: its number, the document, the event, who did it, the IP address, the location, the browser string, the document’s fingerprint, the time, and the hash of the step before. The step’s own hash is the SHA-256 of those fields. The first step points back to a run of 64 zeros. So every step depends on every step before it.
The limit, stated plainly. The chain uses no secret key, and it is kept in Pixasign’s database, outside the sealed file. Somebody able to write to that database could edit a step and work out every hash after it again. What they could not do is make the result match the chain head already printed on the certificate each party was sent. That is why the certificate’s own sentence says a later change “would not match this certificate”, and why you should keep your copy.
What the trail proves, and what it does not
- It records events. Sent, opened, agreed, signed, sealed, with times and the signals around each one.
- It does not prove who the person is. Each signer is identified by the email address their link was sent to. If who signed really matters, add a step outside the tool, such as a call to a number you already hold for them.
- It does not prove authority to sign for a company.
- It does not read minds. It records that the signer agreed to sign electronically. What they had in mind is argued from all the circumstances, with the record as one part.
- It is not the proof on its own. The sealed PDF is. Keep the two together, unedited.
To check a sealed file, see how to tell if a signed PDF was changed after signing. For what to keep if a signature is challenged, see electronic signature evidence in the UK, and for the law, the proof and the pricing together, the guide to electronic signatures for UK small businesses.
See a full certificate on your own document
Free for 3 documents a month, no card. Send a PDF to yourself, sign it on your phone, and read the evidence certificate that comes back.
Start free UK company. Documents stored in the EEA.Questions
- What does an e-signature audit trail show?
- On Pixasign, the evidence certificate shows each signer’s name and the email address their link went to; when they opened the document, agreed to sign electronically and signed; their device, IP address and approximate location; the SHA-256 fingerprint of the document before signing and of the sealed file; every step with its hash; and the DigiCert timestamp on the seal.
- Is an evidence certificate the same as a certificate of completion?
- It does the same job. Some e-signature services call their summary of a signed document a certificate of completion. Pixasign calls it an evidence certificate, and sends it with the sealed PDF to everyone who signed.
- Does an audit trail prove who signed?
- No. It records the signals around the signing: the email address the link was sent to, the IP address, the device and the approximate location. Together they build a picture, but they do not prove who was holding the phone, or that the signer was allowed to sign for a company.
- Can an e-signature audit trail be changed afterwards?
- Pixasign chains every step to the one before with SHA-256, and prints the final value, the chain head, on the certificate each party is sent. The chain uses no secret key, so somebody able to write to the database could recompute it, but the result would not match the chain head on the copies already sent. Keep your copy.
- Where do the times on the certificate come from?
- The time of each step, from sending to signing, is recorded by Pixasign’s server. The time of the seal comes from DigiCert, an independent timestamp authority, inside the sealed file. Page 1 shows UK time and the technical pages show UTC.