DEV Community: VernonHeim

Why Comparing PDFs Is Still Surprisingly Difficult

VernonHeim — Fri, 04 Sep 2026 01:23:17 +0000

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.

Building a Peer-to-Peer Clipboard Sync System with WebRTC

VernonHeim — Mon, 10 Aug 2026 02:32:22 +0000

A few months ago, I noticed a small but annoying workflow problem.

I was constantly moving small pieces of information between devices.

A code snippet from my laptop to my phone.

A URL from one browser to another.

A temporary note that I needed somewhere else.

The amount of data was never the problem. The problem was the unnecessary friction.

Most clipboard synchronization tools solve this problem by introducing a cloud service:

Device A
    |
    |
    v
Cloud Server
    |
    |
    v
Device B

This approach is simple and reliable, but it also means clipboard content leaves your devices.

For many cases, that may be acceptable. But clipboard data can contain sensitive information:

Passwords
Authentication codes
Private messages
Source code
Temporary documents

Clipboard content is usually short-lived. It exists for seconds or minutes and then disappears.

This raised an interesting question:

Can we synchronize clipboard content directly between devices without sending it to a server?

The answer is yes, using WebRTC DataChannels.

The architecture

The basic idea is simple:

             Signaling Server

          Exchange connection data

Device A  -------------------- Device B

             WebRTC DataChannel

          Direct peer-to-peer data

The signaling server is only responsible for helping devices discover each other.

It exchanges:

Session descriptions
ICE candidates
Connection information

After the connection is established, clipboard data travels directly between peers.

The data flow changes from:

Copy
 |
Upload
 |
Store on server
 |
Download
 |
Paste

to:

Copy
 |
Create message
 |
WebRTC DataChannel
 |
Receive
 |
Update clipboard

Why WebRTC DataChannel?

WebRTC is mostly known for video calls and real-time communication.

However, the most interesting part for this use case is DataChannel.

DataChannel allows browsers to exchange arbitrary data directly between peers.

It provides:

Low latency communication
Peer-to-peer transport
Encrypted communication
Support for text and binary data

Clipboard synchronization does not require huge bandwidth.

A clipboard update is usually just a small message:

{
  "type": "clipboard",
  "content": "Hello from another device",
  "timestamp": 1720000000
}

There is no reason to upload this tiny piece of data to a central storage system.

Detecting clipboard changes

The first challenge is clipboard monitoring.

Modern browsers provide the Clipboard API:

const text = await navigator.clipboard.readText();

console.log(text);

However, clipboard access is intentionally restricted.

Browsers do this because unrestricted clipboard access would create serious security problems.

A malicious website could silently read:

Passwords copied from password managers
One-time authentication codes
Private conversations

Therefore, applications need proper permissions and user interaction.

A simplified clipboard reader:

async function getClipboardContent() {
    const content = await navigator.clipboard.readText();

    return {
        type: "clipboard",
        content
    };
}

Once new content is detected, it can be sent through the WebRTC connection.

Sending clipboard data through WebRTC

Creating a DataChannel is straightforward:

const channel =
    peerConnection.createDataChannel(
        "clipboard"
    );

channel.onopen = () => {
    console.log("Connected");
};

Sending clipboard content:

channel.send(
    JSON.stringify({
        type: "clipboard",
        content: text
    })
);

Receiving data:

channel.onmessage = event => {

    const message =
        JSON.parse(event.data);

    if(message.type === "clipboard") {
        navigator.clipboard.writeText(
            message.content
        );
    }
};

The browser does not need to know the physical location of the other device.

WebRTC handles the communication layer.

The difficult part: establishing the connection

The DataChannel itself is simple.

The complicated part is creating the connection.

WebRTC requires:

SDP negotiation
ICE candidate exchange
NAT traversal
STUN/TURN infrastructure

The connection process looks like:

Device A

Create Offer

      |
      v

Signaling Server

      |
      v

Device B

Create Answer

After both devices exchange connection information, WebRTC attempts to create the best possible network path.

In many home networks, devices can communicate directly.

However, some environments are more complicated:

Corporate networks
Strict NAT
Mobile carrier networks

In those situations, TURN servers may be required as a relay.

Preventing clipboard synchronization loops

A real implementation quickly runs into another problem.

Imagine two devices:

Device A copies:

Hello

The content is sent to Device B.

Device B updates its clipboard.

The clipboard watcher on Device B detects the change.

Now Device B sends the same content back to Device A.

Without protection:

Device A
    |
    v
Device B
    |
    v
Device A
    |
    v
Device B

To prevent this, each clipboard message needs metadata.

Example:

{
  "id": "unique-message-id",
  "source": "device-a",
  "type": "clipboard",
  "content": "Hello"
}

Devices can keep a small history of processed message IDs.

If the same message appears again, it is ignored.

Security considerations

Clipboard synchronization requires careful handling.

A good design should consider:

Avoid permanent storage

Clipboard data should only exist during transmission.

Saving clipboard history introduces unnecessary risk.

Encrypt communication

WebRTC provides encrypted communication channels.

The goal is that clipboard content should only be readable by the connected devices.

Verify connected devices

A user should always know which devices are paired.

A clipboard synchronization tool should never silently connect unknown devices.

Why not use a traditional backend?

A backend API would be easier:

POST /clipboard

GET /clipboard

This design is simple.

But it creates a central point that receives clipboard data.

The trade-off looks like this:

Cloud based approach

Advantages:

Easier implementation
Works across networks
Simple device history

Disadvantages:

Server receives clipboard data
Requires storage handling
Privacy concerns

Peer-to-peer approach

Advantages:

Data stays between devices
No temporary cloud storage
Lower latency

Disadvantages:

More networking complexity
Requires WebRTC connection management

For temporary personal data, peer-to-peer communication is an interesting alternative.

Building a real implementation

While exploring this architecture, I built Textunnel, a browser-based tool for moving text, code, and files between devices.

The clipboard synchronization feature follows the same idea: keep your data moving directly between your own devices.

You can try it here:

clipboard sync

Final thoughts

Clipboard synchronization looks like a small feature, but building it properly involves many interesting engineering problems:

Browser security restrictions
Real-time communication
WebRTC networking
NAT traversal
Peer-to-peer architecture

WebRTC is often introduced as a technology for video calls.

But DataChannels make it possible to build many other types of applications.

Sometimes the best way to move your data is not through a server.

Sometimes it is directly between the devices that already belong to you.

How WebRTC Enables Fast and Private Peer-to-Peer File Sharing

VernonHeim — Mon, 20 Jul 2026 14:00:28 +0000

Sharing content between devices sounds like a simple problem.
I explored this everyday frustration in more detail in Why Moving Files Between My Own Devices Is Still More Complicated Than It Should Be.

You copy some text on your laptop, open your phone, and realize there is no easy way to move that information. Maybe it is a code snippet, a temporary file, a URL, or a piece of text you need immediately.

Traditional solutions usually rely on cloud storage:

Upload data to a server
Store it temporarily
Download it on another device

This works, but it introduces additional complexity:

Your data needs to travel through third-party servers
Temporary information may be stored longer than expected
Users need accounts and complicated workflows

WebRTC provides another approach: direct peer-to-peer communication.

What is WebRTC?

WebRTC (Web Real-Time Communication) is an open technology that enables browsers and applications to exchange data directly between devices.

Originally designed for real-time communication such as:

Video calls
Audio communication
Screen sharing

WebRTC also supports direct data transfer through the RTCDataChannel API.

This makes it possible to build applications where devices can communicate without sending every piece of data through a centralized server.

How Peer-to-Peer Data Transfer Works

A simplified WebRTC data transfer flow looks like this:

Device A
   |
   | 1. Create connection request
   |
Signaling Server
   |
   | 2. Exchange connection information
   |
Device B
   |
   | 3. Establish direct P2P connection
   |
Encrypted Data Channel

The signaling server is only responsible for helping devices discover each other.

After the connection is established, the actual data can flow directly between peers.

Why Peer-to-Peer Sharing Matters

For many everyday tasks, users do not need a full cloud storage system.

Examples:

Sending a code snippet from a desktop to a laptop
Moving a URL from a phone to a computer
Sharing a small document during development
Transferring temporary files between personal devices

In these situations, speed and privacy are often more important than long-term storage.

A peer-to-peer approach provides several advantages.

1. Faster Transfers

When devices communicate directly, data does not need to travel through a large storage infrastructure.

This can reduce latency, especially for users on the same network.

2. Better Privacy

With traditional file sharing:

User → Cloud Server → User Device

The server becomes part of the data path.

With peer-to-peer communication:

User Device → User Device

The communication is more direct.

3. No Account Required

Many temporary sharing scenarios do not need:

User accounts
Password management
Permanent storage

A lightweight connection can solve the problem immediately.

The Challenges of Building WebRTC Applications

Although WebRTC is powerful, building a reliable application requires solving several problems.

NAT Traversal

Most devices are behind routers or firewalls.

To establish connections, WebRTC uses:

ICE (Interactive Connectivity Establishment)
STUN servers
TURN servers when direct connections fail

The goal is to find the best possible communication path.

Connection Management

Real-world networks are unpredictable.

Applications need to handle:

Connection failures
Device switching
Network changes
Browser compatibility

User Experience

A technically correct WebRTC implementation can still fail if the user experience is complicated.

Users usually want:

Open
Connect
Share

Not:

Create an account
Configure settings
Upload files
Manage storage

Building Simpler Cross-Device Experiences

Modern users often work across multiple devices:

Desktop computers
Laptops
Phones
Tablets

The problem is not always file storage.

Sometimes users simply need a temporary bridge between their devices.

This idea inspired us to build Textunnel, a privacy-focused cross-device sharing tool designed for quickly moving text, code, links, and files between devices.

We also shared the story behind this decision, including why we chose a peer-to-peer approach instead of building another traditional cloud storage service in Why We Built a Peer-to-Peer File Sharing Tool Instead of Another Cloud Storage App.

Instead of creating another cloud drive, the goal is to make device-to-device communication simpler.

Taking WebRTC Beyond Theory

I didn't just want to understand WebRTC — I wanted to build something people
could actually use. So I created Textunnel, a
browser-based tool for peer-to-peer file and text sharing.

A few of the specific tools I've built on top of WebRTC:

QR File Transfer Without Internet uses QR codes for signalling, so you can transfer files without any internet connection at all
Bluetooth WebRTC File Transfer Without WiFi combines Bluetooth discovery with WebRTC data channels for local transfers
Share Clipboard Text Across Operating Systems lets you copy text on one device and paste it on another — regardless of OS

Each of these tools uses the same WebRTC fundamentals we covered above, just
optimized for a specific use case.

The Future of Peer-to-Peer Applications

As browsers become more capable, peer-to-peer technologies will continue to create new possibilities:

Decentralized collaboration tools
Private communication platforms
Local-first applications
Real-time developer workflows

WebRTC is not only a technology for video calls. It is a foundation for building faster, more private, and more user-controlled applications.

For developers building the next generation of productivity tools, peer-to-peer communication is worth exploring.
This idea inspired us to build Textunnel...