Forem: Iurii Rogulia

5 Signs a PDF Document Has Been Tampered With

Iurii Rogulia — Thu, 09 Apr 2026 11:38:43 +0000

PDF documents are everywhere in business — invoices, contracts, certificates, reports. We trust them because they look official and professional. But that trust can be misplaced. Document tampering is a growing problem, with criminals modifying PDFs to commit fraud, alter contracts, or forge credentials.

The challenge: PDF tampering can be nearly invisible. A modified PDF can look identical to the original, making it difficult to detect changes without knowing what to look for.

This article outlines five clear warning signs that a PDF has been tampered with. Recognizing these signs helps you protect yourself and your organization from document fraud.

Why Document Tampering Is a Growing Concern

Document fraud affects businesses and individuals worldwide. According to research from Smallpdf, document fraud has increased significantly with the rise of digital document workflows. PDFs are particularly vulnerable because they are easy to modify and hard to verify.

The consequences of document tampering can be severe:

Financial losses from fraudulent invoices
Legal disputes over modified contracts
Identity theft through forged certificates
Reputation damage from document fraud incidents

As Help Net Security reports, new techniques for detecting PDF tampering are emerging, but awareness of warning signs remains the first line of defense.

Sign #1: Mismatched Creation and Modification Dates

The simplest sign of PDF tampering is when creation and modification dates do not match — or when they do not make sense.

What to Look For

In PDF Properties:

Creation date: When the PDF was first created
Modification date: When the PDF was last modified

Red flags:

Modification date is significantly later than creation date
Old document (years old) with recent modification date
Modification date matches suspicious activity timeline
Dates that do not align with document history

How to Check

Open the PDF in Adobe Acrobat Reader
Right-click → Properties (or File → Properties)
Check the “Created” and “Modified” dates in the Description tab

Why This Matters

Legitimate documents typically have matching dates or modifications that make sense (like adding a signature). When a document claims to be old but was modified recently, it suggests tampering.

Example: A contract dated 2020 that was modified in 2025 should raise suspicion, especially if no legitimate reason exists for the modification.

Limitations

Some PDF creation tools set both dates to the same value even after editing. Additionally, legitimate actions like re-saving or adding signatures will change the modification date. This sign should be considered alongside other indicators.

Sign #2: Suspicious Producer/Creator Applications in Metadata

PDF metadata reveals which applications created and last processed a document. Suspicious applications can indicate tampering.

Understanding Metadata Fields

Creator: Application that originally created the PDF
Producer: Software that last processed the PDF

What to Look For

Suspicious patterns:

Legal document created in photo editing software
Invoice created in a graphics design tool
Document claiming to be from Word but producer is a PDF editor
Multiple different producers (suggesting multiple edits)
Unknown or suspicious application names

How to Check

Open PDF Properties (File → Properties)
Go to the Description tab
Review the “Application” and “PDF Producer” fields

Real-World Examples

Invoice fraud: Invoice created in “Adobe Acrobat Pro” when the vendor normally uses accounting software
Certificate forgery: Certificate created in “Photoshop” instead of an official certificate generation system
Contract tampering: Contract producer changed from “Microsoft Word” to “Foxit PhantomPDF” between versions

As Heron Data explains, metadata analysis can reveal editing history even when visual inspection shows no changes.

Why This Matters

Legitimate documents are created using appropriate software. When metadata shows unexpected applications, it suggests the document was edited or created fraudulently.

Sign #3: Visual Inconsistencies (Fonts, Spacing, Alignment)

Sometimes, the best way to detect tampering is simply to look carefully. Visual inconsistencies can reveal editing, especially when text or images were added to an existing PDF.

Font Inconsistencies

What to check:

Different fonts in what should be uniform text
Font sizes that do not match the document style
Fonts that appear pixelated or low-quality
Text that looks pasted in rather than original

Why it matters: When someone edits a PDF by adding text, matching the original font perfectly is difficult. Differences can indicate tampering.

Spacing and Alignment Issues

What to check:

Text that does not align with margins
Uneven line spacing
Text that overlaps or appears misaligned
Inconsistent spacing between elements

Why it matters: Original documents have consistent formatting. Editing often disrupts this consistency.

Image Quality Problems

What to check:

Low-resolution images that do not match the document quality
Images that appear stretched or distorted
Watermarks or logos that look different
Images with different color profiles

Why it matters: Adding or modifying images in PDFs can create quality mismatches that reveal tampering.

Color and Style Inconsistencies

What to check:

Colors that do not match the document theme
Text colors different from surrounding content
Inconsistent styling (bold, italic, underline)
Different border styles or line weights

Visual inspection requires careful attention but can catch tampering that automated tools might miss.

Sign #4: Invalid or Missing Digital Signatures

Digital signatures provide cryptographic proof that a document has not been modified since signing. Invalid signatures are a strong indicator of tampering.

How Digital Signatures Work

A digital signature creates a unique cryptographic hash of document content. If the document is modified after signing, the hash changes and the signature becomes invalid.

What to Look For

Signature status indicators:

Valid: Document has not been modified since signing (good sign)
Invalid: Document was modified after signing (red flag)
Unknown: Signature certificate cannot be verified (investigate)
Missing: Document lacks a signature when one is expected (suspicious)

How to Check

Open the PDF in Adobe Acrobat Reader
Look for the signature panel or signature field
Click on the signature to view its status
Review signature details and validity

Why This Matters

A valid digital signature proves the document has not been tampered with since signing. An invalid signature means the document was modified after signing — a clear sign of tampering.

Important note: A valid signature does not guarantee the document was never edited — it only proves it has not been modified since signing. If someone edited the document before signing it, the signature will still be valid.

Real-World Example

A contract was digitally signed by both parties. Later, one party modified payment terms and re-saved the document. The digital signature became invalid, alerting the other party to the tampering.

Digital signature verification is one of the most reliable methods for detecting PDF tampering.

Sign #5: Multiple Revision Layers or Incremental Updates

PDFs can be modified using incremental updates, which add changes without rewriting the entire file. Multiple revision layers can indicate tampering.

Understanding Incremental Updates

When a PDF is modified, some editors use incremental updates that:

Add new content without removing old content
Create multiple versions within the same file
Leave traces of editing history
Can be detected through technical analysis

What to Look For

Technical indicators:

Multiple cross-reference tables
Incremental update markers
Revision history in file structure
Multiple producer entries in metadata
File size inconsistencies

How to Check

Manual inspection:

Check PDF properties for multiple producer entries
Review file size (unusually large files may contain multiple revisions)
Look for revision history in document properties

Automated tools:

Use PDF analysis tools to detect incremental updates
Check cross-reference table integrity
Analyze file structure for revision layers

Why This Matters

Legitimate documents typically have a single revision layer. Multiple layers suggest the document was edited multiple times, which could indicate tampering.

Example: An invoice with three incremental updates when it should have been created once suggests multiple editing sessions, potentially for fraudulent purposes.

As DocuClipper notes, incremental update analysis requires technical knowledge but provides strong evidence of tampering.

Bonus: What These Signs Mean (Fraud vs Legitimate Edits)

Not all PDF modifications indicate fraud. Understanding the difference helps you avoid false alarms while catching real threats.

Legitimate Modifications

These actions commonly modify PDFs and are usually harmless:

Modification Type	Why It Happens	Should You Be Concerned?
Re-saving	Software auto-save, format conversion	No — normal workflow
Digital signature added	Standard signing process	No — expected behavior
Form fields filled	Completing PDF forms	No — intended use
Document merged	Combining multiple PDFs	Possibly — verify source
Format conversion	Converting from Word/Excel	No — normal creation
Optimization	File size reduction	No — performance improvement

Suspicious Modifications

These patterns warrant investigation:

Modification after signature: Document changed after being digitally signed
Unexpected creator: Document created in unusual software
Recent modification of old document: Old document suddenly modified
Metadata inconsistencies: Conflicting information in metadata
Visual anomalies: Obvious editing artifacts
Multiple revisions: Unusual number of incremental updates

Context Matters

The same modification can be legitimate or suspicious depending on context:

Contract modified after signing: Suspicious — should not happen
Invoice re-saved for formatting: Normal — common workflow
Certificate created in photo editor: Suspicious — should use official tools
Report converted from Word: Normal — standard creation process

As research from arXiv shows, context-aware analysis improves tampering detection accuracy.

The Automated Solution: Let Technology Do the Work

While manual inspection can catch obvious tampering, sophisticated edits require automated analysis. PDF verification tools like HTPBE examine multiple technical indicators simultaneously to detect modifications.

Why Automated Tools Are Superior

Speed: Analysis completes in seconds
Accuracy: Detects modifications that manual methods miss
Comprehensive: Checks all five signs plus additional indicators
Objective: No human error or bias
Accessible: No technical knowledge required

What HTPBE Checks

When you upload a PDF to HTPBE, the algorithm analyzes:

Document properties and dates
Metadata analysis (creator, producer)
Digital signature verification
Incremental update detection
Cross-reference table integrity
Structural anomalies The result is a clear verdict with specific findings — no technical knowledge required.

When to Use Automated Verification

Use automated tools for:

Critical documents (contracts, invoices, certificates)
Documents from unknown sources
Documents that seem suspicious
Regular verification workflows
Compliance and audit requirements

Conclusion

Detecting PDF tampering requires awareness of warning signs and careful inspection. The five signs outlined above — mismatched dates, suspicious metadata, visual inconsistencies, invalid signatures, and multiple revisions — provide a framework for identifying tampered documents.

Remember:

Not all modifications are fraud: Many are part of normal workflows
Context matters: Consider the document type and expected modifications
Multiple signs increase suspicion: One sign might be normal; multiple signs warrant investigation
Automated tools help: Use verification tools for critical documents

By recognizing these signs, you can protect yourself and your organization from document fraud. When in doubt, verify through automated tools or independent channels.

React Masonry Layout: Why the Popular Reorder Trick Fails

Iurii Rogulia — Thu, 12 Mar 2026 15:37:15 +0000

A masonry grid looks simple: variable-height cards, left-to-right reading order, columns that fill naturally. You reach for column-count in CSS because that's what the tutorials recommend. Everything looks correct on your three uniform-height test cards. Then you add real content — cards with different amounts of text, images, tags — and the order breaks. Card 4 appears before card 2. Card 7 jumps to the top of column 1. The layout is shuffled.

I hit this on my portfolio's blog and projects pages. I found the popular fix, implemented it, and watched it fail in production. Then I built an approach that actually works. Here's what the popular fix gets wrong and what to do instead.

Why `column-count` Breaks Ordering

CSS column-count is a newspaper-layout primitive. You give it a container and a number of columns, and the browser fills those columns top-to-bottom — not left-to-right. The first column fills completely before the second starts.

That's the correct behavior for newspaper text. It's the wrong behavior for a card grid where reading order should go left-to-right across the top row.

Items: [1, 2, 3, 4, 5, 6]
column-count: 3

What CSS does:           What you want:
┌────┬────┬────┐         ┌────┬────┬────┐
│ 1  │ 3  │ 5  │         │ 1  │ 2  │ 3  │
│    │    │    │         │    │    │    │
│ 2  │ 4  │ 6  │         │ 4  │ 5  │ 6  │
└────┴────┴────┘         └────┴────┴────┘

The standard fix that circulates on Medium and in Stack Overflow answers is to reorder the array in JavaScript before rendering it into the column-count container — placing items in column-reading order so that CSS's top-to-bottom fill produces the correct left-to-right result.

The Popular Reorder Algorithm — And Why It Fails

Jesse Korzan published a clean write-up of this technique on Medium with a live demo. The idea is elegant: instead of passing [1, 2, 3, 4, 5, 6] to the CSS column container, reorder it to [1, 4, 2, 5, 3, 6] so that CSS fills column 1 with items 1 and 4, column 2 with items 2 and 5, column 3 with items 3 and 6 — producing the correct left-to-right reading order.

The solution is correct under its own assumption. The problem is the assumption itself.

// ❌ This approach breaks with variable-height cards
function reorder<T>(items: T[], cols: number): T[] {
  const out: T[] = [];
  for (let col = 0; col < cols; col++) {
    for (let i = col; i < items.length; i += cols) {
      out.push(items[i]);
    }
  }
  return out;
}

Usage:

// ❌ Broken in production — see explanation below
<div style={{ columnCount: 3, columnGap: "1.5rem" }}>
  {reorder(posts, 3).map((post) => (
    <div key={post.slug} style={{ breakInside: "avoid" }}>
      <PostCard post={post} />
    </div>
  ))}
</div>

The algorithm assumes CSS will put exactly Math.ceil(N / cols) items into each column. That assumption is only valid when every card has the same height.

When cards have different heights — which is always true for real content — CSS distributes items by pixel height, not by count. A tall card in column 1 means that column fills up with fewer items. Column 2 then starts earlier, takes more items, and fills faster. By the time you reach the last column, the distribution is completely different from what the reorder algorithm predicted.

6 cards, heights: [300px, 100px, 150px, 200px, 100px, 250px]
Column target height: ~333px each

Algorithm expects:         CSS actually produces:
Col 1: items 1, 4          Col 1: item 1 (300px) → full
Col 2: items 2, 5          Col 2: items 2, 3, 5 → 350px
Col 3: items 3, 6          Col 3: items 4, 6 → 450px

Result: items appear in wrong visual positions

The reorder step produces the right order for equal-height cards. For real cards, you've just shuffled the content in a way that makes the visual order less predictable, not more.

The reorder trick is only correct when all cards have identical heights. With real content —
varying text lengths, images, tag counts — the algorithm makes ordering worse, not better.

The Correct Approach: Replace CSS Columns With JS Columns

The fix is to stop using column-count entirely. Instead of one CSS container that CSS distributes into columns, create N separate <div> elements — one per column — and distribute items into them in JavaScript using round-robin assignment.

item 0 → col 0
item 1 → col 1
item 2 → col 2
item 3 → col 0  ← back to col 0
item 4 → col 1
item 5 → col 2

The key insight: when JS controls which column each item goes into, CSS has no say in the
distribution. Card heights don't matter. The reading order is always exactly what you specified.

With round-robin assignment, row 1 always contains items [0, 1, 2], row 2 always contains [3, 4, 5] — regardless of how tall each card renders. CSS still controls the visual layout (flex row, gap, column width), but the distribution decision is made entirely in JS before render.

The trade-off: you lose CSS's ability to balance column heights. With column-count, CSS naturally puts more items in a column if the previous items were short. With the JS approach, each column gets exactly Math.ceil(N / cols) items — columns with shorter cards will have more whitespace at the bottom. For most portfolio and blog grid use cases, consistent reading order matters more than height balancing.

Full MasonryGrid Component

Here is the complete TypeScript component, 60 lines including the breakpoint hook:

"use client";

import React, { useEffect, useLayoutEffect, useState, ReactNode } from "react";

// useLayoutEffect on client, useEffect on server (Next.js SSR compatible)
const useIsomorphicLayoutEffect = typeof window !== "undefined" ? useLayoutEffect : useEffect;

interface Breakpoints {
  default: number;
  sm?: number;
  md?: number;
  lg?: number;
}

function getColumns(bp: Breakpoints): number {
  const w = window.innerWidth;
  if (bp.lg && w >= 1024) return bp.lg;
  if (bp.md && w >= 768) return bp.md;
  if (bp.sm && w >= 640) return bp.sm;
  return bp.default;
}

function useColumns(bp: Breakpoints): number {
  const [cols, setCols] = useState(bp.default);
  useIsomorphicLayoutEffect(() => {
    setCols(getColumns(bp));
    function update() {
      setCols(getColumns(bp));
    }
    window.addEventListener("resize", update);
    return () => window.removeEventListener("resize", update);
  }, []); // eslint-disable-line react-hooks/exhaustive-deps
  return cols;
}

interface MasonryGridProps {
  children: ReactNode;
  gap?: string;
  breakpoints: Breakpoints;
}

export function MasonryGrid({ children, gap = "gap-6", breakpoints }: MasonryGridProps) {
  const cols = useColumns(breakpoints);

  // Round-robin distribution: item i goes to column (i % cols)
  const childArray = React.Children.toArray(children);
  const columns: ReactNode[][] = Array.from({ length: cols }, () => []);
  childArray.forEach((child, i) => columns[i % cols].push(child));

  return (
    <div className={`flex ${gap}`}>
      {columns.map((col, colIdx) => (
        <div key={colIdx} className={`flex-1 flex flex-col ${gap}`}>
          {col}
        </div>
      ))}
    </div>
  );
}

Usage on the blog page:

<MasonryGrid gap="gap-6" breakpoints={{ default: 1, md: 2, lg: 3 }}>
  {filtered.map((post) => (
    <ContentCard key={post.slug} item={post} />
  ))}
</MasonryGrid>

A few implementation notes:

useIsomorphicLayoutEffect — Next.js renders on the server where window does not exist. useLayoutEffect throws a warning in SSR context. The isomorphic pattern falls back to useEffect server-side, which is a no-op, and uses useLayoutEffect client-side so the column count is applied before the first paint — preventing a flash of single-column layout on page load.

bp.default as SSR value — useState(bp.default) means the server always renders the smallest column count. On hydration, useIsomorphicLayoutEffect fires synchronously and updates to the correct column count for the viewport. This produces the correct layout with zero layout shift for most visitors, since default: 1 renders a valid single-column layout that gets upgraded immediately.

flex-1 on column divs — columns share available width equally. This is simpler than computing width: calc(100% / cols) and works correctly with arbitrary gap sizes.

Gap as a Tailwind class string — gap="gap-6" lets the caller use any Tailwind spacing token. The same gap applies both between columns (on the flex row) and between items within a column (on the flex column). Passing separate horizontal and vertical gap props is straightforward if you need them.

A Note on Native CSS Masonry

CSS is getting native masonry layout via the display: masonry / grid-template-rows: masonry spec (currently renamed to CSS Grid Lanes). Safari 26.4 shipped stable support. Chrome and Firefox have it behind flags.

/* ❌ Not production-ready — 0.02% global browser support (early 2026) */

/* Older spec name — still referenced widely */
.grid {
  display: masonry;
  masonry-template-tracks: repeat(3, 1fr);
  gap: 1.5rem;
}

/* Newer name (CSS Grid Lanes) — same situation */
.grid {
  display: grid-lanes;
  grid-template-columns: repeat(3, 1fr);
  gap: 1.5rem;
}

You will see both names in articles and browser release notes — display: masonry was the original proposal, display: grid-lanes is the current direction after the CSS Working Group renamed the spec in 2024. They are the same feature at different stages. Neither is production-ready: only Safari 26.4 ships stable support, Chrome and Firefox are behind flags. Global coverage in stable browsers is approximately 0.02% as of early 2026. Until this lands across all engines, the JS approach in this post is what you ship.

Reading order in a masonry grid is one of those problems that looks solved until you add real content. The popular reorder algorithm assumes equal heights — a constraint you can't guarantee in any real application. Separate flex columns with round-robin JS distribution is the correct fix: reading order is always exact, the implementation is transparent, and it works in Next.js without any client-side workarounds beyond the isomorphic effect hook.

I build portfolio sites, SaaS frontends, and e-commerce UIs where layout correctness matters. If you need a senior developer who handles the full stack — from grid algorithms to checkout flows — get in touch.

Related reading:

How I Synced 6 CSS Keyframe Animations Without a Single Library — more CSS-from-first-principles work
Dynamic OG Images in Next.js: Why opengraph-image.tsx Hangs Turbopack — another case where the documented approach breaks in production
Jesse Korzan — Masonry Layout Technique (Medium) — the original reorder technique, works perfectly with uniform card heights
CSS Grid Level 3 — Masonry Layout (W3C draft spec for native masonry)
MDN: column-count — official reference for the CSS primitive

Binary PDF Modification Detection: How It Works and Where It Fails

Iurii Rogulia — Tue, 24 Feb 2026 15:01:22 +0000

The question sounds simple: has this PDF been edited after it was originally created? The answer, it turns out, requires understanding how PDF files store their history at the byte level.

This article explains the technical approach behind binary PDF modification detection — what signals we look for, why they are reliable, and critically, where the method breaks down. If you want a quick answer without the technical detail, HTPBE.tech is an online tool that tells you whether a PDF has been edited (yes/no) in seconds. If you want to understand how that answer is produced, read on.

How a PDF File Is Structured

Before discussing detection, you need to understand the PDF file format at a structural level.

A PDF file consists of four components:

Header — declares the PDF version (%PDF-1.7)
Body — a collection of numbered objects (pages, fonts, images, metadata)
Cross-reference table (xref) — an index mapping object numbers to byte offsets
Trailer — points to the xref table and the document root object

A minimal trailer looks like this:

trailer
<<
  /Size 42
  /Root 1 0 R
  /Info 2 0 R
>>
startxref
9876
%%EOF

The /Info entry points to the document information dictionary — this is where metadata lives.

The Metadata Dictionary

The PDF Information Dictionary (/Info) contains fields that describe the document’s origin and history:

Field	Meaning
`/CreationDate`	When the document was originally created
`/ModDate`	When the document was last modified
`/Creator`	Application that created the source document (e.g., Microsoft Word)
`/Producer`	PDF library or printer that generated the PDF (e.g., macOS Quartz PDFContext)
`/Author`	Document author
`/Title`	Document title

Dates are encoded in a specific format:

D:20231015143022+03'00'

This means: 2023-10-15 at 14:30:22, UTC+3. The timezone offset is significant — we will come back to it.

The Creator/Producer distinction matters enormously. When someone writes a document in Microsoft Word and exports it to PDF:

Creator = Microsoft Word
Producer = Microsoft Word (or a Word-internal PDF engine)

When someone then opens that PDF in Adobe Acrobat and edits it:

Creator stays as Microsoft Word (preserved from original)
Producer changes to Adobe Acrobat 23.0 (the tool that wrote the new version)

This mismatch is a strong signal of modification.

The Incremental Save Mechanism

This is the core of PDF modification detection, and it is what makes PDFs fundamentally different from most other file formats.

When you edit a PDF and save it, most PDF editors do not rewrite the entire file. Instead, they append changes to the end:

The original file body is left intact
New or modified objects are appended after %%EOF
A new cross-reference table is appended, containing entries for the changed objects
A new trailer is appended with a /Prev field pointing to the byte offset of the previous xref table

[original body]
%%EOF
[new objects]
xref
[new xref entries]
trailer
<<
  /Size 55
  /Root 1 0 R
  /Prev 9876          ← points to original xref
>>
startxref
14523
%%EOF

This incremental update mechanism exists for good reasons: it enables fast partial saves, supports undo history, and is required for certain digital signature workflows. But it also leaves a clear paper trail.

A PDF with multiple %%EOF markers, multiple xref sections, or a trailer with /Prev has been saved more than once. This does not automatically mean fraud — legitimate workflows involve multiple saves. But it is a definitive indicator that the file was modified after initial creation.

What Automated Detection Actually Examines

A detection tool like HTPBE examines several independent signals and combines them into a confidence score.

1. Timestamp Consistency

The simplest check: is ModDate later than CreationDate? If yes, the file was modified. But there are subtleties:

ModDate == CreationDate does not mean the file was never edited. Some editors reset ModDate to match CreationDate to hide modifications.
ModDate earlier than CreationDate is impossible under normal conditions and indicates tampering with metadata.
Timezone changes between CreationDate and ModDate (e.g., creation in +03'00' but modification in Z) suggest the file was modified on a different machine or with a different tool.

2. Cross-Reference Table Analysis

Counting xref sections reveals the number of save operations:

1 xref section: the file was saved exactly once — typical for freshly exported PDFs
2+ xref sections: the file was modified at least once after initial creation
3+ xref sections: multiple rounds of editing

The content of the xref updates also matters. If the updated objects include the /Info dictionary (metadata), it suggests metadata was modified after the fact.

3. Creator/Producer Mismatch Analysis

We maintain a knowledge base of known PDF creation tool combinations. Some mismatches are routine:

Creator: Word + Producer: Adobe PDF Printer — normal, Word printed to PDF
Creator: Google Docs + Producer: Skia/PDF — normal Google Docs export

Some mismatches are suspicious:

Creator: Microsoft Excel + Producer: iLovePDF — the file was processed by an online editor
Creator: LibreOffice + Producer: Adobe Acrobat — the file was opened and re-saved in Acrobat
Creator: (empty) + Producer: FPDF — programmatically generated, may be a reconstructed document

The tool also looks for editors known to be used for document fraud: certain online PDF editors, specific versions of commercial tools with known history-stripping features.

4. Digital Signature Integrity

PDF supports cryptographic digital signatures (/Sig objects). When a signed PDF is modified:

The signature covers specific byte ranges of the file
If content outside those byte ranges is modified, the signature becomes invalid
If the signature object itself is removed and the document re-saved, the absence of a previously-present signature is detectable via the revision history

5. Object Stream Anomalies

PDF 1.5+ supports compressed object streams. Legitimate PDF generators produce consistent, well-formed object streams. Anomalies we check for:

Objects with inconsistent generation numbers
Orphaned objects not reachable from the document root
Objects that exist in the xref table but whose byte offsets point to different object types (indicates partial overwrite attempts)

Putting It Together: The Confidence Score

No single signal is conclusive. A document with ModDate > CreationDate might be completely legitimate. A document with matching timestamps might have been forged with a tool that resets them.

Detection tools combine multiple signals into a weighted confidence score:

Signal	Weight	Rationale
Multiple xref sections	High	Hard to fake without specialized knowledge
Creator/Producer mismatch with known editor	Medium-High	Common in legitimate workflows too
Timestamp anomaly (impossible date)	High	Never legitimate
Timestamp anomaly (reset to match)	Medium	Detectable but requires suspicion
Known fraud-associated producer	Medium	Context-dependent
Digital signature removed	High	Strong indicator of post-signing modification

A score above a threshold produces a “Modified” verdict. Below the threshold: “Original”. The threshold is calibrated to minimize false positives on legitimate documents.

False Positives: When Unmodified PDFs Look Modified

This is where the method has real limitations.

Legitimate workflows that trigger modification signals:

PDF/A conversion — archival format conversion modifies the file structure. ModDate will differ from CreationDate even if content is unchanged.
Digital signing — adding a digital signature is a modification. A signed-after-creation document will show multiple xref sections even if the content was never altered.
Optimization — tools like Ghostscript, qpdf, or Adobe Acrobat’s “Reduce File Size” rewrite the entire file, resetting the xref structure but potentially preserving old timestamps.
Printer workflows — some enterprise print systems re-process PDFs (adding watermarks, headers, or compliance stamps) as a routine step.
Email clients — some email clients modify PDF attachments (adding metadata, stripping features) during send or receive.
Merging or splitting — combining PDFs with tools like PDFtk or iLovePDF creates a new document with a new Producer and potentially inconsistent metadata from the source files.

In all these cases, the document content may be perfectly authentic, but the structural signals indicate modification. This is why results should always be interpreted in context.

False Negatives: When Modified PDFs Look Original

More dangerous is the opposite case: a forged document that passes detection.

Techniques that evade detection:

Full reconstruction — printing to PDF (or using print → save as PDF) creates a completely new file with a fresh xref, consistent timestamps, and a single clean structure. All modification traces are lost. The resulting PDF looks freshly created, even if it was forged.
Metadata scrubbing — tools like exiftool or custom scripts can overwrite all metadata fields, including timestamps and creator information, before the file is distributed. A sophisticated forger resets CreationDate = ModDate and sets Producer to match the expected original tool.
Re-export from source format — if the forger has access to the source document (a Word file, for example), they can modify the source and re-export to PDF. The resulting PDF has no modification traces because it was never “modified” — it was created fresh from a modified source.
PDF reconstruction tools — specialized tools can parse a modified PDF and reconstruct it as a clean single-revision file, stripping all incremental save history.

The fundamental limitation: binary detection works on file structure, not content. We can detect that a file’s structure shows signs of modification, but we cannot verify whether the visible text or numbers are correct. A forger skilled enough to reconstruct the PDF properly can evade structural detection entirely.

What This Means in Practice

Binary PDF modification detection is a fast, automated first-line check. It catches:

Naive modifications made with standard PDF editors (the vast majority of document fraud cases)
Metadata inconsistencies that reveal post-creation editing
Structural anomalies that indicate multiple save operations

It does not catch:

Sophisticated forgeries where the PDF was fully reconstructed
Source-level modifications (edit the Word doc, re-export)
Cases where the file was “legitimately” processed by a PDF workflow tool

For high-stakes verification (legal documents, financial instruments, regulated industries), automated detection should be combined with:

Human review of the document content for semantic consistency
Verification of the document’s origin through the issuing party
Cryptographic verification if the original was digitally signed
Chain-of-custody controls that prevent the question from arising

Technical Implementation Notes

For developers building similar tools, the key libraries:

pdf-lib (JavaScript/Node.js) — parse PDF structure, read xref tables, access object streams
PyMuPDF / fitz (Python) — comprehensive PDF analysis, supports most PDF versions
pdfminer.six (Python) — lower-level access to PDF internals
iTextSharp (.NET) — commercial-grade PDF analysis

The core algorithm:

Parse the xref table(s) — count revisions
Extract /Info dictionary — compare timestamps, analyze Creator/Producer
Walk the xref chain via /Prev pointers — identify which objects changed between revisions
Check for /Sig objects — verify digital signature presence and coverage
Score each signal — weight by reliability and combine

The implementation challenge is handling malformed PDFs. Real-world documents frequently deviate from the PDF specification. A robust tool must handle:

Missing or corrupted xref tables (PDF readers use recovery mode)
Linearized PDFs (a different structure used for web-optimized files)
Encrypted PDFs (metadata may be accessible even if content is not)
PDF 2.0 documents with new structural features

Conclusion

Binary PDF modification detection is a reliable heuristic, not a cryptographic proof. It answers the question “does this file’s structure suggest modification?” with high accuracy for everyday document fraud. Against a skilled adversary who understands PDF internals, structural detection alone is insufficient.

The honest answer to “has this PDF been edited?” is: we can tell you what the file’s structure reveals. For most fraud cases — edited invoices, tampered bank statements, modified contracts — that is enough.

HTPBE.tech implements the detection approach described in this article. The web tool is free, requires no registration, and processes PDFs in seconds. The API is available for integration into document verification workflows.

Forem: Iurii Rogulia

5 Signs a PDF Document Has Been Tampered With

Why Document Tampering Is a Growing Concern

Sign #1: Mismatched Creation and Modification Dates

What to Look For

How to Check

Why This Matters

Limitations

Sign #2: Suspicious Producer/Creator Applications in Metadata

Understanding Metadata Fields

What to Look For

How to Check

Real-World Examples

Why This Matters

Sign #3: Visual Inconsistencies (Fonts, Spacing, Alignment)

Font Inconsistencies

Spacing and Alignment Issues

Image Quality Problems

Color and Style Inconsistencies

Sign #4: Invalid or Missing Digital Signatures

How Digital Signatures Work

What to Look For

How to Check

Why This Matters

Real-World Example

Sign #5: Multiple Revision Layers or Incremental Updates

Understanding Incremental Updates

What to Look For

How to Check

Why This Matters

Bonus: What These Signs Mean (Fraud vs Legitimate Edits)

Legitimate Modifications

Suspicious Modifications

Context Matters

The Automated Solution: Let Technology Do the Work

Why Automated Tools Are Superior

What HTPBE Checks

When to Use Automated Verification

Conclusion

React Masonry Layout: Why the Popular Reorder Trick Fails

Why column-count Breaks Ordering

The Popular Reorder Algorithm — And Why It Fails

The Correct Approach: Replace CSS Columns With JS Columns

Full MasonryGrid Component

A Note on Native CSS Masonry

Binary PDF Modification Detection: How It Works and Where It Fails

How a PDF File Is Structured

The Metadata Dictionary

The Incremental Save Mechanism

What Automated Detection Actually Examines

1. Timestamp Consistency

2. Cross-Reference Table Analysis

3. Creator/Producer Mismatch Analysis

4. Digital Signature Integrity

5. Object Stream Anomalies

Putting It Together: The Confidence Score

False Positives: When Unmodified PDFs Look Modified

False Negatives: When Modified PDFs Look Original

What This Means in Practice

Technical Implementation Notes

Conclusion

Why `column-count` Breaks Ordering