iTextSharp .NET PDF Library: EOL Status and Migration Path

Why iTextSharp Exists and Who Still Needs It

iTextSharp is the .NET port of the iText PDF library. It addresses applications that need to create, process, or work with PDF documents inside a C# or .NET environment, including document generation and PDF/A-related workflows. The repository now positions the project primarily as a maintenance burden for existing users rather than a foundation for new development. Its README marks iTextSharp as end-of-life and states that only security fixes will be added.

That status narrows the appropriate audience considerably. A team maintaining a working C# application that depends on existing iTextSharp behavior may need access to another release while it plans a migration. A team starting a new document service should instead start with iText 7, which the repository identifies as the replacement. The distinction matters because adopting a deprecated library for a new feature cycle also means accepting a narrower roadmap, comparing its capabilities with the replacement, and planning for code or API changes later.

The project is not archived, and the last push was on 2026-07-27. However, repository activity should not be read as a return to feature development. The explicit EOL notice and security-only policy define the intended maintenance boundary. Release history includes versions 5.5.13.4, 5.5.13.5, and 5.5.13.6, with 5.5.13.6 released on 2026-07-23. That sequence shows that maintenance releases can still occur without reversing the migration recommendation.

The Four iTextSharp Assembly Boundaries

The README describes iTextSharp as a set of DLLs rather than one interchangeable component. The main release contains itextsharp.dll for the core library, itextsharp.xtra.dll for extra functionality described as PDF 2 support, itextsharp.pdfa.dll for PDF/A-related behavior, and itextsharp.xmlworker.dll for XML and HTML functionality. This packaging gives an adopter an initial way to determine which parts of the project are relevant to a particular document workflow.

The split is operationally significant because a core PDF need does not imply that every feature belongs in the same assembly. An application focused on PDF/A would have to inspect the PDF/A package, while an HTML-based conversion path points toward XML Worker. Likewise, features labeled as extra functionality should not be assumed to be included with itextsharp.dll. Package selection therefore needs to follow the capabilities required by the application, not merely the project name.

The repository layout supports that interpretation. Separate NuGet specifications exist for itextsharp, itextsharp.pdfa, itextsharp.xmlworker, and itextsharp.xtra. It also contains specifications for Asian language resources and hyphenation XML. Those files indicate distinct distribution units, although the README does not document their exact package installation commands or dependency resolution. Based on the repository layout, the safest assumption is that feature availability depends on selecting the appropriate assembly or package.

This assembly boundary also makes migration work more concrete. A consumer can inventory calls tied to XML Worker or PDF/A rather than treating every use of iTextSharp as core behavior. That inventory is useful when comparing the existing implementation with the modular document workflow and additional capabilities listed for iText 7.

What iTextSharp Can and Cannot Add After EOL

iTextSharp's remaining scope is security fixes. The README does not promise feature additions, bug fixes beyond security work, performance work, or compatibility changes for new PDF workflows. This makes it unsuitable as the intended long-term base for an application that expects new document formats, broader language coverage, or new forms of PDF inspection.

The replacement direction is concrete. The README identifies iText 7 as the successor and names HTML to PDF with PDF/UA conversion, PDF Redaction, SVG support, data extraction, IDE debugging support, encryption, hashing, digital signatures, and modular handling of document workflows. It also lists improved language support for Indic, Thai, Khmer, Arabic, and Hebrew, while noting that this language support is a closed-source add-on. That qualification prevents the feature list from being treated as a claim that every capability is in one freely available package.

The old and new code bases should not be assumed to be drop-in equivalents. The repository calls iText 7 a replacement, but the README does not provide a migration guide, API mapping, compatibility table, or rollback procedure. Existing code using iTextSharp assemblies will need an explicit evaluation before replacement. In particular, consumers relying on XML Worker or the PDF/A assembly should verify equivalent requirements in iText 7 rather than assuming their package boundaries or APIs are preserved.

Acquiring iTextSharp and Establishing a First Workflow

The README directs users to the repository's latest release page and also links to BUILDING.md for source builds. It does not provide installation commands, package manager syntax, target framework requirements, or a first-use sample. Because those details are not documented in the README, this guide does not invent a `dotnet add package` command or assembly-loading example.

For an existing application, the documented acquisition path is the latest release linked from the README. Before adding its assemblies or packages, identify whether the application needs only the core library or also needs Xtra, PDF/A, or XML Worker. The README supports those package names, but it does not explain whether a given release should be consumed through NuGet, copied DLLs, or another mechanism in this repository.

A sensible first verification workflow can still be defined without inventing technical steps. Record an existing PDF task, such as core document processing, PDF/A generation, or XML and HTML handling. Map that task to the corresponding assembly named in the README, then run the application's existing regression checks after installing the selected release. For a new deployment, first compare those requirements with the iText 7 documentation because the repository explicitly directs new projects there.

The README does not document a sample application, required environment variables, configuration file, listening port, or command-line interface. iTextSharp is a library, so its immediate output is the behavior of the consuming application rather than a separate service interface. Any installation instruction beyond the documented release and build links would require BUILDING.md or release-specific package documentation that is not present here.

AGPL Implications for .NET PDF Deployments

iTextSharp is licensed under the AGPL, and the repository links its licensing statement to LICENSE.md. The README does more than describe the license as free or open source. It states that purchasing a license is mandatory when commercial activities distribute the software inside a product or deploy it over a network without disclosing the application's source code under the AGPL.

The examples given in the README include offering paid services through an ASP, serving PDFs on the fly from a cloud or web application, and shipping iTextSharp with a closed-source product. Those examples matter to.NET architects because a PDF library may be embedded in an application rather than distributed as a standalone desktop binary. Network use and product distribution are separate deployment facts that need to be reviewed directly, not inferred from the hosting model.

This is not legal advice, and the repository excerpt does not define exceptions, warranty terms, or obligations for every distribution scenario. It does make the project's commercial position explicit and points users to iText sales information. Teams should read LICENSE.md and the applicable commercial terms rather than treating the source-code availability of the repository as a blanket answer for deployment rights.

The custom classification shown in repository metadata adds another verification point. The README calls the project AGPL licensed, while the repository metadata says GitHub cannot classify the custom license category. The direct LICENSE.md and README wording are the relevant project records, but an organization still needs to determine which obligations apply to its exact product and service model.

Limits of iTextSharp Compared with iText 7

The main limitation is not that iTextSharp lacks PDF functionality. It is that the repository explicitly closes the feature roadmap while directing users toward a different .NET product. iTextSharp can remain relevant to code that already uses its C# API and assembly set, but each requested new capability now requires checking whether iText 7 is the correct destination.

iText 7 takes a more modular approach to document workflows. The README also associates it with newer capabilities such as PDF/UA conversion, redaction, SVG, extraction, debugging, encryption, hashing, and digital signatures. Some listed language improvements are explicitly tied to a closed-source add-on, so feature planning must account for package and licensing boundaries. iTextSharp does not gain these capabilities merely because the replacement product offers them.

For a new application, iText 7 is the documented choice. For an existing application, the repository does not state whether migration can be incremental, whether generated PDFs should be byte-for-byte comparable, or whether internal APIs can remain unchanged. Those are concrete checks to perform in a separate migration proof rather than assumptions to build into an adoption decision.

Editorial conclusion

Developers should adopt iTextSharp only when maintaining an existing C# PDF implementation that cannot yet be migrated. New applications and teams planning further feature work should evaluate iText 7 first. Before adoption, verify the required PDF, HTML, PDF/A, XML, signing, or extraction capabilities, review the AGPL obligations for the intended deployment, and test the migration against representative PDFs.

Frequently asked questions

Official sources

1. Issues
2. itext/itextsharp on GitHub
3. Project website
4. README
5. Releases