PDF Operations
One capability route for private PDF preflight, extraction, mutation, and automation.
pdf-inspector, PDFCraft, and Stirling-PDF are retained because they solve different stages and deployment shapes; none replaces the existing extraction stack.
Routing Summary
| Job | First route | Why |
|---|---|---|
| Decide whether a PDF or individual page needs OCR | pdf-inspector | Fast local classification with confidence, page-level OCR routes, and explicit reasons for scanned, vector-text, missing-text, or suspected-garbled content |
| Read, search, or extract a born-digital PDF | preflight when uncertain, then LiteParse | Avoid all-or-nothing OCR, then use fast local text/layout extraction and page screenshots |
| Extract broad ordinary documents | MarkItDown - Universal File-to-Markdown Converter | Lightweight multi-format conversion |
| Hard OCR, tables, formulas, or reading order | MinerU | Heavier layout/OCR specialization |
| Merge, split, compress, reorder, secure, or visually chain operations on one machine | PDFCraft | Client-side WebAssembly; files stay in the browser; offline/static deployment; visual workflows |
| Repeated OCR, conversion, signing, redaction, batch work, multi-user service, or API integration | Stirling-PDF | Desktop/browser/server surfaces, Docker, 50+ tools, no-code pipelines, and REST APIs |
Do not send sensitive PDFs to an arbitrary hosted converter. Browser-local and self-hosted are privacy boundaries, not magical security guarantees: verify the code/version, deployment, browser extensions, storage, logs, authentication, network egress, and output before using either route for legal, identity, financial, or confidential documents.
pdf-inspector preflight
firecrawl/pdf-inspector is the local decision layer before an expensive or
lossy extraction path. At pinned revision
f4aab3b36f7fa1752c65ea45fa64be1274f671cf, its Rust core exposes Node,
Python, WASM, CLI, and Rust surfaces for text/scanned/image/mixed
classification, confidence, and page-level OCR routing. The implementation also
emits reasons such as scanned, no_text, vector_text, and
suspected_garbled_text; region and table APIs preserve a needs_ocr boundary
instead of pretending partial extraction is trustworthy. Source: pinned
repository evidence and source entry, reviewed 2026-08-12
Use it when a batch contains mixed document types, when OCR cost/latency matters, or when broken font encodings could make extracted text look valid while being wrong. Keep its page numbering convention explicit across bindings, retain the confidence/reason receipt, and visually inspect representative routed and non-routed pages. Its published 200-document benchmark is reproducible evidence for that named corpus and configuration—not proof that every legal form, chart, signature, redaction, encryption scheme, or document family is solved. MIT licensing permits adaptation, but promotion to a default still requires a pinned representative canary.
PDFCraft
PDFCraft is the browser-local route. Its current upstream README documents 90+ tools, client-side WebAssembly processing, 23+ workflow templates, saved workflows, branching, and batch processing. The app can run from its static site, a local development checkout, a static export, or its container image. The launch video and reviewed thumbnail show the visual editor and repository, not merely a marketing claim. Source: PDFCraft README and local X media, reviewed 2026-08-10
docker run -d -p 8080:80 --name pdfcraft \
ghcr.io/pdfcrafttool/pdfcraft:latest
Current snapshot: main HEAD 0a84e607e20e43c379ebc0db46038312fed8db62,
release v2026.07.31-0a84e60, 8,216 stars, 1,845 forks, and AGPL-3.0.
AGPL is a real adoption constraint for modified network deployments; it is not
equivalent to permissive MIT. Source: GitHub API, upstream LICENSE, and release,
checked 2026-08-12
The pinned tree contains 62 test files and five workflows, but source volume is not a fidelity guarantee. The visual workflow editor is explicitly beta. Before using a new operation on important material, run a representative canary that covers the actual PDF features in play—malformed or encrypted input, forms, annotations, embedded fonts, signatures, redactions, OCR/text layer, page boxes, large files, and metadata as applicable—and compare page count, rendered pages, searchable text, permissions, file size, and hashes. Keep the original untouched. Source: pinned repository evidence and upstream README, 2026-08-12
Stirling-PDF
Stirling-PDF is the persistent service route. Its current upstream README documents desktop, browser, and self-hosted server use; edit, merge, split, sign, redact, convert, OCR, and compress operations; no-code workflows; and REST APIs for nearly all tools. Source: Stirling-PDF README, reviewed 2026-08-10
docker run -p 8080:8080 \
docker.stirlingpdf.com/stirlingtools/stirling-pdf
Current snapshot: main HEAD bbaff8d6c4d3ce0c8ad6da8e8838df9813872eac,
release v2.14.3, 89,285 stars, and 8,071 forks. The root LICENSE applies MIT
to content outside named proprietary, SaaS, engine, desktop, cloud, prototype,
and portal directories, which may carry their own licenses. Therefore “the
entire repo is MIT” is too broad; inspect the exact paths and edition used.
Source: GitHub API and upstream LICENSE, checked 2026-08-10
Operating Contract
- Preserve the original file; write to a new output path.
- Classify the job as extraction, one-off browser-local mutation, or persistent service/API automation before selecting a tool.
- For sensitive inputs, prefer local/offline execution and record the tool, version/image digest, deployment boundary, and whether network egress was disabled.
- Describe the intended page count, ordering, forms, annotations, signatures, redactions, encryption, OCR layer, and metadata before mutation.
- Inspect representative pages and compare page count, file size, searchable text, permissions, redaction result, and hashes after processing.
- Keep a workflow/API recipe only when the operation will recur; otherwise do not turn a one-off document into a permanent service.
What Changed
The source review corrected two old failure modes at once: PDFCraft remains a recommended browser-local workflow tool, while Stirling-PDF remains a stronger self-hosted API and automation route. Engagement and “free forever” language do not decide adoption; current source, privacy boundary, deployment shape, license, and output verification do.
Timeline
- 2026-08-12 | Added Firecrawl
pdf-inspectoras the local preflight rather than another PDF utility: classify text/scanned/image/mixed inputs, retain confidence and page-level OCR reasons, route only necessary pages, and verify against the actual document family. The source-capture audit also fixed the research pipeline so Rustsrc/lib.rsis inspected and binary fixtures no longer consume text-evidence slots. Source: X/@nickscamara_2083295265793212827;firecrawl/pdf-inspector@f4aab3b36f7fa1752c65ea45fa64be1274f671cf - 2026-08-12 | Completed the native Discord follow-up against commit
0a84e607: kept PDFCraft as the browser-local visual route, recorded AGPL and beta-workflow boundaries, and added representative malformed/encrypted/form/annotation/font/signature/redaction/OCR fidelity gates instead of treating its 90+ tool list as proof. Source: pinned repository receipt and Discord source revision - 2026-08-10 | Created one consolidated PDF-operations route from correlated PDFCraft and Stirling-PDF bookmarks, inspected both launch thumbnails and current upstream sources, corrected the license distinction, and added a callable skill without creating one page per utility. [Sources: X/@simplifyinAI
2077948353401524551and2077948356400492867; X/@itsharmanjot2078466103882469579; PDFCraft and Stirling-PDF GitHub sources]