Scan troubleshooting: password-protected PDFs, false alarms, and what a clean verdict really means

Solutions for the most common problems when scanning a PDF for fakes at /scan. All analysis runs in your browser — the file is never uploaded — which also shapes what Scan can and can't do for you.

"PDF is password-protected — metadata can't be read"

You'll see this either as an error before any report renders ("This PDF is password-protected. Remove the password … and try again — scan runs entirely in your browser, AttachKit can't unlock it for you") or as a report containing this single warning signal with an automatic Suspicious — worth a closer look verdict.

Cause: the document has PDF encryption enabled. Its Producer, Creator, and date fields live inside an encrypted stream, and Scan runs in your browser without the password, so it can't read them. Rather than analyze unreadable bytes, Scan stops and tells you.

Fix:

1. If you know the password, open Unlock, enter it, and download the decrypted copy — that also happens entirely in your browser.
2. Alternatively, open the file in any PDF viewer (Preview, Adobe Reader, Chrome), enter the password, and use File → Save As to write a copy without a password.
3. Re-scan the unprotected copy.
4. If you don't have the password, AttachKit can't remove it for you — ask the sender for an unprotected copy.

"Couldn't read this PDF — it may be corrupted or in an unsupported format"

Cause: the bytes don't parse as a PDF at all. Typical culprits: a truncated download, an image or Word file renamed to .pdf, or a malformed file from a buggy generator.

Fix:

1. Check whether the file opens in another PDF viewer. If it opens nowhere, the file itself is broken.
2. Re-download or re-export the file from its source and try again.
3. If it opens fine elsewhere but Scan still refuses it, contact support — that's a parsing case we want to know about.

A legitimate document comes back "Suspicious — worth a closer look"

Cause: the suspicious verdict means at least one warning-level signal fired. It's a prompt for closer inspection, not a conviction. The most common honest triggers:

• The file was run through an online PDF tool (iLovePDF, Smallpdf, PDF24, Sejda and similar). Those services re-render the document, so the producer fingerprint changes and original layout or signatures may have been altered — which is exactly what the warning says.
• The producer string is missing because a privacy tool or a minimal generator scrubbed the metadata.
• The creation date is missing, or the modification date is more than a year after creation, on a file whose producer Scan doesn't recognize. For known authoring tools these are demoted to informational — old re-saved templates such as IRS forms are normal.

Fix:

1. Read the individual signal rows, not just the banner — each row states why it fired and shows the raw value it saw.
2. Weigh the signals against what you know about the file's history. A bank statement that went through an online compressor will legitimately show the re-processing warning.
3. If the document matters, ask the source for the original export straight from the issuing tool, and scan that instead.

A file you doubt comes back "No automated red flags"

Cause: a clean verdict means none of the heuristics fired. It does not prove the document is authentic — every field Scan reads can be spoofed by re-saving the file through Adobe Acrobat, and a careful forger will produce clean metadata.

Fix:

1. Treat the scan as one input to a human judgment call, not the final word.
2. Cross-check the document's contents directly with the issuer (employer, bank, landlord).
3. For documents you'll rely on, ask the source to sign with Sign; then Verify gives you a cryptographic answer instead of a heuristic one.

The file won't drop — it's over 100 MB

Cause: the drop zone caps files at 100 MB to keep your browser responsive.

Fix:

1. Open Pages and extract the pages you care about into a smaller file.
2. Scan the extract — but read the metadata rows with care: extracting pages re-saves the file, so the producer and date signals now describe the re-saved copy (AttachKit's own pdf-lib producer string), not the original document. The structure and image signals still apply.
3. If you genuinely need the original metadata of an over-100 MB file judged, contact support.

Scan ignored the images in my PDF

Cause: image analysis covers embedded JPEG images only, and analyzes the first 6 it finds. Images stored as PNG or JPEG 2000 inside the PDF are skipped, and pages that are pure vector art or text have no images to extract.

Fix:

1. Check the "embedded JPEG images" row in the report — it shows how many JPEGs were found, and notes when only the first 6 were analyzed.
2. If that row is missing entirely, Scan found no JPEG images to analyze. Either way, that doesn't move the verdict; the metadata and structure signals still apply.
3. If an image is the whole question (a suspected doctored photo), remember the statistical tells are deliberately conservative — the absence of an image signal is not a clean bill for the picture.

Still stuck?

Tell us the verdict you got and which signal row looks wrong — contact support.