# iText for .NET review: PDF generation, signing, forms, and standards > iText Core/Community is a C# SDK for creating, inspecting, and modifying PDF files, with separate addons for HTML conversion, OCR, redaction, optimization, and other specialized work. It fits applications that need direct PDF control, but its AGPL licensing and commercial product options require review before adoption. **itext/itext-dotnet** — iText for .NET is the .NET version of the iText library, formerly known as iTextSharp, which it replaces. iText represents the next level of SDKs for developers that want to take advantage of the benefits PDF can bring. Equipped with a better document engine, high and low-level programming capabilities and the ability to create, edit and enha - Repository: https://github.com/itext/itext-dotnet - Website: https://itextpdf.com/products/itext-suite - Stars: 1,942 · Forks: 349 - Language: C# - License: NOASSERTION - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/itext-itext-dotnet ## Why iText for .NET targets direct PDF engineering iText for .NET addresses applications that need to treat PDF as an active document format rather than as a passive export target. The repository describes create, adapt, inspect, and maintain operations in one library, which is useful for software that generates invoices, accepts form input, merges records, adds content to existing files, signs documents, or prepares PDFs for regulated workflows. The intended audience is developers working in C# who need both layout-level and lower-level PDF access. That scope is broader than a report generator. The documented core capabilities include the layout engine, PDF manipulation, digital signing, form handling, PDF/A, PDF/UA, FIPS-compliant cryptography, barcode generation, and SVG support. Topics associated with the repository also include encryption, signature validation, accessibility, archiving, PAdES, XFDF, and SVG. Those labels indicate intended use areas, but the README does not provide a complete compatibility matrix for each feature, format version, or runtime. The project replaces the older iTextSharp name and is presented as the .NET member of a broader iText family. The README also points to a separate Java implementation. C# signing samples are said to be closely related to the Java examples because the APIs are similar. This gives a JVM-based team another route into comparable PDF operations, but it does not make the Java library a drop-in replacement for an existing .NET dependency. Not every PDF requirement belongs to the core package. HTML and CSS conversion, OCR, redaction, international character support, optimization, XFA flattening, and debugging are listed as addons. A team should therefore separate the base PDF engine decision from later product requirements. Adopting the core library does not, by itself, establish that all those workflows are available in the same package. ## How iText's Document and PdfWriter pipeline creates a PDF The README's first example exposes three main layers. `PdfDocument` manages the PDF document, `PdfWriter` writes it to a file path, and `Document` provides the high-level content API. The example creates these objects together with `using`, adds a `Paragraph` containing `Hello World!`, and disposes the document at the end of `Main`. The data flow is straightforward. Content is added through layout objects such as `Paragraph`. The layout engine organizes that content, while the writer materializes the resulting PDF into the selected destination. Lower-level PDF work is also part of the library's stated remit, although the short README example does not demonstrate page-level objects, content streams, existing-file imports, or signature setup. This arrangement separates destination handling from content authoring without requiring applications to assemble every PDF structure themselves. For generated documents, that means a developer can begin with the higher-level API and move closer to PDF primitives only when a requirement demands it. For modifications, the broader feature list indicates that an application can work with existing documents rather than treating creation as the only use case. The README does not document memory behavior, streaming patterns, asynchronous APIs, threading guarantees, or large-document resource limits. It also does not explain the detailed object lifecycle beyond disposal in the example. The safe interpretation is limited to what the sample shows: the application constructs a writer-backed `PdfDocument`, attaches a `Document`, adds layout elements, and disposes the document to finish output. ## NuGet installation and the first generated PDF The installation step adds the core NuGet packages. Both packages should use the same selected version, as shown in the README. ```bash dotnet add package itext --version dotnet add package itext.bouncy-castle-adapter --version ``` After installation, the README's `Hello PDF!` example imports `iText.Kernel.Pdf`, `iText.Layout`, and `iText.Layout.Element`. It creates `helloworld-pdf.pdf` through `PdfWriter`, wraps it in `PdfDocument` and `Document`, then adds one `Paragraph`. Running that program should create a PDF at that exact filename containing the text `Hello World!`. The repository links to an external knowledge base for advanced installation and a separate examples repository for more complete programs. The README warns that GitHub's previewer may display some generated PDFs incorrectly and advises downloading them for inspection. That warning matters for visual verification: a preview rendering problem does not necessarily establish that the generated file is malformed. ## Core capabilities versus separately licensed addons The package boundary is the first practical constraint. The core list covers layout-based creation, manipulation, signatures, forms, PDF/A, PDF/UA, cryptography, barcodes, and SVG. Features with a different cost or implementation boundary are presented as addons. HTML and CSS conversion is linked to a separate `pdfhtml` repository. OCR is linked to `pdfocr`. Redaction is linked to `pdfsweep`. International character support, including Arabic, Chinese, Hebrew, and Thai, is associated with Calligraph. Optimization, XFA flattening, and PDF debugging are also listed outside the core feature group. This design can prevent a large feature set from being treated as one undifferentiated PDF dependency. It also means an architecture based on the core package may need separate components for common publishing pipelines. A web service that converts HTML invoices, for example, cannot be designed as though `itext` alone supplies the documented conversion path. The core list also includes several standards-sensitive areas. PDF/A and PDF/UA have their own repository topics, as do accessibility, digital signatures, PAdES, encryption, and signature validation. The README names these areas but does not publish claim matrices, validator instructions, supported profile versions, or conformance-test results. The terms `PDF/A`, `PDF/UA`, and `FIPS-compliant` should not be treated as proof that a particular deployment satisfies every organizational requirement. Exact conformance criteria and validation procedures are not documented. ## Licensing and maintenance constraints for iText adoption The repository presents several license signals that require direct inspection. The README carries an AGPL badge and links to `LICENSE.md`. The repository metadata identifies the license as custom because GitHub cannot classify it, while the top-level files include `LICENSE.md`, `NOTICE.md`, and `gnu-agpl-v3.0.md`. Based on that layout, license review should involve the exact version's `LICENSE.md` and any relevant notices, rather than relying only on the README badge or NuGet metadata. This is not legal advice. It is an adoption constraint. An application distributed under terms incompatible with the repository's stated AGPL position may need a different arrangement or a commercial license. Teams using iText internally should still review their own distribution and service model rather than assuming all uses are identical. The repository is not archived, the last push was on 2026-10-16, and recent releases include 9.8.0 on 2026-10-01, 9.7.0 on 2026-07-08, and 9.6.0 on 2026-04-01. That record supports recent project activity, but it does not by itself quantify upgrade effort. The README does not publish a migration guide for each minor release, a long-term support schedule, or a compatibility matrix for supported.NET versions. A team moving from iTextSharp or between iText versions should therefore expect some verification work around package versions, API behavior, and output validity. The separate examples repository may help compare behavior, but the README does not claim that sample output is a formal conformance test. ## Java iText and simpler document APIs as decision boundaries The clearest documented alternative platform is iText for Java. The README says iText is also available for Java, describes the APIs as similar, and points to Java signing examples with C# equivalents. A JVM team can therefore evaluate a closely related API and examples rather than translating the product selection entirely to a different vendor. The practical difference is the runtime and ecosystem: the article concerns the .NET SDK, while the alternative requires a Java-based application stack. There is also a design boundary within the project itself. The `Document` and layout-element API is suitable for directly authoring PDFs, but the README sends HTML and CSS conversion to the `pdfhtml` addon. For teams whose source is already HTML, evaluating that conversion boundary is more relevant than assuming a basic layout example covers the application. The wrong choice is likely where the requirement is only to print or export a report from an existing application, with no need to inspect, modify, sign, or merge PDF files afterward. The repository does not provide a feature comparison with lighter report generators, so such a selection cannot be justified from the available text. Conversely, iText fits well when direct PDF manipulation and standards-oriented document functions are explicit application requirements. ## Conclusion iText for .NET is appropriate for .NET teams that need programmatic PDF creation or manipulation and can accept the repository's AGPL licensing terms. It is less suitable for teams requiring a permissively licensed dependency or expecting HTML conversion, OCR, redaction, optimization, and international character support in the base package. Verify the intended package mix, license obligations for the distribution model, target PDF standards, and required addons before integration. The first integration checkpoint should be whether a minimal `Document` and `PdfWriter` program produces the expected file in the target application. ## FAQ ### How do I install iText for .NET? The README says to add `itext` and `itext.bouncy-castle-adapter` through the .NET CLI, using the same desired iText version. It links to the iText installation guidelines for advanced cases. ### Does iText for .NET create PDFs from C#? Yes. The README example creates `PdfWriter` and `PdfDocument` objects, attaches a `Document`, and adds a C# `Paragraph` to produce `helloworld-pdf.pdf`. ### Does the core iText package include HTML-to-PDF conversion and OCR? No. The README lists XML, HTML and CSS conversion under `pdfhtml` and OCR under `pdfocr`. These are addons rather than entries in the documented core feature list. ### What replaced iTextSharp in this repository? The repository describes iText Core/Community, previously known as iTextSharp, as its .NET implementation. The README presents it as the replacement for the older name. ### Can iText for .NET handle PDF forms, signatures, PDF/A, and PDF/UA? The core feature list names PDF digital signing, form creation and manipulation, PDF/A documents, and PDF/UA documents. It does not provide detailed conformance matrices or validator instructions in the README. ## Sources - [Issues](https://github.com/itext/itext-dotnet/issues) - [itext/itext-dotnet on GitHub](https://github.com/itext/itext-dotnet) - [Project website](https://itextpdf.com/products/itext-suite) - [README](https://github.com/itext/itext-dotnet/blob/develop/README.md) - [Releases](https://github.com/itext/itext-dotnet/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/itext-itext-dotnet