Free PDF Compare Online
Compare two PDF files side by side with visual difference highlighting. Instant results, no upload to any server.
Supports PDF files · up to 100 MB
Supports PDF files · up to 100 MB
How It Works
- Upload your first PDF by selecting or dragging it into the left drop zone.
- Upload your second PDF into the right drop zone.
- Choose your viewing mode: "Side by Side" displays both PDFs together, "Overlay" shows differences highlighted in red.
- Navigate through pages using the Previous/Next buttons or by entering a page number directly.
- In overlay mode, red highlights indicate pixel differences between the same page numbers in both documents.
Why Compare PDFs?
PDF comparison is essential for version control, quality assurance, and document management. Use it to track changes between document revisions, verify that edits were applied correctly, identify unauthorized modifications, compare contract or legal document versions, validate form submissions, and ensure document consistency across multiple copies. Automated difference highlighting saves time and reduces errors compared to manual review.
View Modes Explained
- Side by Side · View both PDFs simultaneously on the same screen. Ideal for spotting obvious layout changes, additions, or deletions. Both PDFs navigate independently.
- Overlay · Layers the second PDF over the first and highlights all pixel differences in red. Perfect for detailed change detection. Both PDFs must have the same page count for comparison.
Use Cases
- Version Control · Track changes between document versions and identify what was modified.
- Legal & Contracts · Compare contract versions to ensure all amendments were applied correctly.
- Compliance · Verify that forms and reports match approved templates or previous versions.
- Quality Assurance · Validate that generated documents match expected outputs.
- Fraud Detection · Identify unauthorized modifications or tampering in PDFs.
Frequently Asked Questions
How does overlay mode highlight differences?
Overlay mode performs a pixel-by-pixel comparison of the rendered pages. Any pixel that differs between the two PDFs is highlighted in red. This catches text changes, image modifications, spacing adjustments, and any other visual differences.
Can I compare PDFs with different dimensions?
Yes. PDFs with different page sizes are fully supported. In side-by-side mode, each PDF renders at its native size. In overlay mode, the first PDF determines the canvas dimensions.
What about scanned or image-based PDFs?
Scanned PDFs (composed of raster images) are fully supported. The comparison works by rendering both PDFs and comparing the visual output, so it detects changes in scanned documents just like any other PDF.
Can I compare encrypted PDFs?
This tool works with standard PDFs. If your PDFs are password-protected or encrypted, you'll need to remove the protection first using a PDF unlocking tool before you can compare them.
How large can my PDFs be?
Each PDF can be up to 100 MB. Processing time depends on file size, page count, and your device specifications. Very large files may take several seconds to load and render.
Is the comparison 100% accurate?
Yes, for visual differences. The tool performs exact pixel-by-pixel comparison, so it will detect any visual change. However, it compares rendered output, not underlying PDF structure-minor rendering differences due to fonts or PDF libraries might appear as differences when the actual content is identical.
What is a PDF compare tool?
A PDF compare tool takes two PDF files and shows you what changed between them. The hard part is defining what change means. For documents that look the same, you want a tool that says identical, even if the underlying bytes differ because they were generated by different software. For documents that contain real edits, you want a tool that highlights exactly where the text, layout, or images changed. Different comparison strategies make different trade-offs between catching real changes and ignoring noise.
This tool uses visual comparison: each page from both PDFs is rendered to a pixel grid, and the two grids are overlaid. Pixels that match are shown as the background; pixels that differ are highlighted in red. This catches every visual change, including layout shifts, font substitutions, image edits, and text rewrites. It does not catch invisible changes (PDF metadata, hidden form fields, embedded JavaScript), which is a feature: those rarely matter for typical document review.
Everything runs in your browser using pdf.js (Mozilla's PDF renderer) and pdf-lib (PDF manipulation library). Both PDFs are loaded into memory, rendered to canvas elements, and the pixel comparison runs in JavaScript on your machine. No file is uploaded to a server. The tool handles PDFs up to 100 MB and works on standard digital PDFs, scanned PDFs, and PDFs from any source as long as they are not password-encrypted.
What is inside the tool
The top section has two drop zones side by side: drop the original PDF on the left, the revised PDF on the right. The labels make it obvious which is which, so you do not accidentally interpret added text as removed text. Both files can be dragged from your file manager or selected with a file picker. As soon as both files are loaded, the tool reports the page count of each, which is the first signal of whether real changes happened.
Below the drop zones, a view-mode toggle switches between Side by Side (both pages rendered next to each other) and Overlay (both pages combined with differences highlighted in red). Side by Side is best for a first look or for sharing screenshots. Overlay is where the real comparison happens: any pixel that differs between the two renderings shows up in red, so you can immediately spot what changed without reading both versions.
Page navigation lets you walk through the document one page at a time. If the two PDFs have different page counts, navigation stops at whichever is longer, and the missing page is shown as blank. Buttons jump to the first or last page; the page number input lets you go directly to any specific page. For long documents, the navigation is the bottleneck rather than the rendering, so the workflow is: load, jump to a page, compare, repeat.
History and background
The diff problem in computer science (1976)
Comparing two versions of a document is an old problem. The first practical solution was the diff utility written by Douglas McIlroy at Bell Labs in 1976. Diff compares two text files and prints the lines that differ, using the longest common subsequence algorithm. Eugene Myers improved the algorithm in 1986 with the O(ND) paper that became the basis for almost every modern diff tool, including git. Text diff is the foundation, but it only works on text, not on rendered documents.
Visual diff and pixel comparison (1990s)
The 1990s introduced visual diff tools that compared rendered output rather than source text. WinMerge (1998), BeyondCompare (Scooter Software, 1996) and Araxis Merge (1996) added image comparison alongside text. Pixel-by-pixel diff is conceptually simple (compare each pixel position, highlight mismatches), but it produces noise when comparing renders that look identical to humans but differ by anti-aliasing or font hinting. Refinements like perceptual diff and structural similarity (Wang et al. 2004) try to filter out perceptually-irrelevant differences.
Acrobat adds PDF compare (2015)
Adobe added a Compare Files feature to Acrobat Pro DC in 2015. Unlike pure visual diff, Acrobat's compare is text-aware: it identifies inserted, deleted and replaced text and presents the changes in a sidebar, similar to Word's track changes view. This works well on digital PDFs with proper text layers but degrades on scanned PDFs or PDFs with custom font encodings. Adobe's tool runs only on the desktop application; it is not available in the browser.
DiffPDF and command-line PDF diff tools (2010s)
Open-source command-line tools like DiffPDF (2010) and diff-pdf (a Wine-based wrapper, 2012) brought PDF comparison to scripted workflows. These tools compare either by text (extract both PDFs and run text diff) or by image (rasterize both PDFs and run image diff). They are useful in CI pipelines where you want to flag PDF regressions, but they require local installation and are awkward for non-developers.
Browser-based PDF rendering matures (2013)
Mozilla shipped pdf.js bundled with Firefox 19 in February 2013, making JavaScript-based PDF rendering production-ready. Chrome integrated PDFium (C++, Foxit-derived) in 2013-2014 to similar effect. Once browsers could render PDFs natively, building a browser-based PDF compare tool became feasible: load both files in JavaScript, render each page to a canvas, compare canvas pixel buffers. This tool follows that lineage.
Privacy-first cloud alternatives (2020 onwards)
The COVID-era surge in remote work pushed many PDF tools online. Most cloud PDF comparison services (Smallpdf, iLovePDF, PDF24) require uploading both files to a server for processing, which is unacceptable for confidential documents like contracts, medical records or financial statements. Browser-based tools that run client-side are a privacy-preserving alternative: the file never leaves your device, but you get the same compare experience as the cloud tools.
Practical workflows
Contract version review
A counterparty sends a redlined contract claiming only one clause changed. Load the original and the revised PDF, switch to overlay mode, and walk through the pages. The red highlights show every actual modification, not just the ones the counterparty pointed out. This catches snuck-in changes (a date shift, a number tweaked, a clause silently added) that text-only redlines might miss. Save screenshots of any unexpected red regions for follow-up.
Design and marketing collateral approval
A designer sends version 2 of a brochure claiming they addressed your feedback. Load version 1 and version 2, overlay each page, and verify the changes. The pixel diff catches typography tweaks, colour shifts, image swaps and layout adjustments that are easy to miss when reading two versions sequentially. For multi-page collateral this is much faster than printing both and laying them side by side.
Technical documentation regression check
When you publish technical documentation as PDF (user manuals, API references, internal SOPs), comparing the new version to the previous release catches unintended diffs. The pixel comparison is sensitive enough to catch a page-break shift or a renumbered section that text diff might present confusingly. For docs with hundreds of pages, scan through in side-by-side mode first, then overlay any page that looks different.
Tax form year-over-year comparison
Tax forms (IRS 1040, UK SA100, French 2042 etc.) change every year. Comparing this year's form to last year's identifies new line items, removed deductions, and renumbered sections. For accountants and tax preparers, this is faster than reading the form change notes from the tax authority. The overlay highlights every printed change immediately.
Academic paper revision tracking
When a paper goes through peer review, comparing the original submission to the revised version helps verify which reviewer comments were addressed. LaTeX-generated PDFs are usually clean enough that visual diff catches every text change. If figures or equations were updated, the pixel comparison highlights them clearly. Saves time over reading both versions in full.
Regulation and policy change tracking
Government regulations, corporate policies and standards documents (ISO, IEEE, IETF) are typically published as PDF. Comparing the new version to the previous one is the fastest way to identify substantive changes. Compliance teams use this to brief stakeholders on what changed without rereading the entire document. Side-by-side mode is good for context; overlay mode is good for spotting every micro-edit.
Common pitfalls
Different generators produce different renders
A document exported from Microsoft Word and the same document exported from Google Docs may render the same text with slightly different kerning, line wrapping, or font substitutions. Pixel diff flags these as differences, even though the document content is unchanged. If you are comparing the same source document exported from two different tools, expect a baseline of noise. Use Adobe's text-aware compare or run a text-diff after extraction to filter the noise.
Scanned PDFs at different resolutions look different everywhere
If one PDF is a scan at 300 DPI and the other is a scan at 600 DPI of the same physical document, the rendered pixels will not align. Every page will appear as a sea of red. Match the rendering resolution by re-scanning at the same DPI, or run OCR on both and compare the text instead of the visual rendering. Visual diff only works when both PDFs render to similar pixel grids.
Page rotation differences
If a page in one PDF is rotated 90 degrees relative to the same page in the other PDF, pixel comparison will flag the entire page as different. Check the page-rotation metadata of both PDFs before comparing. PDF readers will show both pages upright on screen, masking the underlying rotation. Use the PDF metadata tool to verify rotation, and rotate one PDF to match if needed.
Anti-aliasing produces sub-pixel differences
Even when comparing identical PDFs rendered twice, browser anti-aliasing can produce small pixel-value differences along glyph edges. The overlay may show a faint red halo around text. This is rendering noise, not a real change. If the noise is overwhelming the signal, consider a higher comparison threshold (treat pixels within 5 percent of each other as matching) or rasterize at higher resolution where each glyph occupies more pixels.
Layout shifts cascade red highlights
If you add a single paragraph near the top of a page, the rest of the page shifts down. Every line below the inserted paragraph now sits at a different y-coordinate, and pixel diff highlights all of them as different. The actual change was one paragraph but the visible diff is everything below it. This is the main reason text-aware diff (which understands paragraphs) often gives better results than pure pixel diff for content-heavy PDFs.
Visual diff misses invisible changes
PDFs can have invisible changes: metadata edits, embedded JavaScript, hidden form fields, watermarks set to zero opacity, attached files. Visual comparison will not catch any of those because they do not render to pixels. For comprehensive auditing, combine visual diff with the PDF metadata tool (which shows producer, creation date, title, custom dictionary entries) and the PDF unlock tool (which reveals encryption flags). Visual diff is necessary but not sufficient.
Privacy and data handling
Both PDFs you load into the tool stay on your device the entire time. pdf.js and pdf-lib are JavaScript libraries that execute in your browser; they do not make any network requests with the file contents. The files are read into memory, rendered to canvas elements, and the pixel comparison runs in JavaScript. We never upload either file, never log the contents, and never analyse what is in them. This matters because the documents you most want to compare (contracts, financial reports, legal correspondence, medical records) are exactly the ones you should never send to a third-party service.
Once the page is loaded, the tool works offline. You can disconnect from the internet, drop both PDFs, run the comparison, and review the overlay without your data ever touching another machine. The comparison result (the red-highlighted overlay) is a rendered image on the page; if you want to keep it, take a screenshot. Nothing is saved server-side and nothing is uploaded.
When not to use this tool
Pure text comparison (use diff-checker instead)
If your PDFs are text-only and you want a line-by-line diff with inserts and deletes called out, extract the text first (PDF-to-text) and run the result through a text diff tool. Text diff handles paragraph reflow, layout shifts and font changes naturally, none of which pixel diff handles well. The Absolutool diff-checker tool does exactly this for text. Pixel diff is best when layout and visual elements matter, not pure prose.
Comparing PDFs that should be byte-identical
If you need to verify that two PDFs are exactly the same file (build reproducibility, file-integrity check, fraud detection), use a hash comparison (SHA-256, MD5) rather than visual diff. A hash check is faster, deterministic and immune to rendering noise. The file-hash tool computes a SHA-256 hash in seconds; if the hashes match the files are identical, if they differ the files are not the same regardless of how they render.
Very large PDFs that exceed browser memory
Loading two 100 MB PDFs simultaneously, plus the rendered canvases for each page, consumes a lot of browser memory. On low-spec laptops and most mobile devices this can crash the tab. For very large PDFs (architectural drawings, multi-thousand-page manuals), split each PDF first with the PDF splitter tool and compare matching chunks. Or use a desktop tool like Adobe Acrobat Pro DC for memory-heavy comparison.
Comparing PDFs in different file formats
If one document is a PDF and the other is a Word file or HTML page, this tool cannot compare them. Convert both to PDF first (or both to text) so you are comparing like with like. Comparing across formats almost always produces enormous visual diffs because the renderers are completely different. Convert to a common format first; then compare.
More questions
Why does the overlay show red even though the PDFs look identical?
Pixel-perfect comparison catches sub-pixel rendering differences that humans cannot see. The two PDFs might have been generated by different tools (Word vs LaTeX vs InDesign) that hint fonts differently or anti-alias edges differently. The content is the same; the pixels are not. For these cases, prefer text-based diff after extracting text from both PDFs, or accept that the noise is real and look only at large red regions.
Can I compare scanned PDFs?
Yes, scanned PDFs work because the tool compares rendered pixels rather than text. The catch is that both scans must be at the same resolution and orientation, or the comparison will be useless noise. For scans of the same physical page, this tool catches differences like added handwriting, redaction marks or stamps. For scans of different pages at different DPIs, OCR both first and compare the text.
Does the tool know which PDF is older?
No, the tool treats both PDFs symmetrically. It shows you where they differ; it does not infer which is the original and which is the revision. You decide which file to put on which side. The labels Left and Right are purely positional. If you need temporal context (which one came first), check the file modification times in your file manager or the PDF metadata.
Can I export the comparison as a report?
Not directly: the comparison is rendered live in the browser. To capture it, take screenshots of the overlay pages and paste into a report document. For more sophisticated reporting (a PDF of differences with annotations), Adobe Acrobat Pro DC's Compare Files feature produces a printable report; this browser tool focuses on the live visual comparison only.
What if the two PDFs have different page counts?
The page navigation extends to the maximum page count of either PDF. When you reach a page that only one PDF has, the other side shows blank. This is the simplest behaviour and usually the most useful: if version 2 added two pages at the end, you see those pages as added content. If pages were inserted in the middle, every subsequent page will appear as different because they have shifted; that is the signal that an insertion happened.
Why pixel-based comparison instead of text-based?
Pixel comparison catches everything visual: text edits, layout shifts, image changes, font substitutions, colour tweaks, redactions. Text-based comparison only catches text changes and is blind to layout and images. For document review (contracts, reports, marketing) the visual changes often matter as much as the text. Pixel comparison is the safer default; for pure prose comparison, a text diff is more precise.