Verify troubleshooting: when a signed PDF won't check out

What to do when Verify shows an error, a red banner, or less than a full green result.

"Not signed with AttachKit" or "No AttachKit proof block found"

Cause: the proof lives in the PDF's metadata, alongside the audit page added at signing time. If the file was never signed with AttachKit, there's nothing to find. If it was, the proof can be destroyed by re-processing: printing to PDF, compressing, flattening, merging, or re-saving in another editor often strips or rewrites metadata.

1. Ask the sender for the exact file that was downloaded from AttachKit after signing — not a copy that went through another tool.
2. If you signed it yourself, sign and download again, then verify the fresh download before sharing it.
3. Going forward, share the signed file as-is; any "optimize" or "reduce size" step can remove the proof.

"Couldn't open the PDF. If it's password-protected, decrypt it first."

Cause: the verifier can't parse an encrypted file.

1. Open Unlock and remove the password (this happens in your browser too).
2. Drop the decrypted copy into Verify.
3. Note: if the password was added after signing, the file has by definition been modified since signing, so the content-binding check can fail even after unlocking. The who-signed-and-when checks may still verify; for full confidence, ask for the original unencrypted signed file.

"No hardware-key proof"

Cause: the PDF was signed with the regular browser flow. Its audit page records when and where each signature was placed, but no passkey (WebAuthn) assertion is bound to it — so there is nothing cryptographic for the verifier to check.

1. This isn't a failure; it just means the document carries a plain signature, not a verifiable proof.
2. If you need a verifiable result, ask the signer to use the hardware-key (passkey) flow in Sign — a Max feature (during the private beta, everything is free).

"Invalid — this didn't verify" or "Content was modified after signing"

Cause: the signature or content hash doesn't match the file you dropped. Either the file was changed after signing — even an innocent re-save counts — or the proof was lifted from a different document. The row shows the recomputed and expected hashes so an auditor can confirm the mismatch.

1. Ask the sender for the original signed file and verify that instead.
2. If you have both an original and a suspect copy, run them through Compare to see exactly what differs.
3. Treat a red result on the only copy you have as unverified: AttachKit can't tell you what changed, only that the bytes no longer match what was signed.

"Signed, but not fully confirmed"

Cause: a proof block is present, but no cryptographic check could complete — every check was skipped rather than passed or failed. In practice the proof carries nothing verifiable: no passkey signature at all (see "No hardware-key proof" above), or only a timestamp with no signature behind it. The timestamp re-check — the only step that needs a network round-trip — is also skipped when rate-limited, but if the passkey signature itself verified, the verdict stays green despite the skipped timestamp.

1. Read the individual rows — each one says whether it was valid, invalid, or skipped, and why.
2. If the page shows No hardware-key proof, the file carries a plain signature, not a verifiable one — see that section above.
3. A dropped connection during the timestamp re-check surfaces as Timestamp signature: invalid (network_error) and turns the verdict red, not amber — check your connection, click Verify another PDF, and drop the file again.
4. For a time claim that needs no AttachKit server at all, use the RFC 3161 row's openssl ts -verify recipe (the standalone offline verifier confirms content integrity offline, but doesn't re-check timestamps).

A badge link with ?u= won't load the PDF

Cause: /verify?u=<url> fetches the remote PDF from your browser, so the hosting server must allow cross-origin requests. Only http(s) URLs are accepted, remote files are capped at 50 MB, and slow hosts time out after about 15 seconds. Typical messages: "Couldn't fetch the PDF (403). The host may not allow cross-origin requests." and "That PDF is over 50 MB — too large to fetch here."

1. Download the PDF from its source yourself.
2. Open Verify and drop the downloaded file in manually — manual drops allow up to 100 MB.
3. If you publish the badge, host the PDF somewhere that sends CORS headers, or link to the PDF and let visitors drop it themselves.

The file is over 100 MB

Cause: drops are capped at 100 MB so a huge file can't freeze the tab.

1. Don't split, compress, or re-save the file to shrink it — verification needs the exact signed bytes, and any modification will (correctly) fail the content check.
2. Signed documents this large are rare; if you genuinely have one, contact support and we'll help.

Still stuck?

Tell us what the verdict banner said and which row failed — contact support.