← All posts

Opens in Chrome, refused by Acrobat

The file opens in Chrome. You can read it, scroll it, print it from the browser. Then you drag it into Acrobat and it says the document is damaged and could not be repaired. Or the upload portal rejects it, or the print shop emails back to say their software will not take it.

Nobody has set the wrong default app. You opened it in both programs deliberately, and they disagree about whether the file exists.

One of them has to be wrong, and the annoying answer is that neither is. The file really is broken, and the browser really is showing it to you.

Every reader does one thing before it draws a pixel

A PDF is not read from the front. The objects — pages, fonts, images, the catalogue that ties them together — are scattered through the file in no particular order, and at the very end there is an index: the cross-reference table, which lists every object by number against the byte offset where it starts. A reader jumps to the end, reads the index, and then seeks directly to the objects it needs.

That design is why a 2,000-page PDF opens instantly. It is also the single point of failure. If the offsets in the index no longer match where the objects actually are, the reader asks for byte 481,203 and gets the middle of a font.

At that point software has a choice, and this is the whole of your problem: it can give up, or it can ignore the index and find the objects itself. Every object in the file is labelled with its own number, in plain view, so a parser can scan the bytes from the start, note where each one really lives, and build a fresh index from what it found. That works remarkably often — it is the same redundancy a repair tool leans on, and it needs no help from you.

Programs sit at different points on that spectrum, and none of them tell you where:

How the offsets stop matching

Worth knowing which of these happened, because two of them will happen again tomorrow if you do not notice.

The file went through something that treated it as text. This is the classic. An FTP transfer in ASCII mode, a mail gateway, a script that read the file into a string — each one converts CRLF line endings to LF, or back. Every conversion shifts everything after it by a byte, so the index is correct at the start of the file and wrong by a growing amount from the first line ending onwards. A PDF is binary; nothing may touch its line endings.

Bytes were added in front of the header. A proxy that prepends an HTML error page, or a concatenation that put two files in one. Offsets are counted from the beginning of the file, so everything is out by a fixed amount. Most readers cope by finding %PDF- and adding its position; the fussy ones do not.

The download stopped. The index lives at the end, so an interrupted transfer produces a file with no index at all. A lenient viewer rebuilds one and shows you the pages that arrived, which is exactly why a truncated file can look fine until you scroll to the bottom.

A chain of saves broke. A file that has been filled in and saved a few times is usually a stack of appended revisions, each with its own index pointing back at the one before it. Break one link — an editor that rewrote part of the file, a sync client that merged two versions — and everything behind it is unreachable. Those stacked revisions are also most of what a repair leaves behind.

It was born like this. Some server-side generators calculate the offsets themselves and get them wrong, and some write a modern cross-reference stream while declaring an old PDF version, so older software looks for a table that is not there. Nothing damaged the file. It has simply only ever been opened in things that were forgiving.

The browser's repair is not saved anywhere

This is the part that makes the situation feel unreal. The reconstruction Chrome performs happens in memory, every time you open the file, and is thrown away when you close the tab. The bytes on disk are untouched. Nothing you do in the viewer writes a corrected index back.

So "it opens in Chrome" is not evidence about the file. It is evidence about Chrome. Every recipient running stricter software will see what Acrobat saw, and printing to PDF from the browser to "fix" it gives you a flattened photocopy: no text layer worth having, no bookmarks, no form fields.

What you actually want is one file that both programs agree on, written to disk once.

Rebuild it, then test it in the program that refused it

Repair PDF does the reconstruction on purpose and keeps the result. Nothing is patched and the old index is never consulted: the document is assembled again from the pages themselves, page by page, so one page that is genuinely beyond saving fails on its own rather than taking the file with it, and what comes back has a cross-reference table that matches its contents. Building a file that way also leaves behind everything the old one was carrying that nothing points at any more, which is why the copy is often a great deal smaller — a shrink with its own explanation.

  1. Upload the file that is misbehaving. There is nothing to configure.
  2. Read the notes, not just the download button. They say how many of the pages were rebuilt and name any that were left out, how many bookmarks were kept and how many of those now point at nothing, and what could not be carried across. A markedly smaller file is flagged there too, with the amount.
  3. Open the result in the program that rejected the original. Not in the browser. The browser was always going to open it, and it is the one opinion that carries no information.
  4. If not one page can be read, the job stops and tells you, rather than handing you an empty document dressed up as a result. That is a real answer: go back to whatever produced the PDF and export it again.

When it is not damage at all

Some disagreements between two programs have nothing to do with the index, and a rebuild will not touch them.

Our PDF inspector is the quickest way to eliminate most of that list. It reads the file in your browser without uploading it and reports the page count and page sizes, the version in the header and the version the catalogue claims, whether the file is encrypted, whether it is tagged, how many form fields it has and whether there is a real text layer. It will not tell you whether the cross-reference table is sound — for that, see the command below — but if it says the file is encrypted, or that the versions disagree, you have your answer without repairing anything.

If the strict program still refuses a rebuilt file, the problem is one specific page. Use Organize PDF pages to write out halves — 1-40, then 41-80 — and open each in the fussy program. Four rounds narrows two hundred pages to one, and that page is usually a corrupt image or an oddly generated vector object that no rebuild can heal.

The command line answers the question our tool cannot

One free tool belongs on your machine for this, and it is qpdf. It runs on Windows, macOS and Linux.

qpdf --check broken.pdf

That is the diagnosis nothing in a browser can give you. It says whether the file is linearised, whether the cross-reference table is sound, whether the index had to be reconstructed, and which objects are damaged — the exact fact that decides everything above.

qpdf broken.pdf fixed.pdf

That rewrites the structure and nothing else. Objects are copied as they stand rather than decoded and re-drawn, so it preserves things a page-by-page rebuild has to drop: XFA forms, embedded attachments, unusual annotations, exotic structures. On a file whose only problem is its index, this is the better tool, and it takes a second. Add --replace-input to write over the original in place.

If qpdf itself gives up, mutool clean -gggg in.pdf out.pdf from MuPDF is worth one attempt, and gs -sDEVICE=pdfwrite -o out.pdf in.pdf is the last resort — Ghostscript re-interprets the whole document, which recovers files nothing else will, at the price of re-encoding everything in it.

Then fix the pipe, not just the file

If the answer turns out to be a transfer that mangled line endings, or a generator writing bad offsets, the next file will arrive in the same state. Move PDFs in binary mode, never through anything that treats them as text, and if a system you rely on is producing them broken, run qpdf --check on one straight out of the machine. A file that fails that check on the day it was created was never damaged by anyone. It was only ever being opened by software kind enough not to mention it.

Tools this post uses: