Stirling-PDF: local web application to perform various operations on PDFs

Original Article ↗ Hacker News Discussion ↗

Self-hosted PDF tools like Stirling-PDF are gaining attention as privacy-conscious users look for alternatives to web services that require uploading sensitive documents. Commenters compare a wide range of options—from command-line utilities and native apps like macOS Preview to browser-based and WASM tools—highlighting trade-offs between ease of use, feature completeness, resource bloat, and cross-platform support. The thread also touches on harder PDF problems (form parsing, layout reflow, tagging, optimization) and notes that even with an open standard, Adobe’s ecosystem still dominates many advanced use cases.

Overall reception & use cases

  • Many responders welcome a self-hosted, browser-based PDF tool to avoid uploading sensitive documents to random sites.
  • Particularly valued for non-technical users and mixed-device households (desktop + mobile) who still need a simple UI.
  • Some see it as ideal for internal deployments (e.g., offices, newsrooms) where many people frequently manipulate PDFs.

Alternative tools & ecosystems

  • Command-line tools: poppler-utils, pdfcpu, pdftk (with reports of corruption on some Windows servers), Ghostscript, OCRmyPDF, ImageMagick, wkhtmltopdf, puppeteer/headless browsers.
  • Desktop/OS tools: macOS Preview is repeatedly praised for extensive PDF editing; others mention Okular, LibreOffice Draw, Inkscape, Xournal++, Edge, Firefox, various commercial editors (Foxit, Nitro, PDF Studio, PDF Expert, Bluebeam, etc.).
  • Web / browser-only tools: pdfsam, pdf24, pdftool.org, smallpdf, Tabula, and several new fully in-browser editors/signers are referenced.

Feature gaps and hard PDF problems

  • Desired features: adding/managing form fields, attachments, tagging/structure for accessibility, redaction, paragraph numbering, key–value extraction from filled forms, good repair tools, and robust compression.
  • Several “hard problems” are called out:
    • Reflowing multi-column magazine PDFs into clean Markdown.
    • Extracting structured data from complex forms (often needing OCR + layout analysis).
    • Fixing odd text selection issues, where the PDF may not actually be “broken.”
  • Various workarounds involve GPT-4 Vision / LLMs, column-aware OCR, scripting pipelines, and Ghostscript-based optimization.

Architecture: web app vs native

  • One camp criticizes running a web server + Docker for local PDF ops, preferring tiny native CLI tools for efficiency and environmental reasons.
  • Others argue web UIs are easiest to use and deploy cross-platform, especially for many non-technical users; containerization simplifies maintenance at scale.
  • Discussion touches on Electron vs lighter options (Tauri, NodeGUI) and WASM/client-only approaches. The project’s v2 is planned to be largely client-side.

PDF format & viewer ecosystem

  • Debate over Adobe’s “control”: PDF is now an ISO standard and widely implemented, but some argue only Acrobat reliably supports the full, complex spec (JS, 3D, advanced features).
  • Others counter that most real-world PDFs render fine in third-party tools; PDF/A is highlighted for archival.
  • macOS Preview is widely lauded but known bugs (e.g., signature operations scrambling text searchability) and limited support for scripted features are noted.

Project origins and roadmap

  • The app reportedly began as a “100% ChatGPT-built” experiment (early website and a handful of operations) and was then heavily rewritten and expanded manually.
  • Currently donation-supported; the maintainer mentions possible future paid/AI-powered features but wants the core to remain free.
  • Plans include a richer UI (possibly Electron or similar) and a client-heavy v2 while retaining a server option for API use.