Skip to content
dialegein

LEADTOOLS PDF SDK

Commercial PDF SDK for .NET, C++ and mobile targets, with OCR, forms, conversion and automatic redaction alongside the PDF API.

Operated by Apryse

Where your files are processed

No server involved

A commercial SDK compiled into the application you build. The PDF library and the Document Analyzer component that drives automatic redaction both run in your own process on your own infrastructure; LEADTOOLS operates no processing service in that path and there is no account. 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 a set of libraries that run inside the application linking them, with no vendor service in that path. That is a statement about the components rather than about every deployment: the same vendor page describes hosted backends for web comparison components, and Document Analyzer is not asserted to always run in the same process. Architecture is not an independent traffic test.

What it does

LEADTOOLS is a broad commercial SDK family — imaging, recognition, document, medical and vector toolkits — and the PDF SDK is the part that covers PDF: a library API for creating, loading, viewing and saving PDFs, for form fields, annotations and bookmarks, for encryption, permissions and digital signatures, and for conversion in both directions against PDF/A and other standards. What distinguishes it from the other commercial PDF SDKs in this index is that the PDF library sits inside a much larger recognition stack, so text extraction, OCR, document analysis and automatic redaction are documented as part of the same product rather than as separate purchases. The deployment surface is unusually wide: one project can target Windows, Linux, macOS, Android, iOS and the web.

Best for: Teams building a document application across several platforms at once, and particularly those who need recognition and PDF handling together — scanning, OCR, forms processing, document analysis and redaction in the same codebase. It is a heavy SDK bought by OEMs and product teams rather than a component added to an existing app, and a reader wanting to manipulate one PDF will find it is priced and sized for something else entirely.

Worth knowing: LEAD Technologies has been acquired by Apryse, announced in the vendor's own news section, so this is no longer an independent alternative to the largest SDK vendor in this index — several of the names a reader might compare here now share an owner, and what the acquisition means for licensing and support is not established by anything read. There is no published price: LEADTOOLS is quote-only, and the pages read describe per-developer and deployment licensing only in general terms. Redaction deserves particular care because the vendor's claim is that information "can be removed from the PDF automatically" when the Document Analyzer component is used — that is a claim about a specific toolchain, and automatic detection of account numbers and social security numbers is exactly the sort of feature whose accuracy should be tested on your own documents before it is relied on for compliance. The redaction capability is also described as depending on a separate SDK component rather than on the PDF library alone, so what is included at any given licence level needs confirming. And an SDK this broad has a large surface area: the PDF-specific capabilities are a subset of a family that also covers medical imaging and vector graphics, so the licence you are quoted may include more than you need. The capabilities in this family are combined rather than assumed: the official page describes combining PDF APIs with OCR, recognition and Document Analyzer, which does not by itself establish that one licence includes every capability on every platform, so a licensed-product and platform matrix is the thing to check. Redaction comes in both permanent and temporary modes, and applied content removal is different from masking with annotations, as is detection accuracy.

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 · Android · iOS · Web · Self-hosted
Website
leadtools.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
Not verified
Open source
No
Self-hostable
Yes
Licence
Commercial, quoted rather than published. LEADTOOLS is licensed per developer and per deployment; no price, tier or evaluation limit is stated on the pages read.
Redaction
Removes the content
Programmatic access
Embeddable library
Last availability check
Responded in 205 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 redaction verdict rests on

From the vendor's own documentation, read 22 September 2026. Not tested by us.

“Additionally, by leveraging PDF image and text redaction and the LEADTOOLS Document Analyzer SDK component, user-defined information such as account numbers and social security numbers can be removed from the PDF automatically.”

What that does not establish: Recorded as removal on the vendor's own wording — "can be removed from the PDF automatically" — and it is a claim about a specific toolchain rather than about the library as a whole: the sentence names both "PDF image and text redaction" and the separate Document Analyzer component as what makes automatic removal possible. A tutorial on the same site, "Redact Text in PDF Using RegEx in C# and VB.NET", corroborates that redaction is a documented API operation rather than a marketing bullet. What it does not establish: whether the removal is irreversible in the way PrizmDoc's "no traces of the text" describes, since the wording here is about the operation succeeding rather than about what remains in the file; and whether a licence at any given level includes the Document Analyzer component the sentence depends on. Nothing was tested, and this is one of the verdicts in the index where a test would be worth more than the documentation it currently rests on.

https://www.leadtools.com/sdk/pdf

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.

  • “Apryse, the global leader in document processing technology, announced its most recent acquisition of LEAD Technologies, a leading provider of AI-powered SDKs for application development across all major platforms and programming languages.”

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

    Confirmed verbatim from the vendor's own news section on its home page. Recorded because it changes who the reader is dealing with, and because it is the second Apryse acquisition read in the same session — Accusoft's site carries a banner saying it too has been acquired. The acquisition is stated; no date, price or completion status is given in the text read, and none is inferred. owner is set to Apryse so the records group on /owners, which is where the consolidation becomes visible to a reader.

    Standing: Re-read and matched byte for byte

    Check it yourself: the source, the SHA-256, and how we checked
    From
    the text a browser renders
    SHA-256
    c72a5c2eaf8ad63bb01746c4a03fcd3cd200609af3e7e22bc38d6dea1770fe34

    How we checked: https://www.leadtools.com/ rendered in headless Chrome with scripts/render-page.mjs on 2026-09-22 (visible text 14780 bytes) and the announcement read from that rendered text, under the heading "Apryse Announces Acquisition of AI-Powered Document Toolkit Provider LEAD Technologies". sourceHash is the SHA-256 of that text.

    What this hash proves, and what it does not

  • “Projects that use LEADTOOLS PDF libraries can be deployed to Windows, Linux, macOS, Android, iOS, and Web devices.”

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

    Present verbatim under the heading "PDF SDK Platforms and Programming Interfaces", and platforms is recorded from it. The same section names the supported frameworks — .NET 6 and later, .NET Framework, .NET MAUI, Xamarin, UWP, WinForms and a C++ class library — which is what makes the breadth checkable rather than promotional. This is the widest platform list on any PDF SDK in the index, and it is the reason the record carries six platform values plus self_hosted.

    Standing: Re-read and matched byte for byte

    Check it yourself: the source, the SHA-256, and how we checked
    From
    the text a browser renders
    SHA-256
    a80ce86e0dc43ebd37947afd174bfa397ddb04144a1d77f27d8efe88d227bb4a

    How we checked: https://www.leadtools.com/sdk/pdf rendered in headless Chrome with scripts/render-page.mjs on 2026-09-22 (visible text 11613 bytes) and the claim checked against that rendered text, including the framework list that follows it. sourceHash is the SHA-256 of that text.

    What this hash proves, and what it does not

  • “In addition to changing formats, the LEADTOOLS PDF Conversion API can convert between PDF and PDF/A, convert between PDF standards versions, linearize PDFs for "Fast Web View", and distill Postscript with optimizations for eBook, screen, and pre-press applications.”

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

    Confirmed verbatim. Recorded because it is the most specific capability statement on the page and because it covers ground the other SDK records in this index do not mention at all: converting between PDF standards versions, linearising for fast web view, and PostScript distillation with pre-press optimisations. Those are the details that separate an SDK used for archival and print work from one used for display, and they are stated precisely enough for a reader to test against their own requirements.

    Standing: Re-read and matched byte for byte

    Check it yourself: the source, the SHA-256, and how we checked
    From
    the text a browser renders
    SHA-256
    a80ce86e0dc43ebd37947afd174bfa397ddb04144a1d77f27d8efe88d227bb4a

    How we checked: Same rendered page and hash as the claim above; the conversion section was read together with the surrounding capability sections for viewer, forms, security and annotations.

    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 LEADTOOLS PDF 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.
3 claims taken from the vendor's own pages, read between 22 September 2026 and 22 September 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: leadtools.com, read 2026-09-22 with headless Chrome: the company home page (visible text 14780 bytes, including the news section carrying the acquisition announcement) and the PDF SDK product page (11613 bytes, including the capability sections for viewer, forms, conversion, security and redaction, and the platforms and programming interfaces list). Vendor documentation, not independently tested; no SDK was downloaded, no evaluation was requested and no document was processed.