PDF

Mac Preview Error: 'It May Be Damaged or Use a Format Preview Doesn't Recognize'

Error message: The file '[filename].pdf' could not be opened. It may be damaged or use a file format that Preview doesn't recognize.

When Preview reports "could not be opened. It may be damaged or use a file format that Preview doesn't recognize," the file isn’t necessarily damaged — the wording is broader than it looks. Preview uses macOS’s PDFKit, which handles the vast majority of PDFs but has specific limitations around certain encryption variants, newer PDF features, and edge-case constructs. A file that’s perfectly fine in Acrobat or Chrome can produce this error in Preview. The first job is to figure out whether the problem is the file or Preview itself.

Quick fix

  1. Test the file in another reader to localize the problem. Drag the PDF into Chrome, Safari, or Firefox. If any of them displays it, the file is fine and Preview is the issue — skip to step 2. If all readers fail, the file has real damage — skip to the recovery section below. If you have Adobe Acrobat Reader installed, that’s the most authoritative test; download the free Reader from adobe.com/acrobat/pdf-reader.html if you don’t.
  2. If the issue is Preview-specific, clear its cache. Open Terminal (Applications > Utilities > Terminal) and run:
    rm -rf ~/Library/Containers/com.apple.Preview/Data/Library/Caches/
    Then quit Preview entirely (Cmd+Q) and reopen the PDF. This clears Preview’s cached previews and document state without affecting your other settings. It resolves the persistent “this file works in Chrome but not Preview” symptom in many cases.
  3. Check file permissions. Right-click the PDF in Finder and choose Get Info. Under “Sharing & Permissions” at the bottom, your user account should have “Read & Write” or at minimum “Read only” access. If it shows “No Access,” click the lock icon, authenticate, and add yourself with read access. This is a common issue with files from external drives, files restored from backup, or files copied from another user’s account.

If those three steps don’t resolve it, work through the diagnostic below.

If that didn’t work

Reset Preview’s preferences. This is more aggressive than clearing the cache — it resets all Preview settings to defaults, clearing window arrangements, recent files, and any view preferences you’ve configured. The file association for PDF defaults will be preserved.

defaults delete com.apple.Preview

Run this with Preview closed, then relaunch Preview and try the file. If preference corruption was the cause, this resolves it. If Preview was already at defaults, this command runs without doing anything visible — no harm done.

For files where Preview specifically fails but other readers succeed, the file is using a PDF feature that PDFKit doesn’t support cleanly. The most common cases:

AES-256 encryption with specific variants. Preview supports most encrypted PDFs but has historical issues with certain non-standard AES-256 implementations. If you can open the file in Acrobat, you can re-save it from Acrobat to a more standard encryption (or no encryption) and Preview will then handle it.

PDF 2.0 features. Preview has improved its PDF 2.0 support over time but still rejects some files using newer specification features. Re-saving the file as PDF 1.7 (the previous standard) usually resolves this. In Acrobat: File > Save As Other > Optimized PDF, then in the Compatibility setting choose “Acrobat 8.0 and later” (PDF 1.7).

Certain XObject types. Some PDFs use embedded objects that Preview’s parser doesn’t handle. The qpdf re-write below normalizes most of these.

A general-purpose Preview-compatibility fix: re-save the file with qpdf to produce a clean, standard structure:

qpdf --linearize --object-streams=disable input.pdf output.pdf

The --object-streams=disable flag is specifically helpful here — Preview’s parser handles files without object streams more reliably than files that use the more compact (and more recent) object-stream format.

Advanced recovery

If all readers reject the file, including Acrobat, the damage is real and the standard PDF repair process applies. See the guide to PDFs that won’t open for the full diagnostic sequence, or the guide to “file is damaged and cannot be repaired” if Acrobat shows that specific error.

A useful Mac-specific note: macOS sandboxes Preview, which means Preview reads files differently from how Terminal or other applications might. If a file is in an unusual location — an iCloud Drive folder that hasn’t fully synced, a network share with permission quirks, an external drive with macOS quarantine attributes — Preview may report the file as unopenable even when the file itself is fine. Copy the file to your Desktop and try again before assuming the file is damaged. Quarantine attributes from downloaded files can be cleared with:

xattr -d com.apple.quarantine /path/to/file.pdf

This is occasionally the difference between Preview rejecting a file and accepting it.

Why this happens

Preview’s PDF rendering uses Apple’s PDFKit framework, which is generally excellent but is not Adobe’s reference implementation. The two parsers make different choices about what to accept. Acrobat tends to be more permissive on file structure (it auto-repairs many problems silently) and stricter on certain rendering details. Preview tends to be stricter on file structure but more tolerant of unusual content streams. This means there’s no consistent ranking of “Preview is more capable” or “Acrobat is more capable” — they fail in different ways on different files.

The specific Preview error wording — “may be damaged OR use a file format that Preview doesn’t recognize” — is honest about this uncertainty. Apple’s developers know Preview has compatibility limitations and chose error text that doesn’t claim more than they can verify. Most other PDF readers don’t have a “I don’t support this” failure mode separate from “this is damaged”; Preview at least admits the distinction.

The sandboxing layer adds its own failure modes. macOS treats Preview as a sandboxed application that can only access files the user explicitly grants it access to. This usually works seamlessly through the standard file-open mechanisms, but files in unusual storage locations, files with non-standard permissions, or files inherited from other macOS user accounts can hit access restrictions that produce the same error wording as actual file damage.

Preventing this in future

If you work primarily on Mac and need reliable PDF handling, install Adobe Acrobat Reader (free) as a backup for Preview-incompatible files. Set Preview as your default PDF reader (it’s faster and more lightweight) but keep Reader available for the cases where Preview fails. Right-click any PDF, choose “Open With,” and Reader will be in the list once installed.

For files you create or convert on Mac, prefer applications that produce broadly compatible output. Pages, Word, and most PDF creators on macOS produce files that Preview handles reliably. Some legacy and specialized tools — particularly older CAD applications, niche scientific publishing software, and some library-generated PDFs — produce files that pass Acrobat but fail in Preview. If you’re publishing a PDF that recipients on Mac will need to read, test it in Preview before distribution.

For documents from external drives or USB sticks, copy them to local storage before opening. The combination of file system differences, quarantine attributes, and sandboxing can produce intermittent Preview failures that go away once the file is on the local disk.

If the file fails in every reader you try, not just Preview, the underlying problem is structural damage and the general guide to PDFs that won’t open covers the full diagnostic. For Adobe Reader’s similar but distinct error, see the guide to “file is damaged and cannot be repaired”. For PDFs that work on desktop readers but fail on mobile (a related reader-compatibility class of issue), see PDFs that won’t open on mobile. The PDF repair pillar covers the underlying file structure that determines whether a given reader can handle a given file.

Last verified: April 2026