IntactFile

Inspect a PDF file — is it intact, truncated, or encrypted?

Before you decide a PDF is beyond saving, see what's actually wrong with it: the header, the end-of-file marker, the startxref pointer and the cross-reference table — checked locally, in your browser.

Your file never leaves your device — inspection runs in your browser. 0 bytes uploaded.

Drop a PDF file hereTap to choose a PDF file

Reads the %PDF- header, the trailer, the startxref pointer and the cross-reference table.

100% in your browser. 0 bytes uploaded — open DevTools → Network and watch. Your file is read, never sent.

In short

This is a read-only inspector for PDF documents. Drop a file and it scans the structure locally — the %PDF- header at the top, and the trailer, startxref pointer and%%EOF marker at the bottom — then spot-checks that the cross-reference table actually leads to real objects. It reports whether the document is intact, truncated, has a broken xref, carries a garbage prefix, or is encrypted. Nothing is uploaded and nothing is rewritten.

What the inspector reads

A PDF is bookended by two things a reader depends on. At the top, the %PDF- header declares the version; anything before it is a garbage prefix that confuses parsers. At the bottom sits the trailer, the startxref pointer, and the %%EOF marker — and startxref points at the cross-reference table, the index that lets a reader find every object without scanning the whole file.

The inspector reads the header window, then scans the tail for those end markers, then follows startxref and sanity-checks that the first live entry really lands on an object. Its report is a compact set of structural facts: the detected version, whether each key marker is present, whether the xref is readable, and whether an /Encryptentry means the document is password-protected rather than broken. Each finding is stated in plain words so you know exactly what failed.

Reading the verdict

Valid or encrypted

If the header, tail markers and xref all check out, the document is structurally sound. If it reports as encrypted, the structure is equally sound — it simply needs its password. Either way the bytes are fine.

Truncated or broken xref

A missing %%EOF points to a file cut short; astartxref that leads nowhere points to a damaged index. When the objects before the damage survived, this is what structural repair rebuilds around — the repair tools pick up from here.

Why "no upload" is verifiable, not a slogan

The document is read with the browser's own file APIs and diagnosed on your machine; the page makes no request that carries your data. Don't take it on faith — open DevTools, select the Network tab, drop the file, and watch nothing leave. It's the same principle as thezero-upload proof page, applied to inspection.

FAQ

Why won't my PDF open?

Usually one of a few structural reasons: the file was truncated so the %%EOF marker and cross-reference table at the end are missing; the xref table is present but damaged; a garbage prefix sits before the %PDF- header; or the document is encrypted and needs a password. The inspector checks each of these and tells you which one applies.

Does the file get uploaded?

No. The PDF is read in your browser and diagnosed there — 0 bytes are sent anywhere. Open DevTools, switch to the Network tab, drop the file, and confirm that nothing carries it.

What is the cross-reference (xref) table?

It's the index a PDF reader uses to jump directly to each object in the file, and its location is recorded by the startxref pointer near the end. If the tail of the file was cut off or the xref is corrupt, readers can't find their way around and refuse the document even though most of its content is still present.

It says the PDF is encrypted — is that damage?

No. Encryption means the structure is intact but the content is locked behind a password (an /Encrypt entry in the trailer). The inspector reports it separately from damage so you know the file is fine and simply needs its password to open.

The report says it's damaged — what now?

Inspection only reports; it doesn't change the file. If the damage is a missing tail or a broken xref, that structure can often be rebuilt around the surviving objects — the repair flow starts from this same diagnosis. If the content bytes themselves are gone, no tool can invent them back, and the inspector says so.

Other inspectors: ZIP ·PNG · or, if the file is damaged,all repair tools