iText
Java and .NET PDF library with an AGPL-3.0 core and component-specific licensing.
Operated by Apryse
Opens the vendor's own site.
Jobs covered
Open a task to see exactly what the vendor documentation supports.
Edit
Browse all edit toolsediting an existing PDF by opening it with a reader and a writer and adding additional content such as a new page, a paragraph or an image, with examples for Java and .NET
Convert
Browse all convert toolsconverting HTML and CSS to PDF through the pdfHTML add-on of the iText PDF SDK; not arbitrary format conversion and not part of the base library
Protect
Browse all protect toolsencrypting PDFs with a user and/or owner password and decrypting a PDF with its owner password, as shown in the iText Core security examples for Java and .NET
Merge
Browse all merge toolsmerging multiple PDFs into one as part of the PDF manipulation features of iText Core/Community for Java and .NET
Compress
Browse all compress toolsautomatically optimising PDFs, including in bulk, through the pdfOptimizer add-on of the iText PDF SDK; not part of the base library
Accessibility
Browse all accessibility toolscreating PDF/UA documents and running PDF/UA-1 conformance checks through the PdfUADocument and PdfUAConfig APIs of iText Core, including setting the document as tagged and accessibility properties on form fields; the checks are programmatic support for many, not all, Matterhorn Protocol checkpoints
Sign
Browse all sign toolsdigitally signing PDFs through iText's high level signing API, with examples for Java and .NET
View
Browse all view toolsrendering PDF pages to image output such as JPG, PNG or an in-memory image through the licensed pdfRender add-on, for example to preview a page as an image; this is rasterising to an image, not on-screen display, and is not part of the base library
OCR
Browse all ocr toolsOCR text recognition in scanned documents, PDFs and images through the pdfOCR add-on of the iText PDF SDK; not part of the base library
Extract
Browse all extract toolsextracting text from PDFs using text extraction strategies and location extraction strategies, as demonstrated by the Parsing PDFs examples in Java and .NET
Where your files are processed
No server involved
An in-process Java and .NET library. There is no hosted component and no vendor service in the path, so documents are parsed and written inside the calling application. 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.
Architectural: an in-process library distributed as JARs (Maven) or DLLs (NuGet). There is no hosted component, and files are read and written by the host application's own code on the local filesystem.
Apryse separately markets an iText Suite BYOL listing on AWS Marketplace described as using a REST API, which would move processing to the customer's own AWS deployment rather than an Apryse service.
What it does
iText is a PDF library for Java and .NET, split into an open-source core that creates, edits and manipulates documents at the object level, and a set of add-ons that cover HTML-to-PDF conversion, redaction, OCR, compression, XFA flattening and advanced typography. It is one of the oldest PDF toolkits still in wide use and is embedded in server-side document pipelines rather than offered to end users as an application.
The core is dual-licensed, so the same binaries can be used free under AGPL-3.0 or paid for under a commercial licence that removes the copyleft obligations.
Best for
Engineering teams that need a mature, deeply documented PDF engine inside a Java or .NET backend, where AGPL-3.0 is acceptable or the budget exists for a commercial licence.
Worth knowing
The dual licence is the entire commercial story and it is stricter than most open-source PDF libraries. iText's own AGPL page states that using the core in a non-AGPL environment is a legal violation and requires disclosing the full source of your own application, so the free route is only open to projects that are themselves AGPL. A closed-source product needs a commercial licence for the core as well as the add-ons, and both are quote-only.
The add-ons are not licensed alike, which the subtitle used to imply: the vendor’s own community and get-started pages identify pdfHTML, pdfSweep and pdfOCR as open source, while pdfCalligraph, pdfXFA and pdfOptimizer are closed source. Buying the core does not include every add-on.
Embedded deployments and the AWS or REST packaging are distinct editions rather than one web service, and a renderer component, not core PDF creation, is what a View membership should rest on.
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 · macOS · Linux · Self-hosted
- Website
- itextpdf.com
- Requires an account
- Not applicable
- Free tier
- Yes
- Watermark on the free tier
- Not verified
- Maximum file size
- Not verified
- Batch processing
- Yes
- Data residency
- Not verified
- Open source
- Yes
- Self-hostable
- Yes
- Licence
-
Dual-licensed per licensee rather than per module: the iText Core toolkit and most of...
Dual-licensed per licensee rather than per module: the iText Core toolkit and most of its add-ons are available under AGPL-3.0, or under a commercial licence that removes the source-disclosure obligation for closed-source products. pdfHTML - the most commonly used add-on, and the one that converts HTML to PDF - is dual-licensed this way, not commercial-only. pdfCalligraph is the add-on iText names as genuinely closed source. iText publishes no single page allocating every add-on, so this is established add-on by add-on rather than in general.
- Redaction
- Removes the content
- Programmatic access
- Embeddable library
- Last availability check
- Responded in 387 ms 21 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.
“pdfSweep is an iText Core add-on for Java and C# (.NET) that removes (redacts) information from a PDF document in a reliable and secure way … After adding a digital "blackout bar" over the sensitive text, image or part of an image, pdfSweep changes the document's rendering instructions causing the hidden content of your digital document to become impossible to extract.”
What that does not establish
WEAKER BASIS THAN IT SHOULD BE, THOUGH LESS WEAK THAN IT WAS. The page body did not render on the first pass and only the title could be read, which is how this verdict was originally recorded.
Re-read with headless Chrome on 2026-09-22, the body does render and describes the mechanism itself. But that is product-page prose rather than API documentation, so the verdict still rests on a vendor's marketing description of what the call does to the file rather than on a contract for it.
Someone should read the pdfSweep API documentation directly, or run the canary, and replace this. Read from vendor wording, not tested by us.
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.
-
“PDFTron Systems Inc., the world's leading provider of digital content solutions for software developers, has acquired iText Group NV, the leading global open source PDF technology company. Created in 2000 and commercially available since 2008, iText's flagship product is a software library to create and manipulate PDF documents in Java and .NET.”
Checked by us - the source says this Read 22 September 2026
Confirmed verbatim: the paragraph appears unaltered in the acquisition announcement, including the superlatives "the world's leading provider" and "the leading global open source PDF technology company". Both are the acquirer's characterisation of itself and of its acquisition, in a post on its own blog, so they are recorded as the company's wording rather than as an assessment.
The checkable parts of the claim are the dates and the product description - created in 2000, commercially available since 2008, a Java and .NET library - and the page states them as recorded. The same paragraph adds "millions of iText users, both open source and commercial", which is a figure with no source attached.
Recorded as the vendor's announcement; no control was run.
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
- 1dfc98084054ccf639928ddd7d38954bd29a9e959ea05a4d0acbc143ca1e243a
How we checked
Re-verified verbatim on 2026-09-22: https://apryse.com/blog/news/pdftron-acquires-itext re-rendered in headless Chrome with scripts/render-page.mjs and the claim's wording found in the rendered text. Originally verified on 2026-09-21. sourceHash is the SHA-256 of the re-rendered text, held as rv-apryse-com-blog-news-pdftron-acquires-itext-fd1589b9.txt.
-
“By following the rules of the Affero General Public License (AGPLv3), you may use the iText PDF library and our open-source add-ons at no cost. This license applies to iText 5 and all subsequent versions.”
Checked by us - the source says this Read 22 September 2026
Confirmed verbatim: the sentence appears unaltered at the top of the page. Two things the page adds are worth carrying.
The version scope in the claim is deliberate and is repeated elsewhere on the page - "iText 5 and all subsequent versions of iText are dual-licensed" - so this is a statement about every version from 5 onward, not about one release. And the conditions are set out plainly under a heading reading "Only allowed in AGPL environments", with the commercial alternative offered for anyone who cannot meet them.
This is the same structure Artifex uses for Ghostscript and MuPDF and borb uses for its library, all verified in this batch, which makes it the common licensing shape in this index rather than an exception. Recorded as the vendor's description; no control was run.
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
- f4d9252d2982f27da85eda33452e44dac7ec3e326b4a1758de9247497b49ff91
How we checked
Re-verified verbatim on 2026-09-22: https://itextpdf.com/how-buy/AGPLv3-license re-rendered in headless Chrome with scripts/render-page.mjs and the claim's wording found in the rendered text. Originally verified on 2026-09-21. sourceHash is the SHA-256 of the re-rendered text, held as rv-itextpdf-com-how-buy-AGPLv3-license-fd7211be.txt.
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.
Related reading
- Checking a PDF for accessibility - what makes a PDF accessible, and how it is checked.
- Which PDF tools really redact - which tools remove the content rather than cover it.
- Which PDF tools keep your file on your machine - what we count as processing on your own device.
- Open source PDF tools, and what their licences require - what open source does and does not tell you.
Compared head to head
- iText vs Apryse Two developer PDF libraries, and one company owns both.