The surveillance problem
A prescribing information document runs to dozens of pages of dense text, tables and boxed warnings. Revisions are published as complete new PDFs, not as a list of edits. A pharmacovigilance or regulatory team has to know which warnings, doses, contraindications and interactions changed, and it has to be certain it did not miss one.
The obvious approach is to read both versions. That works for the first few labels. It stops working when a team follows dozens of products, each revised several times a year, and when the change that matters is a single number in a dosing table on page 31. People reading at speed catch rewritten paragraphs. They miss "40 mg" becoming "20 mg" in a renal impairment row.
A hypothetical revision
Picture a 38-page label where the manufacturer has made three changes. A new sentence is added to the Warnings and Precautions section about hepatotoxicity monitoring. One row of the dose adjustment table changes a maximum daily dose. A drug interaction is moved from one subsection to another, with no change to its wording.
A page-by-page comparison of those two PDFs reports changes on almost every page after section 5, because the new sentence pushes all later text down. The table may light up in full if the extractor read its cells in a different order. The moved interaction shows up as one deletion and one insertion, several pages apart, and a reviewer has to work out that they are the same text.
What the reviewer actually needs is three entries: one insertion in section 5 with its page number, one replaced value in the table, and one moved paragraph. That is the output the engine behind this site was built to produce.
What the engine had to get right
- Reflow. A sentence added to section 5 must not be reported as changes on every later page. Content is aligned by paragraph, not by page.
- Tables. Dosing and adverse reaction tables that are unchanged must not light up because the extractor read the cells in a different order. Unchanged tables are recognised and held out of the diff, so only changed cells are reported.
- Running headers and footers. Reference IDs and revision dates repeat on every page and must be reported once, not per page.
- Two-column layouts. Highlights sections are laid out in columns and must be read in the right order.
- Moves. Text that moved without being rewritten is reported as a move.
- Determinism. The same two documents must always produce the same result, because the result becomes part of a regulated record.
Mistakes that cost teams time
The most common one is comparing against the wrong baseline. The previous version on file is not always the previous version published, especially when a safety labelling change and an unrelated update landed close together. Before comparing, confirm that the older PDF is the revision the team last reviewed and signed off.
The second is relying on the revision summary at the top of the label. Recent major changes are listed, and that list is useful, but it covers the sections the manufacturer considers major. Editorial changes, table corrections and changes in other sections are not always flagged there. The change list from a comparison is the complete record; the summary is a cross-check.
The third is reviewing a scan. If the only copy of an older label is a scanned image, the engine refuses it, because there is no text to compare. An OCR text layer fixes that, and formatting differences are then ranked low so OCR noise does not bury real changes. See comparing scanned PDF documents for what to expect from OCR copies.
When an unexpected change turns up
Sometimes the change list contains something nobody was expecting: a contraindication reworded, a frequency category in the adverse reactions table changed from "common" to "very common". Treat it the same way as an expected change. Record it with its page number in both versions, route it to the person who assesses impact on your own materials, and keep the redlined PDF with the assessment. The redline shows exactly what was reviewed, which is easier to defend later than a note saying "label checked, no impact".
From labels to everything else
The same engine now runs behind the comparison tool on this site and its API. Pharma teams use it for the label problem it was built for, and for the documents around it: SOP revisions that QA has to approve, protocol amendments, CMC documents and regulatory submissions that must match the internally approved version before filing.
For a team that tracks many products, the REST API is the practical route. Each time a new label PDF is retrieved, send it with the previous version and store the JSON change list next to the document. Labels with an empty change list need no reading at all.
Validation and deployment
Because the diff is rules-based rather than model-based, it is reproducible and can be validated: run the same pair twice and you get the same change list. Enterprise deployments run pinned versions inside the customer's own infrastructure, which supports IQ/OQ documentation and keeps documents off shared servers. The pharma industry page covers the deployment options in more detail.
Try it on your own documents. Upload two versions on the homepage. Documents up to 30 pages need no account, and nothing is stored.
Industry page: PDF comparison for pharma and life sciences