How to tell if a document has been altered: hashes, seals and what a PDF cannot tell you

Start with the awkward truth. Nothing inside a file can prove the file is honest. The question "has this document been altered?" is really two questions: has it changed since it was issued, and was it right when it was issued. Different tools answer each, and the most convincing-looking evidence, a clean set of PDF properties, answers neither.

Two questions hiding inside one

When people ask how to tell if a document has been altered, they usually mean one of two things. A buyer's solicitor holding a building regulations completion certificate wants to know it is the one the council issued, with the same date and the same address. A lender reading a valuation wants to know the figure on page one is the figure the valuer wrote. Both are asking about change since issue.

The second question is harder and more common than people think: was the document ever genuine? A perfectly preserved forgery has never been altered. A certificate run off on a home printer with a real scheme's logo will pass every check for edits because it was never edited; it was made wrong from the start. Fraud by false representation under section 2 of the Fraud Act 2006, and making a false instrument under section 1 of the Forgery and Counterfeiting Act 1981, each carry up to ten years on indictment. The law treats the two questions as the same offence. Your checks cannot.

So the method below runs in order, from the weakest evidence to the strongest: metadata, then content, then a file hash, then a digital signature check, then the issuer. Each layer rules something out. Only the last one rules something in.

What metadata can tell you, and what it cannot

Every PDF carries a creation date, a modification date, the application that made it and the "producer" that wrote the file. PDF 2.0 (ISO 32000-2:2020) deprecates most of those fields in favour of an XMP metadata stream but keeps the two dates, so you will find them in anything from a scanned certificate to a bank statement, under File, then Properties, in Acrobat and most readers.

How to tell if a PDF has been edited from its properties

Three patterns are worth a second look: a modification date later than the date printed on the document; a producer that names a general-purpose editor, an online converter or a word processor when the issuer's own system would have produced it; and an author field that names a person rather than an organisation. None is proof. A conveyancer who rotates a page or adds a bookmark changes the modification date without touching a word.

Illustrative properties panel. Two fields prompt a question; neither answers it.

One more place to look: a PDF can be saved by incremental update, which appends the changes to the end of the file and leaves the earlier version intact inside it, where tools that read the file's revision history can show it. Word files carry a last author, a revision count and any tracked changes left in; photographs carry EXIF data, and gain a software tag when an editor has touched them.

Why metadata is a lead, never evidence

Every one of those fields is a value in a file, and values in files can be set. Free tools rewrite PDF dates, EXIF fields and Office properties in seconds; a competent forger does so, and a careless one does not. That asymmetry is the whole value of a metadata check: it catches the lazy, confirms nothing about the careful, and must never be the reason you accept a document. To check if a PDF has been altered with any confidence, you need something the forger cannot set.

Read the content before you trust the container

Before reaching for cryptography, read the thing. Altered documents fail in predictable ways because editing a finished layout is harder than it looks.

• Fonts and spacing. A replaced figure is often in a near-identical face at a fractionally different weight, or a pixel off the baseline. Zoom to 400% on the numbers that matter.
• Arithmetic. Totals that do not add up, VAT that is not 20% of the net, a valuation that differs from the covering letter.
• Reference numbers. A Gas Safe registration number, a FENSA certificate number and a Companies House number each have a shape; one that does not fit is worth a call.
• Dates against the world. A certificate dated on a Sunday, a signature dated before the work was ordered.
• The copy you already hold. Two copies from independent sources that agree are worth more than any single clean file.

None of this is sophisticated. It is also where most altered documents are caught.

Verify a file hash: what SHA-256 proves

A cryptographic hash turns any file into a fixed-length fingerprint. SHA-256, specified in NIST's FIPS 180-4 (Aug 2015), produces 256 bits, written as 64 hexadecimal characters. Change one byte of the file, a full stop, a trailing space, a pixel, and the fingerprint changes completely. Two different files producing the same SHA-256 has never been demonstrated; its predecessor SHA-1 was broken in public on 23 February 2017, when CWI Amsterdam and Google published two PDFs with different content and the same SHA-1 hash, and NIST has set 31 December 2030 as the date SHA-1 leaves its standards entirely (NIST, Dec 2022). If a document you are checking comes with an MD5 or SHA-1 fingerprint, ask for SHA-256.

How to compute a SHA-256 hash yourself

You do not need any software you do not already have. Every current desktop operating system ships a tool that prints a file's SHA-256:

The fingerprint is deterministic: the same bytes give the same 64 characters on any machine, in any year.

To verify a file hash you need two things: the file, and a fingerprint recorded earlier by someone you have a reason to trust. Compute the hash of the file in front of you and compare the two strings in full; a glance at the first and last four characters is not a comparison. If they match, the file you hold is byte-for-byte the file that was fingerprinted.

What a matching hash does not prove

This is the part most "document verification" marketing skips. A hash proves the file has not changed since the moment it was hashed, and nothing about that moment: not who made the file, not whether its contents were true, not whether the person who gave you the fingerprint should have. A forged certificate, hashed on the day it was forged, verifies cleanly for ever. A fingerprint that arrived in the same email as the document is not independent of it and adds nothing.

The second gap is when. A bare hash carries no time. For that you need a timestamp from a party that is not the sender: a timestamping authority under RFC 3161 (IETF, Aug 2001), which signs a hash together with the time it saw it, or a public ledger the hash is written into. The XRP Ledger closes a new ledger roughly every three to five seconds (xrpl.org), each with an agreed close time nobody can later move; a hash recorded in one existed by then. The timestamp still says nothing about truth. It narrows "when" to a window the sender did not control.

Digital signature check: who signed it, and when

A digital signature adds the missing "who". The signer's software hashes the document and encrypts that hash with a private key; anyone with the matching public key, published in a certificate, can decrypt it and compare it with a fresh hash of the document. If they match, the document has not changed since signing and the signing key was the one in the certificate. Acrobat and most PDF readers show this in a signature panel, and those are the two things they check: integrity since signing, and a certificate chain that leads to a root the reader trusts.

In the UK the legal footing is settled. Section 7 of the Electronic Communications Act 2000 makes an electronic signature and its certification admissible as evidence of authenticity or integrity. Article 25 of the UK eIDAS Regulation, the EU text carried into domestic law on 31 December 2020, says a signature cannot be denied legal effect solely because it is electronic. The Law Commission's report of 4 September 2019 confirmed electronic signatures can execute documents, including deeds, where the signer intends to authenticate and any formalities are met.

Reading a signature result correctly

Three outcomes, three meanings. "Valid" means the content matches the signed hash and the certificate chains to a trusted root; it does not mean the signer was entitled to issue the document, only that the named key was used. "Unknown" usually means the reader does not recognise the certificate's issuer, common for an organisation's own certificate authority, and is a prompt to check the certificate by hand rather than a verdict. "Invalid" means the document changed after signing or the certificate has been revoked: stop. For photographs and video the same idea is arriving under the C2PA Content Credentials standard, which binds a signed manifest of origin and edits to the image. Its limits are the same as any signature: a valid credential proves the manifest was signed and the file is unchanged since, not that the picture is true.

Confirm with the issuer: the step everyone skips

Only one party can answer "was this real when issued", and it is the party that issued it. For the documents that matter most in a UK property or asset transaction, that confirmation is a lookup rather than a phone call: Gas Safe, FENSA and HETAS run registers where a certificate can be checked by number or address; NICEIC and NAPIT confirm their contractors; the EPC register holds every energy certificate in England and Wales; Companies House publishes filings; a council's building control team will confirm a completion certificate for its own address. The guide to the documents needed to sell a house lists which scheme issues each one.

Two rules make the check worth doing. Use the contact details on the issuer's own website, never the ones printed on the document; a forger who has altered the figure has also altered the phone number. And quote the reference and ask the issuer to read back the date, the address and the key figure, rather than sending the file and asking "is this genuine". If the issuer cannot confirm it, the document is unverified, whatever its metadata says. To check document authenticity you confirm with the source; everything above only tells you whether the copy in your hand is the copy the source produced.

Six checks, in order of strength. No single row answers both questions.

How a tamper-evident document and an integrity receipt work

Put the pieces together and you have the method that any record of documents should use. It is not complicated, and it has nothing to do with where the documents are stored.

Hash, receipt, anchor. A reader can check steps 1 and 2 today; step 3 removes the need to trust whoever holds the record.

Three design rules follow. The hash is taken on arrival, not on request, or there is a window in which the file could change unrecorded. The original is kept and corrections stored as new versions, each with its own receipt, so the history of a document is itself a record. And the claim is stated honestly: a tamper-evident document, meaning a change is detected, not a tamper-proof one, meaning a change is impossible. Nobody can make the second promise about a file in storage.

What a receipt system still cannot do is grade the document. A completion certificate from a council and a photograph from an owner hash identically well. That is why a record of an asset needs a second layer in which each document is graded by who issued it; the asset provenance record and the verification score built on it exist for that reason, and both run off-ledger.

What Property Vault does, and its status today

Property Vault applies the method above to every document in an asset's Vault. On upload, each file is hashed with SHA-256 and given an integrity receipt: the hash, the document, its version and the time. Originals are kept and corrections are stored as new versions; nothing is overwritten. That is live in pilot at propertyvault.world/homes, and the tamper-evident documents page sets out the full design, including what is never written to a ledger.

The document integrity check is where the receipt becomes useful to someone outside the Vault. Drop a sealed document and paste its seal: your browser computes the file's SHA-256 locally, the file is never uploaded, and only the fingerprint and the seal are sent to be checked against Property Vault's published keys. Signed seals and the seal check are launching. Until anchoring reaches mainnet, a valid result means Property Vault signed that fingerprint at the seal time and your file carries it: tamper-evident, and our signature rather than an independent public timestamp.

Integrity anchoring runs as a rehearsal on the XRPL testnet: Merkle roots of keyed commitments are written to the test network, which can be reset, and listed on the public anchor page; mainnet anchoring is on the roadmap, subject to approvals. On mainnet, each day's receipts will fold into one Merkle root written to the XRP Ledger in a single AccountSet memo from Property Vault's own account, 32 bytes with nothing identifiable in them, and comparison against the ledger arrives with it. Documents, personal data, natural keys and title never go on-ledger; the companion article on XRP Ledger tokenisation explains why the record has to come first.

It matters wherever a sealed document leaves the Vault and someone else has to rely on it: a conveyancer receiving material information through the Sale-Ready Passport, a claims handler reading insurance claim evidence under an insurer scope, a credit team reading the Collateral Report, which is in development. Each gets the same honest answer: unchanged since sealed, graded by who issued it, never a judgement of the work itself.

How to tell if a document has been altered: the six-step checklist

The order matters. Each step is cheap, and the one you skip is the one the forger was counting on.

1. 1
   Open the propertiesCreated and modified dates, application, producer. Flag anything later than the printed date or made by a general-purpose editor. Flags, not findings.
2. 2
   Read it at 400%Fonts, baselines, arithmetic, reference-number formats, dates against the calendar. Compare with any independent copy.
3. 3
   Hash itCompute the SHA-256 and compare it, in full, with a fingerprint recorded earlier by someone other than the sender. A match proves "unchanged since"; nothing more.
4. 4
   Check the signatureIf the document is signed, read the panel. Unknown means look harder; invalid means stop.
5. 5
   Find the independent timestampA timestamping authority's receipt or a ledger anchor fixes "existed by when" to a date the sender did not control.
6. 6
   Confirm with the issuerUse the issuer's own contact details and quote the reference. The only step that answers "was it real", and the one most people skip.

Run all six and you will know two things separately: whether the copy in your hand is the copy that was issued, and whether what was issued was true. A record that seals every document on arrival, keeps the receipts and lets anyone check them does the first for you, permanently. Nothing does the second except the issuer, which is why a serious record also tells you who the issuer was.¹