PDF Integrity Report: April 2026
This article is a snapshot – content was accurate as of May 2026. The product evolves actively; specific counts, examples, and detection rules may have changed since publication – see the changelog for the current state.
Every month we look at aggregate, anonymized data from checks processed through the HTPBE? web interface and write up what the structural signals tell us about the state of PDF tampering. No file contents, no personally identifiable information – only the structural and metadata patterns our algorithm uses to classify documents.
A note before the numbers. April was an unusual month for the dataset. Alongside the organic stream of public submissions, we ran a large internal adversarial-testing batch – well over ten thousand synthetic and modified PDFs, generated and edited through every technique we know about, used to harden the algorithm against new tampering classes. Those test files are mixed into the structural counts below. So the absolute volume for April is dominated by our own training pipeline and is not a meaningful number to compare to March. What is meaningful is the shape of what we saw – the proportions, the shifts in which signals fire, and the categories of tampering that became detectable for the first time. Those are what this report covers.
For that reason we are stepping away from the daily-volume chart and the headline file-count figure that anchored the February and March reports. Both were useful when the sample was a clean walk-up of public submissions. They are misleading once a structured testing batch is mixed in.
How to read this report
This report describes the PDFs that were submitted to HTPBE? in April 2026 and what our structural analysis found in them. That is all it describes. It is not a measurement of the whole internet, of all business documents, or of how common fraud is in any industry. People tend to send us a file when they already have a reason to look closely at it, so the sample leans towards documents that someone found questionable. A high flagged share here means ‘a high share of the files we were sent’, not ‘a high share of the PDFs in circulation’.
April also contained a large internal testing batch (explained above), so read the proportions and the direction of change rather than the raw counts. The figures for one month are a snapshot and are not revised after publication.
Key takeaways
- More than one in two documents in the April sample came back flagged: about 47% not flagged, about 24% high-confidence modification and about 29% certain modification.
- Eighteen algorithm versions shipped in the month, so part of the rise in the flagged share comes from wider detection coverage rather than from a change in the files themselves.
- Files carrying incremental updates were overwhelmingly flagged, and the modification share among them was higher than in March, which was itself higher than February.
- The newer signal categories (character-encoding manipulation, residual prior-template traces, generator-fingerprint contradictions, multi-session assembly) grew as a share of flagged files, while date-field inconsistencies remained the most common single category.
- Digital signatures are not an integrity guarantee: a meaningful share of signed submissions showed changes made after signing, although that share fell compared with March.
- Absolute volume for April is not comparable with February or March because of the testing batch.
The Headline Pattern
The modification rate kept climbing. February was around two-fifths of submissions flagged. March was just under half. April pushed past the halfway line: more than one in two documents that reached the algorithm – across organic submissions and adversarial test material combined – came back flagged.
Within those, the share carrying definitive structural evidence (the verdict we label ‘certain’, reserved for cases where multiple unambiguous signals converge) held roughly stable as a proportion of all flagged files. The ‘high-confidence’ share – strong but non-converging evidence – grew slightly. The qualitative direction is the same one we noted in March: the population reaching the tool is increasingly weighted toward documents where something is structurally wrong, not toward clean files being routinely checked.
| Verdict | Share of all submissions |
|---|---|
| Not flagged | ~47% |
| High-confidence modification | ~24% |
| Certain modification | ~29% |
Eighteen Algorithm Versions in Thirty Days
April was the most active month for detection development since launch. Eighteen versions shipped between April 1 and April 30. Most of the work fell into three buckets:
New detection categories. Several whole classes of tampering became identifiable for the first time. We are deliberately vague about exactly what each new check looks for – the changelog notes describe behavior in general terms for the same reason. The new categories include impossible-timestamp detection, character-encoding manipulation in document text, residual structural traces left by document rebuilds, and a class of tampering that targets the consistency between different metadata layers within a file. There is also a new category covering documents marked as redacted where the underlying content remains structurally accessible.
False-positive reductions. Roughly half of the April releases were focused on cleaning up false positives on legitimate document classes – enterprise reporting frameworks, certain office-suite outputs, web-optimized files, multi-party signed documents, scanner-firmware variants, and HTML-to-PDF rendering pipelines. These are categories where the underlying tools produce structural quirks that look superficially like tampering signals. Each release narrows the heuristics so that legitimate output stops triggering them.
Clearer inconclusive verdicts. Documents that the structural layer cannot reason about with confidence – pure scans, consumer-software exports, browser-rendered HTML-to-PDF output – are now more consistently routed into an explicit ‘inconclusive’ verdict instead of being forced into intact-or-modified. The April releases added a dedicated status reason for HTML-rendered documents and broadened the scanner-origin classification. The practical effect is that fewer files are returned with a misleading ‘intact’ label simply because the format made structural reasoning impossible.
The broader point: detection coverage in April is materially wider than in March. A non-trivial share of the documents now classified as modified would have come back as intact under the March algorithm. That alone accounts for some of the rise in flagged share.
Modification Signals: The Shape of the Evidence
Among flagged documents, no single signal carried the entire result. The classical signals – date-field disagreements, the presence of incremental updates, missing mandatory metadata fields – remained the most common findings by share. The newer signals appeared less often individually but covered tampering classes the classical signals miss.
The proportional pattern across flagged files in April:
| Signal category | Share of flagged |
|---|---|
| Date-field inconsistencies | leading single category |
| Incremental update structure | second tier |
| Document-identity inconsistencies | second tier |
| Design-tool assembly patterns | second tier |
| Generator-fingerprint contradictions | second tier |
| Mandatory metadata removal | third tier |
| Cross-metadata-stream disagreement | third tier |
| Editor-tool content-stream traces | third tier |
| Sub-1% incremental modifications | smaller share |
| Character-encoding manipulation | smaller share |
| Multi-session page assembly | smaller share |
| Page-property inconsistencies | smaller share |
| Post-signature modifications | smaller share |
| Residual prior-template traces | smaller share |
| Scan-replace patterns | smaller share |
Files routinely carry more than one signal at the same time, which is why this list is best read as a portrait of the evidence mix rather than a partition.
The trend worth flagging: the newer categories – encoding manipulation, residual templates, generator-fingerprint contradictions, multi-session assembly – are becoming a larger share of the flagged set month over month. A forger who has learned to scrub creation dates and avoid leaving an incremental update trail does not necessarily know to clean up the residual template hierarchy of the document they rebuilt from, or to avoid leaving a structural fingerprint that contradicts the producer string they spoofed. These are the second-order signals, and they are catching cases the first-order signals miss.
Incremental Updates: Almost Always Tampered
Files carrying incremental updates were overwhelmingly flagged in April – the modification share among them was higher than in March, which was itself higher than February. The trend has been monotonic across three months.
The mechanism has not changed: PDF incremental updates allow appending content after the original write. Legitimate workflows do produce them – signature application, annotation, form-fill. But on the population reaching the tool, those legitimate cases are increasingly the minority. When an incremental update appears on a document submitted for fraud detection, it is now far more often than not a sign of post-creation editing rather than a clean signature chain.
The average revision-chain length on flagged files ticked up slightly compared to March.
Document Origin
The origin classifier’s output split as follows in April:
| Origin classification | Share |
|---|---|
| Institutional (server-side generators, enterprise systems) | majority |
| Consumer software (‘Cannot Verify’) | second-largest |
| Scanned (‘Cannot Verify’) | meaningful share |
| Unknown | small share |
| Online editor (‘Cannot Verify’) | small share |
Documents falling into the ‘Cannot Verify’ buckets – scans, consumer-software exports, online HTML-to-PDF tools – receive a deliberately conservative inconclusive verdict rather than an intact-or-modified call. The rationale is unchanged: those formats produce structural patterns that overlap with legitimate editing artifacts, and forcing a binary verdict on them would generate too many false positives in either direction.
The April releases also reaffirmed and broadened that conservative stance. HTML-rendered documents now return inconclusive with an explicit machine-readable reason; the classifier treats more scanner-firmware variants as scans; and certain office-suite quirks that previously triggered modification signals are now correctly recognized as legitimate library behavior.
Digital Signatures: Still Not a Guarantee
Among submitted files carrying embedded digital signatures, a meaningful share showed evidence of post-signature modification, and a smaller share had had a signature removed entirely. The post-signature-modification share fell relative to March, but the underlying observation has not changed: digital signatures are not, on their own, an integrity guarantee.
The mechanism is the structural one we have written about before. A PDF signature covers exactly the bytes it covered when it was applied. Incremental updates appended after signing fall outside the signed scope, and the signature can remain technically valid in the viewer chrome – green checkmark, ‘signed by’, date – even though new content has been spliced in. Checking integrity at the structural layer, rather than at the signature-validation layer, is what catches these.
What the April data adds: the share of altered-after-signing files among signed submissions is consistently in the same order of magnitude across months. It is not a tail-risk class of forgery – it is a routine one.
The Software Ecosystem
The producer and creator distributions in April shifted toward more server-side and enterprise generators than the previous months. Several patterns recurring across the ecosystem are worth noting in proportional terms.
Online manipulation services as intermediate steps. A larger share of flagged documents in April than in March showed an online PDF manipulation service in the producer field while a different application appeared in the creator field. That combination indicates the document went through a compress / merge / page-extract / edit step somewhere between original creation and submission. Whether that step was benign or fraudulent is what the structural analysis resolves.
Design-tool origin. Vector-design and consumer-design applications continued to appear in the creator field for documents that purport to be business records – invoices, certificates, contracts. Design tools are powerful enough to reproduce convincing layouts and trivially easy to edit; their presence in the creator field is one of the cleaner indicators that a document was hand-built rather than generated by the system that ought to have produced it.
Programmatic manipulation libraries. Paid PDF-manipulation libraries (the kind used legitimately for merging, watermarking, and signing, and also used in volume for page-import and template-assembly forgeries) continued to account for a notable share of flagged files. The detection signal here is no longer the producer string itself – those are easy to spoof – but the structural fingerprint the library leaves at the binary level. The contradiction between declared producer and structural fingerprint was one of the more frequently firing signals in April.
PDF Version Landscape
The version distribution was effectively unchanged from March: PDF 1.7 and 1.4 together accounted for roughly two-thirds of the sample, with 1.5, 1.6, and 1.3 splitting most of the remainder. PDF 2.0, despite nearly a decade of availability, remained a rounding-error share.
Embedded Content
A small but non-trivial share of files contained embedded JavaScript, and a similar share contained embedded file attachments – binary payloads carried inside the PDF wrapper. Both shares were higher than in March in proportional terms. Neither is in itself proof of tampering, but both are recognized compliance and threat-vector concerns in business-document contexts (contracts, invoices, statements). For workflows that touch documents from external counterparties, both warrant scrutiny independent of modification verdict.
Document Profile
Average size and average page count were broadly in line with the prior months. Metadata completeness remained around three-quarters of fields populated on the average file. The share of documents with creation dates removed entirely ticked up slightly compared to March – a continuation of a trend we have been tracking, since a missing creation date removes one of the cleaner forensic anchors in the file.
Where April Sits in the Series
April is the month that changes how the series should be read. February and March gave file counts and a daily chart; April gives proportions only, for the reason stated at the top. Here is what carries over across the three months and what does not.
| February | March | April | |
|---|---|---|---|
| What the report gives | Counts and shares | Counts and shares | Proportions only |
| Flagged share | 40.4% | 48.5% | past one in two (about 29% certain plus about 24% high) |
| Sample | Walk-up submissions | Walk-up submissions | Walk-up submissions plus an internal testing batch |
| Algorithm updates reported | Not a focus of the report | Seventeen | Eighteen versions |
| Main story | Who submits what | New assembly checks found in the wild | Newer second-order signals, fewer false positives, clearer inconclusive |
What April adds is the direction of detection rather than a count. The classical findings, such as date disagreement and incremental updates, stay the most common. The newer categories grow as a share of what is flagged. The fall in false positives on legitimate document classes matters as much as the new checks, because it is what lets a flagged result be read with more confidence.
If you came here for absolute numbers, February and March have them, and May is the next month with a cleaner sample.
Summary
April 2026 in proportional terms:
- The flagged-document share rose past one in two – continuing the climb from prior months.
- Eighteen algorithm versions shipped, broadening detection coverage materially. Some part of the rise in flagged share is attributable to that wider coverage, not just to a change in the population.
- New tampering categories – character-encoding manipulation, residual prior-template traces, generator-fingerprint contradictions, incomplete redaction, impossible timestamps – are becoming a meaningful share of flagged findings in their own right.
- Files carrying incremental updates were overwhelmingly tampered – the rate has gone up every month for three months running.
- Digital signatures continued to be modified after signing in a non-trivial share of signed submissions.
- The same online manipulation services and design tools that featured in the March writeup continued to appear, in proportional terms, as recurring fingerprints in the flagged set.
For absolute volume readers: April included a large internal adversarial-testing batch used to train the algorithm, so the raw counts for the month are not comparable to February or March. The proportions and trend directions above are what the data supports.
Every figure in this report comes from the same forensic engine teams run on their own intake stream through the PDF tamper detection API.
May will be a cleaner month for like-for-like comparison.
See the full aggregate dataset on the PDF statistics page. Previous report: PDF Integrity Report: March 2026.
Method in brief
A ‘check’ is one PDF analyzed once. HTPBE? reads the structure and metadata of the file and does not interpret what the document says. It returns one of three verdicts:
- MODIFIED – the structure shows the file was changed after it was created. The result is named signals, not a score.
- INTACT – no structural sign of modification was found. This is not proof that the document or its content is genuine.
- INCONCLUSIVE – the file type does not allow a reliable call either way, for example a scan, a consumer-software export or a browser-rendered page. This is not a failure and not a hidden ‘modified’: it is an honest statement that structure alone cannot settle the question for that file.
In the tables above, ‘not flagged’ means files that did not receive a modification verdict, and ‘high-confidence’ and ‘certain’ are confidence levels within a modification verdict, not separate verdicts and not a score. A modification verdict says a file was altered. It does not say who altered it or why, and it does not say anything about whether the content is true. Because the algorithm changed during the month, a file checked on April 2 and the same file checked on April 28 could receive different results. Algorithm changes are listed in the changelog.
FAQ
Does a flagged share above 50% mean most PDFs in the world are forged?
No. It means more than half of the files sent to HTPBE? in April were flagged. People submit documents they already doubt, and the month also included a large internal testing batch, so the sample is not a fair picture of all PDFs.
Why does this report give proportions instead of file counts?
The testing batch made April’s raw volume mostly a product of our own pipeline. Proportions and direction of change are what the data supports, which is why this report does not repeat the daily-volume chart used in February and March.
Is an inconclusive result a sign that something is wrong with the file?
No. It means the file type, such as a scan or a consumer-software export, does not leave enough structural evidence to call it intact or modified. It is a third, deliberately cautious outcome.
Can I check my own documents?
Yes. Upload a PDF on the site, or call the PDF tamper detection API to check files in your own workflow, using the current version of the algorithm. Plans and per-check pricing are on the pricing page.
Other monthly reports
Each month has its own report, and the figures in each are not revised after publication.
- February 2026
- March 2026 – the previous report
- April 2026 – this report
- May 2026 – the next report
- June 2026
- July 2026
- August 2026
Live aggregate figures are on the PDF statistics page.
This report covers checks submitted to HTPBE? in April 2026. We analyze only file structure, never document content; web uploads may be retained in anonymized form to improve detection. All figures are aggregate and anonymized.