Upload the original PDF and the edited version to the PDF Layout Validator. It compares the two documents at both the object level (text, fonts, images, lines, tables, form fields, annotations and page geometry) and the visual level (both pages rendered and compared), then reports every difference it detected with a severity and the exact values that changed.

A pixel comparison only tells you that something looks different, and it reports harmless rendering noise as a change. This validator reads the actual PDF objects and content streams as well, so it can tell you what changed — a font size, a moved paragraph, a flattened form — and can distinguish an intended edit from layout damage and from an invisible internal rewrite.

Differences that every PDF writer produces on save — a new producer string, a bumped PDF version, renumbered internal objects — are reported as informational and labelled harmless, and they do not reduce the layout integrity score. They are shown rather than hidden so you can see why the file’s bytes changed.

It is a 0–100 summary of the differences the validator detected, where every point deducted traces back to a listed finding. Critical findings such as a removed page or a changed page size weigh heavily, minor ones such as a small shift weigh little, and repeated instances of the same problem are damped because they usually share one cause.

Yes, and this is one of the most important checks it performs. When a page that previously contained text objects arrives as a full-page image with no text left, the validator reports that the page was converted to an image. The page can still look identical while the text has become unselectable, unsearchable and uneditable, so a visual comparison alone would not catch it.

Yes. It compares the font family, size, weight and style behind every matched piece of text, and the document-level font inventory. It also reports when the updated file has fallen back to a substitute typeface, which usually means the original font is missing or no longer embedded — a common cause of shifted spacing and line breaks.

Yes. The validator reads the AcroForm field tree of both files. When every interactive field is gone it reports the form as flattened rather than listing each field separately, and it separately reports fields that moved, changed type, changed value or changed editability. Signature fields that disappeared are always reported as critical.

It means an area of the page renders differently but the document’s object list does not account for it. Shading, transparency, clipping paths and colour conversions can cause this. These findings are reported at medium confidence and are worded as visual differences, because the validator has not verified a specific cause.

Yes. The comparison accepts approved edit regions. Differences that fall entirely inside one are marked as expected and stop counting against the document, while anything that spills outside the region is still reported. Expected findings are marked, never hidden, so you can still confirm that your intended edit actually happened.

They set how much movement counts as a difference. Balanced ignores sub-point drift that comes from re-saving a file and suits most documents. Strict reports movements as small as a quarter of a point and is intended for print and prepress work. Lenient only reports movements larger than three points and ignores colour changes.

Structural comparison covers every matched page. Rendering is the expensive step, so the number of pages compared visually is capped — and the report always states how many pages were rendered out of how many were matched, rather than presenting a sampled run as a complete one.

Yes. Pages are matched by content before anything is compared, so an inserted or deleted page is reported as exactly that instead of making every following page look changed. Pages that exist in only one of the two files are reported as added or removed.

No. A clean result means this validator detected no unexpected layout differences between the two files you supplied. It is not a guarantee of correctness, and it cannot know what you intended to change — always review the findings against the edit you meant to make.

No. Both files are processed for the comparison and then removed — they are not kept, shared, indexed or used for training. Neither document is modified: the validator has no write path at all. Only structural counts such as page and finding totals are logged, never document text.

Word reflows content to fit the target printer or PDF driver, so page breaks, spacing and images can move during export. Fonts that were not embedded get substituted, which changes character widths and pushes everything after them. Comparing the export against a reference PDF shows exactly what moved.

Print adds a second rendering path with its own font handling, colour conversion and page scaling. Non-embedded fonts get substituted by the printer, RGB colours are converted to CMYK, and "fit to printable area" quietly rescales every page. None of these change the file — they change what comes out of it.

Text shifting in tables on export is a documented behaviour rather than a mystery, and the usual workarounds are enabling tagged export or converting the affected text to outlines. Compare the export against a known-good version to confirm which of the two fixed it.

It can. A PDF has no layout engine — it is independent objects at fixed coordinates — so an editor that reflows a text box may split it, move it or push neighbouring content. That is precisely the case approved edit regions exist for: mark what you meant to change and everything outside it is still checked.

Usually a plot-style table, a shade-plot setting or a lineweight configuration rather than the PDF itself, which is why the same file can print correctly in one viewer and not another. Compare the plot against the reference and the missing geometry is listed rather than hunted for by eye.

It can. Lossy image recompression, downsampling and font subsetting all alter the file, and the result is usually indistinguishable — but not always. Comparing the compressed copy against the original is a few seconds well spent before the compressed one is the version you send.

Yes. Adding a text layer can misalign it against the image, break words apart, or in reported cases drop content. On anything legal or archival that is worth verifying rather than assuming, since the visible page often looks untouched.

Structural comparison inspects the internal objects — text runs, fonts, images, positions, page boxes — and explains why something changed. Visual comparison renders both pages and shows what changed. Each misses what the other catches, which is why this validator runs both and reconciles them.

Because a save rewrites the file. Object numbering, compression, producer strings and the PDF version can all change while every drawing instruction stays the same. Incremental updates go further and append revisions, so earlier content persists inside a file that renders identically.

Not in any absolute sense. Rendered pixels depend on the engine doing the rendering, and PDFium, Ghostscript, Poppler, MuPDF and Adobe disagree in places. A pixel comparison is only meaningful relative to one fixed renderer, which is why "pixel-perfect" is a claim worth distrusting.

No, and tools that claim otherwise are overselling. Automated comparison catches a broad range of text, object and visual differences, but some semantic problems still need a person — and even professional validators disagree with each other on a large share of real files.

Those answer conformance questions — is this production-ready for press, will it survive as an archive. This answers an integrity question: did anything change between these two versions. They stack rather than compete, so a print job may reasonably want both.

Not here — this validator needs two files, because "did the layout change" only has meaning relative to a reference. If you want to inspect one file in isolation, the font checker, accessibility checker and object explorer each examine a single document.