A Metadata Viewer Shows What a PDF Says. A File-History Check Shows Whether It Changed
Tools like ExifTool or a free metadata viewer list the creator, producer and dates stored in a PDF. Those fields are easy to rewrite or blank, so they cannot settle whether the file is still the original. HTPBE? answers that second question: was this file edited after it was created?
Two different questions
Reading the fields is not the same as checking the file
A metadata viewer answers ‘what does this file claim about itself?’ It prints the creator, producer, creation date and modification date exactly as stored. That is useful, and for a quick look it is free: try the PDF metadata viewer.
The trouble is that those fields are the part of a PDF anyone can change with a consumer editor, and the part that is often blank on perfectly honest files. A clean-looking or empty set of fields therefore proves nothing in either direction.
A file-history check asks a different question: ‘does the file itself show signs of having been changed after it was created?’ HTPBE? runs a set of forensic checks and returns a verdict (INTACT, MODIFIED or INCONCLUSIVE) with named markers. It reports the fact of an edit, not who made it or why.
What a metadata viewer cannot tell you
- Whether the file was edited after the dates in its properties
- Whether a digital signature still covers what you are looking at
- Whether the fields were rewritten or blanked on purpose
- Whether pages come from more than one source document
- A verdict you can act on without reading raw field names
What this looks like
Where the two approaches give different answers
Three real fraud mechanics we catch at the structural PDF layer.
A payslip whose properties look perfectly normal
A landlord or lender opens the properties of a payslip and sees a sensible creator and a creation date from the right month. A viewer reports exactly that. A file-history check looks at the file rather than the label, and can still return MODIFIED when the amounts were changed afterwards.
An invoice with every field blank
An accounts-payable clerk sees no creator, no producer, no dates. A viewer shows empty rows and leaves the clerk guessing. Empty fields alone settle nothing. The file-history check still reads the file and returns a verdict instead of a shrug.
A bank statement saved as an image, then back to PDF
A scan, print or screenshot has fresh, plausible metadata from the device that made it. A viewer cannot say anything about how the image content came to be. HTPBE? never returns INTACT for a scanned, printed or screenshot-based file, because there is no original file left to confirm.
A signed contract with a signature field still present
The properties still list a signature, so a viewer makes the file look sealed. HTPBE? checks whether the signature still covers the content you are looking at, and flags the file when it no longer does.
Hundreds of uploads a day
A viewer is built for one file and one person reading the output. A lender or marketplace needs every upload screened before a human sees it, with a result a workflow can route on. That is the job of the HTPBE? API.
When to use each
Use the viewer to look. Use the check to decide
They answer different questions, so most people end up using both.
Metadata viewer (ExifTool and similar)
A quick look at what the file claims
- Free and instant for a single file
- Full list of stored fields, nothing hidden
- You interpret the values yourself
- Says nothing about whether the fields are still true
A good start for one-off curiosity or debugging.
HTPBE? file-history check
An answer on whether the file changed
- 63 forensic checks on the file itself
- Verdict: INTACT, MODIFIED or INCONCLUSIVE
- Named markers explain what was found
- REST API for screening at volume
What HTPBE? checks
Detection capabilities
Deterministic structural signals. No probabilistic scores, no model training.
What a metadata viewer is good at
Showing the stored creator, producer, dates and XMP fields in full, quickly and for free. It is a good first look when you know what you are looking for, and a decent way to understand what a file says about itself.
What a file-history check adds
A verdict on whether the file was changed after it was created, based on the file itself and not only its labels. It does not depend on those fields being present or truthful.
Edits after signing
A file that was edited after a digital signature was applied, or had its signature taken out, is reported as modified.
Pages from more than one source
Documents assembled from pages that did not start out together are flagged, even when the visible result looks uniform.
Scans, prints and screenshots
These can be flagged for what they are, but never returned as INTACT: a verdict on the original file is not possible once the content has been re-captured.
A result you can route on
63 forensic checks feed one verdict plus named markers. There is no numeric risk score to interpret, only a clear answer and the reasons behind it.
Share with engineering
Wire this into your intake pipeline in under a day
Two API calls – one POST to submit the PDF, one GET to retrieve the verdict. Forward this page to your engineering team; the full API reference, quotas, and copy-paste examples in cURL, JavaScript, Python, PHP, Go, and Ruby are one click away.
Pricing
Self-serve plans, no sales call
All plans include the same forensic checks. Pick the quota that matches your monthly document volume.
manualStarter
30 credits/mo
Manual spot-checks and integration testing
most commonGrowth
350 credits/mo
Active document processing pipelines
high volumePro
1,500 credits/mo
High-volume automation and API integrations
Enterprise (unlimited, on-premise available) — see full pricing
API key on signup. Free test environment on every plan. No card required.
Customer Stories
Teams that stopped document fraud
Compliance, finance, and risk teams use HTPBE? to catch manipulated PDFs before they become costly mistakes.
Caught an invoice where the total had been changed by less than a thousand dollars. Without this I would have approved it without a second look.
Sarah M.
AP Manager
United States
We had three applicants in the same week with bank statements that looked completely fine. Two of them were flagged as modified. You simply cannot see this by reading the document — it is in the file structure.
Lars V.
Risk Analyst, Online Lending
Netherlands
Salary slips were coming with altered figures. We identified two problematic files before the placement was finalised.
Priya K.
HR Operations Lead
India
Since we started checking documents this way, we stopped two applications early in the process that would have been very difficult to reverse later.
Julien R.
Fraud Analyst, Fintech
France
Some applicants were sending PDFs that looked authentic but had been edited in ways not visible to the eye. We now ask for checked originals when something is flagged. Already saved us from a few bad decisions.
Marta S.
Compliance Coordinator
Spain
One invoice was caught because there was a mismatch between the document dates and structure. That particular case would have cost us significantly.
Tariq A.
Finance Manager
United Arab Emirates
FAQ
Frequently asked questions
If a PDF’s metadata looks clean, is the file original?
Does empty metadata mean a PDF has been tampered with?
Is ExifTool or a metadata viewer enough for checking a document?
Can I still view the metadata itself?
What does the HTPBE? verdict tell me that raw fields do not?
Secure your workflow
Create your account – check PDFs on the web or with an API key, both ready on signup.
No sales call. Cancel any time.