The metadata was real. The story was wrong.

A long report can still mix up the evidence

The unsettling result was a perfectly readable list of metadata. It showed the author from an early draft beside software from a later save. Both strings existed in the file. They did not describe the same saved version.

That is the trap in asking which PDF metadata tool shows the most fields. A longer list is useful only if you know what the values belong to: the current document, an earlier save, a comment, an embedded image or an object the document no longer references.

We tested a deliberately small PDF with known contents, then looked at tools built for different jobs. We make Lyonite, which appears in this comparison. The fixture is public so you can challenge the observations with the same bytes.

New to the distinction? What’s hidden inside a PDF? explains metadata, stored versions and other file contents, with links to the checker guides.

One file, several retained states

The test PDF has five pages and six retained file states: its base state followed by five incremental saves. Four saves change the document properties. The last adds an XMP packet that is present in the current object table but not referenced by the document. A harmless named JavaScript action is also present.

The current title is Final and the current author is Priya Raman. Earlier properties include Draft one and Jane Doe. Those are synthetic names and values planted for the test. An inspector can usefully expose both, provided it explains which is current.

Six retained states means five incremental updates after the base. A tool that counts six end-of-file markers has measured something real, but calling that six edits or six incremental updates changes the claim.

SHA-256: 178846e54dd8972a96ace6c9f6293eb402716e363a0b3dc5955997f39e131eff

Compare the job, then the output

Read the rows by the job you need done. A quick properties viewer does not fail merely because it lacks an object browser. A security inspector should not be treated as an author-attribution service. The observations below apply to this one fixture and these workflows, not every PDF the products can read.

“Not observed” means the completed result we inspected did not expose the item. It is not a claim that the product could never expose it through another operation. Export options are labelled as offered unless we inspected the downloaded artifact. Paid verification products were not tested.

Where the results disagreed

The free TamperCheck extractor returned Draft one and Jane Doe alongside Reviewer Workstation 4. That mixes values from different saves. Its paid document-verification service is a separate product; this result says nothing about its paid checks. The earlier Konvi run showed a similar mixture.

ExifTools.com and Metadata2Go returned the current title and author in this fixture. Metadata2Go also surfaced JavaScript and a warning about duplicate information dictionaries. That is useful context without a reconstructed timeline. ExifTools.com is a website; it is not Phil Harvey’s local ExifTool application, and the names should not be treated as interchangeable.

Meta-Sleuth’s actual app returned the current properties and exposed JavaScript indicators, strings and a hex viewer. It counted six end-of-file markers and described them as six incremental updates. For this constructed file, the distinction is five updates plus the base state. Its visible PDF panel also listed XML namespace addresses among embedded URLs. A namespace string is not, by itself, a clickable PDF action.

These are reasons to inspect the evidence behind a label. A script can be harmless; an ordinary XML namespace can look like a URL; old metadata can still be readable. None should become an accusation merely because an interface gives it a warning colour.

Local processing is a different question

Processing location is a separate question from parsing depth. APIVoid, TamperCheck’s free extractor and Meta-Sleuth advertise local processing. The inspected Metadata2Go View Metadata flow created a server conversion job and used an upload endpoint. ExifTools.com used its extraction endpoint and describes server processing in its FAQ. That does not describe every tool offered by either website: Metadata2Go, for example, separately advertises a browser PDF comparison workflow.

We record request methods and endpoints after selecting the synthetic fixture. Browser request logs do not always expose multipart file bodies, and a request count alone cannot prove that a file was or was not transmitted. Code downloads, analytics and file processing are different operations. Claims here are limited to the observed workflow and the provider’s stated processing model.

A correction to the first edition: it said Lyonite and Konvi made no requests after selection, and described a telemetry request body more confidently than the saved evidence supported. Those claims have been removed. Lyonite loads parser assets from its own origin when needed; that is compatible with local file processing. The checker’s local verification separately exercises the file workflow and checks requests.

Which would I use?

For a quick answer about the current author and dates, a small properties viewer may be all you need. For a PDF generator bug, Loreatec’s object graph or an independent local parser can be a better starting point than a warning dashboard. For broader file-type triage, Meta-Sleuth offers views beyond PDFs. For a multi-format metadata workflow with server processing acceptable, ExifTools.com and Metadata2Go deserve a look.

Lyonite’s useful distinction is the combined workflow: current properties first, retained saved versions and hidden-information checks in the same report, then deliberate page comparison when you have a second copy. It keeps file processing local and lets a reader move from an ordinary question to technical evidence. That is a practical advantage, not evidence that it is the most complete parser or cannot be beaten.

We also found and fixed faults in our own implementation while consolidating it. A fixed-size cross-reference preview missed older states when the table was long. A report with no flagged findings could export almost no useful data. The checker now has regression coverage for the long-table case, and readable reports include ordinary fields even when no findings are highlighted.

What this test cannot settle

This fixture does not grade real signature verification, certificate trust, scanned-image manipulation, malformed compressed objects or fraud detection. It is intentionally narrow. A broad claim about “forensic accuracy” would require a much larger corpus and independently checked ground truth.

Lyonite itself has limits. Earlier content may have been overwritten; recovery can be partial; raw byte matches need context; signature trust and timestamp message imprints are not verified. Page comparisons have explicit page and rendering budgets. A matching appearance is not a proof of identical files, and a changed appearance is not proof of deception.

The most useful next step is to run the same file through another parser and investigate disagreements. Keep the original, record the exact workflow and distinguish observations from conclusions. That is how a comparison remains useful after the products change.

Try the same bytes

Download the PDF and its ground truth below, verify the SHA-256, then inspect the current properties, retained states, JavaScript and unreferenced XMP separately. The downloadable observation record identifies which workflows completed and which did not. Dates are attached to the runs; a later product update can change the result.

APIVoid returned an access-denied page in our browser environment. DocuExprt’s file control accepted the selection but did not produce a completed result in two attempts. We do not score either as a parsing failure. Their documented scope is included so readers can still compare the intended workflows.

Found a changed result? Send the workflow and result. We can rerun and date a correction.