PDF Error: 'There Was a Problem Reading This Document' (Numbered Codes)

Error message: There was a problem reading this document (14)

Adobe’s numbered “problem reading this document” errors are internal codes that aren’t documented publicly. Adobe has never published a definitive table of what each number means, and third-party sites that claim to provide one are mostly guessing. What we do have is well-documented community evidence: certain codes appear in certain contexts often enough that the patterns are reliable, and most of these errors share a small set of working fixes. This guide covers the codes you’re likely to see, what causes them in practice, and the order in which to try the fixes.

The most useful thing to know up front: a single workaround — opening the file in Chrome and saving it back to PDF — resolves the majority of these errors in under a minute. Try that before anything else.

Quick fix

For any numbered “problem reading this document” error, in this order:

The Chrome wash. Open Google Chrome, drag the problem PDF onto it, then press Ctrl+P (Cmd+P on Mac). In the print dialog, change the destination to “Save as PDF” and save. Open the saved file in Acrobat — for codes 14, 109, 110, and 111 in particular, this resolves the error a high proportion of the time. The new file has clean structure because Chrome re-rendered it through its own PDF engine. You lose form fields, signatures, and bookmarks; you keep visible content. For files where those features matter, this isn’t the right fix — skip to step 3.
Update Acrobat. Help > Check for updates. Several of these errors trace to bugs in specific Acrobat builds that have been fixed in later releases. This is Adobe support’s standard first answer for any numbered error, and it’s not just a deflection — it does sometimes resolve them.
Structural rebuild with qpdf. For codes that indicate corruption rather than rendering issues (109, 110, 111 in particular), qpdf can rebuild the file’s structure while preserving form fields, annotations, and bookmarks:
```
qpdf --linearize input.pdf output.pdf
```
This works when the Chrome wash isn’t acceptable because of what it strips out.

If none of those work, the rest of this guide covers code-specific fixes and the underlying causes.

What each code typically means

Adobe doesn’t confirm these meanings, but the community pattern is consistent enough to be useful.

Error 14 — Page-rendering or save-after-edit issue. Usually appears when navigating between pages after inserting or deleting pages, or when trying to save a file that’s been modified. A long-standing community workaround is changing View > Page Display > Page Layout to “Continuous” and then doing Save As to a new filename — this preserves comments and edits and produces a clean output. The fix doesn’t address the underlying cause but it works reliably enough that it’s worth trying before anything else for code 14 specifically.

Error 109 — Corruption or structural problems, most often appearing on save. Strongly associated with files generated by CAD applications (Inventor, AutoCAD) and other engineering tools that produce technically-valid-but-non-standard PDFs. McAfee real-time scanning has been reported to interact badly with Acrobat saves and produce 109 errors; if McAfee is running, try saving with it temporarily paused. Renaming pages within the document (right-click thumbnail > edit page label) has resolved this for some users with no clear explanation — likely because it triggers a structural rewrite.

Error 110 — Content stream or font-embedding issue, typically appearing while scrolling pages. Heavily associated with PDFs produced by iText, PDFBox, and other library-generated PDFs where fonts weren’t properly embedded. Adobe staff have confirmed in community threads that 110 errors traced to specific files were caused by missing embedded fonts. The fix in those cases is for the file’s creator to re-export with all fonts embedded — which is not always possible if you’re not the original creator. As a recipient, the Chrome wash usually works because Chrome substitutes its own fonts during re-rendering. Installing the Adobe Acrobat Reader Font Pack sometimes resolves this without the wash.

Error 111 — Same family as 110. Appears in similar contexts and responds to the same fixes.

Error 135 — Almost always appears on save, particularly after stamping, commenting, or other editing operations. Despite some sources suggesting this is encryption-related, the consistent community evidence points to embedded special characters or structural quirks in the file that Acrobat tolerates on read but refuses to write back. The most reliably-reported workaround, posted by an Adobe community member and validated by many subsequent users: close the document without saving, then in Acrobat use Edit > Combine Files > Add Open Files (or right-click the file in Finder/Explorer and choose “Combine Files in Acrobat”). The combined output, even when it contains only the one file, can usually be saved without the 135 error. Comments and stamps are preserved. This isn’t an elegant fix, but it’s documented to work consistently.

If the Chrome wash isn’t an option

For documents where you need to preserve form fields, digital signatures, embedded attachments, or accessibility tags, the Chrome wash strips too much. The structural rebuild via qpdf is the better option:

qpdf --check input.pdf
qpdf --linearize input.pdf output.pdf

The --check step is informational — it tells you what qpdf finds wrong with the file. The --linearize step rebuilds the cross-reference table and produces a cleanly-structured output. For 109, 110, and 111 errors, this often resolves the underlying issue while preserving the file’s interactive features.

For 14 and 135 errors specifically, qpdf’s structural rebuild may not help because the underlying issue is in the content stream or save path rather than the structure. The code-specific workarounds above are more likely to work for those two.

If nothing works

Some files producing these errors are genuinely beyond economic recovery. In particular:

Files where the source application generated structurally-invalid PDFs that Acrobat can read but not write (some CAD exports, some legacy reporting tools) can be displayed and printed but never saved without errors. The pragmatic fix is to print to PDF (rather than save) — this generates a fresh file via the OS PDF printer, which sidesteps Acrobat’s save path entirely.
Files that have been through multiple “repair” attempts often accumulate damage rather than recovering. If you have an earlier version of the file (from email, version history, or backup), use that and discard the repaired one.
Files where the original creator can be contacted should be re-requested with a note that the export produced an invalid PDF. The original application can usually re-export cleanly.

Adobe’s official position on these errors, in support threads, is consistent: the error is in the PDF, not Acrobat. Whether or not that’s strictly true (some of these errors do trace to specific Acrobat versions), the practical implication is the same — the most reliable fix is to produce a fresh, clean copy of the file rather than to repair the broken one in place.

Why this happens

The numbered errors are Acrobat’s internal exception codes surfacing in user dialog text. When Acrobat’s PDF parser hits an unexpected condition, it raises an error with a numeric tag indicating where in the parsing or rendering pipeline the problem occurred. Different numbers correspond to different stages — page tree traversal, content stream interpretation, font lookup, save serialization, and so on. The same underlying file problem can produce different numbers depending on which operation triggered it (open vs scroll vs save), which is why the same file might show 110 when you scroll to page 3 and 135 when you try to save edits.

The codes’ opacity is a real frustration. Foxit and other PDF readers tend to either open these files or fail with more descriptive errors; Acrobat’s choice to surface a numeric code without an explanation pushes users toward generic repair attempts that may or may not help. The Chrome wash works for so many of these errors because Chrome’s PDF engine (originally PDFium, derived from Foxit) is more permissive about non-standard constructs than Acrobat’s stricter parser.

Preventing this in future

If you’re generating PDFs for distribution and seeing these errors reported by recipients, validate your output with qpdf --check and a current Acrobat install before shipping. Most PDF generation libraries have an “embed all fonts” option — turn it on. If you’re using iText, PDFBox, or similar tools server-side, run a small post-processing step that pipes output through qpdf — this often resolves the structural issues that produce 109, 110, and 111 errors at the recipient’s end.

For documents you receive that you’ll be working with extensively, do the Chrome wash up front before adding comments or signatures. It’s much less disruptive to clean the file before you’ve spent hours marking it up than to discover at save time that you can’t preserve your work.

If the error message shows the broader “file is damaged” wording rather than a numbered “problem reading” code, see the guide to that error. For PDFs that show 109 or 110 specifically after merging multiple files, the root cause is often in the merge process — see PDFs that are corrupted after merging. For 110 errors traced to font-embedding problems, the guide to PDF fonts displaying incorrectly covers font-specific diagnostics. The PDF repair pillar explains the structural model that makes sense of why these errors appear.

Last verified: April 2026