Stirling PDF

What it does

Stirling PDF is an open-core PDF toolkit that runs as a desktop app, a browser interface, or a server you host yourself. It bundles around fifty operations — merging, splitting, converting, OCR, compression, redaction and signing — and exposes them through a web UI, a REST API and no-code pipelines. The self-hosted edition is free for up to five users.

Best for: Teams that want a PDF toolkit inside their own infrastructure, with an API and automation rather than a consumer web service.

Worth knowing: Not every tool runs in the purely local desktop mode — OCR, Office-format conversion, compression and repair need a server, so full-local use means self-hosting or sending those jobs to Stirling's cloud for credits. If you do self-host: the 2.x server release needs a Java 25 runtime and will not start on Java 21.

Details, and where each comes from

Vendor statements, our own reading of their pages, and the things nobody has established yet, each answered separately. Where we have not confirmed something it says so rather than guessing, and a row nobody has established is greyed out.

Versions covered

Web · Windows · macOS · Linux · API · Self-hosted

Website

stirling.com

Requires an account

No

Free tier

Yes

Watermark on the free tier

Not verified

Maximum file size

Not verified

Batch processing

Yes

Data residency

Self-hosted

Open source

Yes

Self-hostable

Yes

Licence

MIT for the core; some directories carry separate licences (open-core)

Redaction

Removes the content

Programmatic access

HTTP API

Last availability check

Responded in 154 ms 16 October 2026

Checked automatically by our own runner, not reported by the vendor. 100% of our last 30 checks got a response.

What the vendor says

Claims are labelled rather than repeated as fact. Where we have checked something ourselves, it says so and shows when. Checked means we read the vendor's own page and it says what we recorded — not that we tested the behaviour, unless the note says we did.

• “Unlike a simple black box drawn on top of the page, automatic redaction deletes the matching text from the file so the underlying text is genuinely removed - not merely hidden.”

  Checked by us — the source says this Read 22 September 2026

  RE-QUOTED 2026-09-22: this claim previously read "Unlike a simple black box drawn on top of the page, redaction deletes the matching text from the file so the underlying text is genuinely removed - not merely hidden." — our characterisation rather than the vendor's wording, so a reader could not tell a quotation from a summary. The vendor's own sentence is now in the claim field and what we read from it follows here. The boxed string is gone from the saved file, and so are the text lines the drawn box covered. Lines outside the box survived, and the untouched second page kept its text, fonts and text layer. The output contains zero image XObjects, so nothing was rasterised: the marked text is deleted from the page structure and a solid fill is drawn where it was. qpdf reports no errors. This is removal, and it is done without flattening the page - the contrast with SnackPDF, which rebuilds the affected page as an image, is the reason both verdicts are now worth having.

  Standing: Re-read, and the recorded hash was not reproduced

  Check it yourself: the source, the SHA-256, and how we checked

  Read

  https://docs.stirlingpdf.com/Functionality/Page-Operations/redact/

  From

  the raw HTTP response

  SHA-256

  b18355d34f088ce4b3aba7c0f782f589124f04efd91caf5b2d72a527a4affe5d

  Note

  real drift in the vendor's documentation: the Manual bullet was rewritten ("draw redactions over specific text, areas, or whole pages" became "mark specific text or areas for redaction"), and the page is 5,470 characters shorter. RE-READ 2026-09-21: the claim's own sentence, "Unlike a simple black box drawn on top of the page, automatic redaction deletes the matching text from the file so the underlying text is genuinely removed - not merely hidden", is present verbatim, so the verdict stands.

  How we checked: Re-verified verbatim on 2026-09-22: https://docs.stirlingpdf.com/Functionality/Page-Operations/redact/ rendered in headless Chrome with scripts/render-page.mjs, and this sentence found in the rendered text. ALSO RE-QUOTED on the same date: the claim field previously held our own summary of this page rather than the vendor's sentence, which made it impossible to verify by quotation — the schema's own words are "we do not repeat a vendor's claim as though it were our own finding", and the reverse holds too. sourceHash is the SHA-256 of the rendered text, held as p10-stirling-redact.txt.

  What this hash proves, and what it does not

Each claim is quoted from the vendor's own pages. This section describes what we have and have not checked — it is not a judgement about anyone.