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

  1. Preserve the original file; write to a new output path.
  2. Classify the job as extraction, one-off browser-local mutation, or persistent service/API automation before selecting a tool.
  3. For sensitive inputs, prefer local/offline execution and record the tool, version/image digest, deployment boundary, and whether network egress was disabled.
  4. Describe the intended page count, ordering, forms, annotations, signatures, redactions, encryption, OCR layer, and metadata before mutation.
  5. Inspect representative pages and compare page count, file size, searchable text, permissions, redaction result, and hashes after processing.
  6. 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-inspector as 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 Rust src/lib.rs is 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 2077948353401524551 and 2077948356400492867; X/@itsharmanjot 2078466103882469579; PDFCraft and Stirling-PDF GitHub sources]