"There was a problem reading this document (14)" in Preview

Preview opens a PDF and stops: There was a problem reading this document (14). Other numbers appear too, and the parenthesised figure is more useful than it looks, because it distinguishes a damaged file from one Preview simply will not handle.

What the numbers tend to mean

Apple does not publish these codes, but their behaviour is consistent enough to work with:

• (14) generally indicates a structural problem: the cross-reference table that tells a reader where each object lives is damaged or missing. This is the classic truncated-download or interrupted-copy failure.
• (18) usually points at encryption or permissions the reader cannot satisfy.
• (21) and similar higher numbers tend to indicate an unsupported feature rather than damage, often an unusual form or an embedded element Preview does not implement.

For (14), the file is damaged or incomplete, and the question becomes how much survives.

Check the structure

A PDF has a defined shape. It starts with a version header and ends with a pointer to the cross-reference table. Both are checkable:

head -c 16 broken.pdf | xxd | head -2
tail -c 64 broken.pdf | strings

The first should show %PDF-1. followed by a version digit. The second should contain startxref and %%EOF. A file missing %%EOF at the end was truncated, which is exactly the (14) case, and it tells you the download or copy did not finish rather than that the document is bad.

Compare the size against what you expected. A file that stopped at a suspiciously round number, or that is markedly smaller than a sibling from the same source, was cut short.

Try a different reader first

Preview is stricter than most PDF readers. Before treating the file as damaged, open it in something else. A browser is the quickest test:

open -a Safari broken.pdf

Browsers have their own PDF engines and are notably tolerant of malformed structure. If the document renders there, it is readable, and you can print it to a new PDF from the browser to get a clean copy:

File, then Print, then the PDF menu, then Save as PDF. The result is a rebuilt file with a valid structure, which Preview will then open.

That single step resolves a great many of these, and it costs nothing to try.

Rebuilding the cross-reference table

If no reader will open it, the cross-reference table needs rebuilding from the objects that remain in the file. That is a matter of scanning for object markers and constructing a new index describing where they are.

The outcome depends on where the damage is. A PDF with a broken index but intact objects usually recovers completely, because the content was never lost, only the map to it. A PDF truncated partway through recovers the pages that arrived and not the ones that did not.

Manatee does this for PDFs, working from a duplicate so the damaged original is untouched, and reports the outcome in pages rather than claiming a success it cannot deliver. A result of thirty-four pages out of forty-one means exactly that: thirty-four readable pages, and seven that were not in the file to recover. What “34 of 41 pages” really means explains why partial results happen and why they are usually the honest answer. Repairing a corrupted PDF covers the process in more detail.

If it is encrypted rather than damaged

An error in the (18) range, or a file that prompts for a password you do not have, is a different situation entirely. A PDF can be encrypted for opening, or restricted for printing and copying while still opening freely.

strings broken.pdf | grep -i "/Encrypt" | head -3

A match means the document is encrypted. No amount of repair will help; the file is intact and deliberately locked. Go back to whoever produced it. Tools that claim to strip PDF passwords are, at best, working only on the weaker permissions layer, and using them on a document you are not entitled to open is not something to do casually.

Preventing the truncated download

Since (14) is so often an incomplete transfer, the fix for next time is worth stating.

Re-download rather than repairing, if you can. A fresh copy takes seconds and gives you a genuinely complete file rather than a reconstruction.

For large documents over an unreliable connection, curl resumes where the browser starts over:

curl -C - -O "https://example.com/large-document.pdf"

-C - continues an interrupted download. Then confirm you got everything before trusting it:

tail -c 64 large-document.pdf | strings | grep "%%EOF"

A match means the file reached its end marker.

Questions

The PDF opens on my phone but not on my Mac. Different rendering engines with different tolerances. If it opens anywhere, print it to a new PDF from there to get a clean copy.

Preview opens it but pages are blank. The structure is valid and some content streams are damaged, or the pages use a feature Preview does not render. Try a browser; if the pages appear there, print to PDF from the browser.

Can I recover text from a PDF that will not open at all? Often, yes. Text is stored in content streams that may survive even when the index does not:

strings broken.pdf | head -100

That is crude and produces a mess of markup alongside real text, and it sometimes retrieves the paragraph you needed.

The file was fine yesterday. Then something changed it: an interrupted sync, a failing drive, or a copy that did not complete. Check whether an earlier version exists in Time Machine or in the file’s Versions history before attempting any repair.