Why Comparing PDFs Is Still Surprisingly Difficult

If you've ever had someone send you two PDF files and ask "what changed?", you probably know how this usually goes. Open the first file. Open the second one. Put them next to each other. Start scrolling. After a few pages, you realize that you're not actually comparing the documents anymore. You're comparing your memory of what you just saw with what you're looking at now. It gets worse when the PDFs are nearly identical. A 200-page contract with one changed sentence is harder to review than two completely different documents. The less that changed, the easier it is for the important change to disappear into everything that stayed the same. This is a problem that seems like it should have been solved a long time ago. We have git diff, IDE diff viewers, image comparison tools, database migration tools, and all kinds of sophisticated ways to answer a simple question: What changed? PDFs are one of the places where that question is still surprisingly awkward. A PDF isn't really a text document One reason is that a PDF doesn't behave like a Markdown file, source file, or plain text document. If I have two source files: version 1: const timeout = 30; version 2: const timeout = 60; A normal diff has a very clear job. The underlying representation is text, so comparing the two versions is straightforward. A PDF is different. A page might contain: text fonts images vector graphics tables headers and footers page numbers positioned elements embedded metadata annotations different rendering instructions The text might be identical while the rendered page is different. And the opposite can happen too: two PDFs can look almost identical while containing a meaningful textual change. That makes "PDF diff" a slightly different problem from ordinary text diff. The obvious solution: extract the text If you're a developer, one of the first things you might try is extracting the text from both files. For example: pdftotext old.pdf old.txt pdftotext new.pdf new.txt diff -u old.txt new.txt This is actually a pretty useful solution. For simple documents, it may be all you need. You can put it into a shell script, run it in CI, or process PDFs with one of the many PDF libraries available for Python, JavaScript, Java, Go, and other languages. But there is an annoying limitation. You aren't really comparing the PDFs. You're comparing the text extracted from the PDFs. Those aren't always the same thing. Imagine a report where someone changes the position of a table. The text extraction could be identical: Revenue 2024 $1.2M 2025 $1.8M But the actual PDF might have a completely different layout. Or someone replaces a chart with a new image. The text diff may report nothing. The PDF has clearly changed. Visual comparison catches a different class of changes This is where rendering each page to an image and comparing the images becomes useful. A simplified workflow might look like this: PDF A ↓ Render pages ↓ Images A PDF B ↓ Render pages ↓ Images B Images A + Images B ↓ Pixel comparison ↓ Visual differences This catches things that text extraction misses. For example: a logo was replaced a table moved a font changed a paragraph wrapped differently an image was resized a footer moved a page break changed a signature block disappeared But visual comparison has its own problems. A one-pixel rendering difference can generate a huge number of changed pixels. Different PDF rendering engines can produce slightly different output. Anti-aliasing can make otherwise identical text appear different at the pixel level. So a raw image diff isn't necessarily what a person wants to see. The interesting part isn't detecting that 14,381 pixels changed. The interesting part is understanding why they changed. Text diff and visual diff solve different problems This is why I think PDF comparison is better thought of as two related problems. Text comparison It answers questions such as: Was this sentence changed? Was a number modified? Was a paragraph added or removed? Did a clause change from 30 days to 15 days? Visual comparison It answers questions such as: Did the layout change? Did an image move? Did a table change? Did a page break move? Did something disappear visually? Neither approach completely replaces the other. For serious document review, having both views is much more useful than choosing one. The "one tiny change" problem There is another reason PDF comparison is frustrating. Most of the time, people aren't comparing PDFs because the entire document is different. They're comparing them because something small changed. Maybe a lawyer received a revised contract and wants to know what changed since yesterday. Maybe a designer exported a new proof and wants to check whether anything moved. Maybe a finance team generated this month's report and wants to compare it with last month's version. Maybe a developer changed a PDF generation template and needs to verify the output. In all of these situations, the important information might represent 0.1% of the document. The other 99.9% is noise. That's exactly what a useful comparison tool should reduce. Instead of asking someone to inspect 100 pages, the goal is to bring attention to the pages and regions that actually changed. Contracts are a particularly good example Consider a 70-page agreement. Version A says: Payment must be made within 30 days. Version B says: Payment must be made within 15 days. Visually, the two documents may look almost identical. The difference is one number. But that one number can matter considerably more than everything else in the document. A manual side-by-side review has a bad property here: the reviewer has to spend roughly the same amount of attention on unchanged material as changed material. A diff reverses that. Instead of showing you the entire document and asking you to find the changes, it starts with the changes and lets you inspect the surrounding context. That's the basic idea behind almost every useful diff tool, and PDFs shouldn't be an exception. Generated PDFs create another interesting problem PDF comparison isn't only useful for lawyers and document reviewers. It's also useful for developers who generate PDFs automatically. Suppose your application generates invoices. You change the HTML template. The code compiles. The tests pass. The invoice is generated successfully. Nothing crashes. But now the total is pushed onto another line, a table is slightly wider, or a footer overlaps some content. A normal unit test may not catch that. This is where PDF comparison can become part of a testing workflow. You can generate a known document, compare it against an expected version, and investigate unexpected changes. This is similar to visual regression testing for websites. The difference is that the output is a PDF rather than a browser screenshot. For document-heavy applications, that can be surprisingly useful. But automation isn't always the answer It's tempting to turn everything into a pipeline. Sometimes that's exactly right. If you're generating thousands of PDFs, you probably don't want a human opening them one by one. But if you're comparing two documents once, building a custom PDF processing pipeline can be overkill. There's a large gap between: "I need to compare these two files right now." and: "I need an automated document-diff system integrated into our CI infrastructure." The first problem benefits from convenience. The second benefits from APIs, scripting, reproducibility, and automation. A good workflow should recognize the difference. Privacy matters more than it first appears There's also a less obvious issue with PDF comparison. Documents often contain information that shouldn't be casually uploaded somewhere. Think about: employment contracts customer invoices financial statements internal reports legal agreements product specifications unreleased documentation If you're comparing those files, where the comparison happens matters. There is a big difference between: Browser ↓ Process document locally ↓ Show result and: Browser ↓ Upload document ↓ Remote server ↓ Process document ↓ Return result Neither architecture is automatically right or wrong for every situation. Server-side processing can make certain features easier. Client-side processing can reduce the need to send sensitive documents to a server. The important thing is that users should know which model they're using. For document tools, privacy isn't just a checkbox in a settings page. It's part of the workflow. Why I built PdfCompare This was one of the reasons I started working on PdfCompare. The basic idea is pretty simple: I didn't want PDF comparison to require a large desktop application for every small task. If someone has two PDFs and wants to know what changed, there should be a straightforward way to do that from a browser. PdfCompare focuses on comparing PDFs directly in the browser, with both textual and visual differences available for inspection. The browser-based approach is particularly useful for quick comparisons where installing software, creating an account, or setting up a document-processing workflow feels like more work than the actual task. You can use a pdf compare tool when you simply need to answer the question "what changed between these two files?" without turning the task into a larger software project. What I think a useful PDF diff should show After working through the problem, I think there are a few things that make a PDF comparison workflow genuinely useful. 1. Don't hide the original documents The comparison is easier to understand when you can still inspect the original pages. A diff shouldn't become another opaque representation that requires interpretation. 2. Make small changes obvious If one word changed in a paragraph, the user shouldn't have to scan the entire page to find it. The changed region should stand out. 3. Show context Highlighting a changed word is useful. Showing that word in the context of the surrounding paragraph is better. The user needs enough of the original document to understand what the change means. 4. Handle visual changes separately A changed image isn't necessarily a text change. A moved table isn't necessarily a text change. A visual comparison mode makes those changes much easier to inspect. 5. Don't make users install something for every small job Desktop applications still have their place. So do command-line tools and libraries. But there should also be a low-friction option for someone who just received: contract-final.pdf contract-final-2.pdf and wants to know what happened between them. Where command-line tools still win None of this means browser tools replace developer tooling. If I'm building an automated system, I'd rather have a scriptable library than manually upload documents somewhere. For example, a development team might want: Generate PDF ↓ Compare against baseline ↓ Detect unexpected changes ↓ Fail CI if necessary That's a completely different requirement. Tools such as pdftotext, PDF parsing libraries, rendering libraries, ImageMagick, and custom comparison algorithms can be combined to build sophisticated workflows. The advantage is control. The downside is engineering time. There isn't one perfect PDF comparison workflow. There are just different workflows for different problems. The part that still feels strange What's surprising to me is how mature document formats and developer tooling have become, yet this particular problem remains so common. We routinely compare: Git commits JSON files CSV files source code images database schemas configuration files But when the output becomes a PDF, the workflow often goes back to: Open both files and look carefully. PDFs are everywhere in business. They're used for contracts, invoices, reports, specifications, applications, manuals, academic papers, and exported application data. So "what changed?" is a question worth answering well. A practical rule of thumb If you're comparing source documents during development, use a text or structured diff whenever possible. If you're validating generated PDFs, consider combining text comparison with visual regression testing. If you're reviewing contracts or business documents, you probably want a human-readable diff that makes meaningful changes easy to inspect. And if you simply have two PDFs sitting on your desktop and need to know what changed, use the simplest workflow that gets you the answer. That's ultimately what PdfCompare is trying to solve. Not "PDFs are complicated." Not "we need another PDF editor." Just this: You have two versions of a document. You want to see what changed. That shouldn't require manually reading both documents from beginning to end.