PDFCora

One PDF engine — PDFium — behind five SDKs that share an object model, an error type and a conformance suite.

Shared guarantees

• One engine thread per process runs every call; concurrent use is safe, and calls serialise.
• Errors are a closed, typed set. The core cases — password required, wrong password, corrupt, page out of range, closed, invalid operation, save failed — exist on every platform. Java has only these; iOS, Android and the web add a few more.
• Coordinates are PDF space (bottom-left origin); PdfViewTransform converts.
• Redaction removes content from the file rather than covering it, and reports what it removed.
• Signatures are read, verified and created (PAdES; a timestamp, for B-T, on iOS, Android and the web — Java signs B-B only). Integrity and trust are separate answers, and a signature reports whether it covers the whole file.

AI, separately

pdfcora-ai is an optional package. The core has no AI dependency and never gains one — a CI check fails the build if it does. On iOS, Android and the web (which Node uses unchanged) it ships answers, summaries, redaction and form proposals, alt text, remediation and diff, on top of the availability model and a custom-provider interface. Java has no AI package yet.

Three things worth knowing before you design around it. A feature reports availability per feature and re-checks on every call, because the user can turn the platform's AI off mid-session. Availability alone does not mean a model can be prompted — a device can report available with a prompt budget of zero — so the two are read together. And anything that would change a document returns proposals; nothing is written until your app applies the ones the user accepted.

Version 0.1.0 · built 2026-10-28 · 5c966af. Third-party licences: NOTICE.