Skip to content
dialegein

Pdftools SDK

Commercial SDK for PDF/A conversion, validation, compression and signing at volume.

Jobs Convert Compress Sign

Operated by Apryse

Where your files are processed

No server involved

An SDK that runs inside your own application. The vendor's own wording is "deploy on-premise, in the cloud, or hybrid", where cloud means the customer's cloud rather than theirs. The same company also sells a separate Conversion Service, and the documentation offers that for self-hosted, on-premises and cloud deployment on Windows, Linux and Docker, so it is not a vendor-hosted-only product: a REST API is an interface rather than evidence that the vendor processes the files. That is a property of the library itself: what an application built with it does with your file depends on that application, not on this.

It is an embedded SDK, so it runs inside the application that links it. The vendor also sells a separate Conversion Service, and that service is offered for self-hosted, on-premises and cloud deployment on Windows, Linux and Docker rather than being vendor-hosted only: a REST API is an interface, not evidence that the vendor processes the files. SDK deployment and service deployment are separate decisions, and where documents go is determined by the deployment rather than by the shared boilerplate.

What it does

The Pdftools SDK does the document-processing jobs that have to be right rather than merely done: converting to and from PDF, producing PDF/A for archiving, validating a file against the PDF and PDF/A standards, compressing, and applying or checking digital signatures. It is aimed at volume — pipelines that run over large document sets in regulated environments — and it is bound into C, Java, Python and .NET, with a C API underneath for anything else. It deploys on-premises, in a private cloud or in a hybrid arrangement, and the same vendor sells a conversion service and a PDF viewer.

Best for: Enterprise document pipelines where PDF/A compliance and validation matter, and teams whose existing stack is in C or a language without good PDF tooling, since the C API is genuinely a first-class binding rather than an afterthought. It is also a reasonable choice where deployment has to stay on your own infrastructure for regulatory reasons.

Worth knowing: The vendor is joining Apryse, which is the documented acquisition notice and the fact this record carries; predictions that commercial terms, support or the roadmap will change are not made here, because the notice does not say so and no change notice has been read. Pricing is yearly and usage based, as a dated vendor statement, and quotas, committed usage and fees are separate quantities rather than one figure. Redaction through this SDK is left uncertain until the licensed API is verified: the Viewer documents redaction and this record does not borrow that verdict.

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
Windows · Linux · macOS · Self-hosted
Website
pdf-tools.com
Requires an account
Not applicable
Free tier
Not verified
Watermark on the free tier
Not verified
Maximum file size
Not verified
Batch processing
Yes
Data residency
Self-hosted
Open source
No
Self-hostable
Yes
Licence
Commercial, usage-based with a yearly licence and no monthly caps
Redaction
Not determined
Programmatic access
Embeddable library
Last availability check
Responded in 13 ms 16 October 2026

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

Why we have not determined this

What that does not establish: RECORDED AS UNVERIFIED, AND THE REASON IS SPECIFIC. The vendor makes an unusually strong redaction claim elsewhere on this site — "Redaction That Can't Be Undone", building "a new PDF without sensitive information" with "no residual data" — and that page attributes the manual redaction path to the PDF Viewer rather than to this SDK. This SDK's own page describes conversion, PDF/A creation and validation, compression and signing, and does not mention redaction at all. Recording `removes_content` here would be taking a family brochure for a product page, which is the mistake this index made with Foxit's desktop editor and the SDK. What would settle it: the API reference for this SDK, or a canary test through it.

https://www.pdf-tools.com/products/conversion/pdf-tools-sdk/

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.

  • “Build large-scale document processing solutions for fast and accurate outputs: PDF/A conversion, compression, signing, and more. Deploy on-premise, in the cloud, or hybrid.”

    Checked by us — the source says this Read 1 October 2026

    Confirmed. The quoted text appears in the rendered page as read on 2026-10-01. This claim was carried as reported rather than checked until this read.

    Standing: Not re-read against the live source

    Check it yourself: the source, the SHA-256, and how we checked
    Read
    https://www.pdf-tools.com/products/conversion/pdf-tools-sdk/
    From
    the text a browser renders
    SHA-256
    62f1dfad62a3eeb5f6ace9355df41c339efb93e2ba5c77ab751fc60f61723018

    How we checked: Read as rendered text in headless Chrome on 2026-10-01 and saved to the evidence archive, so the read can be repeated against the same file. Comparison ignores case, punctuation and hyphenation, which is why "open-source" on the record matches "open source" on the page.

    What this hash proves, and what it does not

  • “The Pdftools PDF SDK validates compliance with important PDF standards, such as PDF/A for archiving.”

    Checked by us — the source says this Read 1 October 2026

    Confirmed. The quoted text appears in the rendered page as read on 2026-10-01. This claim was carried as reported rather than checked until this read.

    Standing: Not re-read against the live source

    Check it yourself: the source, the SHA-256, and how we checked
    Read
    https://www.pdf-tools.com/products/conversion/pdf-tools-sdk/
    From
    the text a browser renders
    SHA-256
    62f1dfad62a3eeb5f6ace9355df41c339efb93e2ba5c77ab751fc60f61723018

    How we checked: Read as rendered text in headless Chrome on 2026-10-01 and saved to the evidence archive, so the read can be repeated against the same file. Comparison ignores case, punctuation and hyphenation, which is why "open-source" on the record matches "open source" on the page.

    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.

Sponsorship is distribution, not an endorsement or a promise of search rankings, AI citations, traffic, or sales. This listing is a free entry, compiled from published sources.

Visit Pdftools SDK Report a problem

Related reading

How this record was put together

Editorial review.
No editor has signed this record off. That is not the same as nothing having been checked, and the lines below say what has.
Source reading.
2 claims taken from the vendor's own pages, read between 1 October 2026 and 1 October 2026.
Website availability.
The vendor's site was last checked on 16 October 2026.
Behaviour testing.
We ran this ourselves. The file handling was watched directly.

Sources: pdf-tools.com: the home page, the Pdftools SDK product page and the true-redaction feature page, read 2026-09-22 with headless Chrome. Vendor documentation, not independently tested; the SDK was not downloaded and no document was converted.