ServerTextControl

TX Text Control .NET Server and IronPDF both generate PDFs in C#, but they take fundamentally different approaches, and this comparison helps you understand that difference.

IronPDF is built around an embedded Chromium browser engine. Pass it HTML and CSS, and Chromium's print engine produces the PDF. If your content is already HTML, getting started is straightforward.

TX Text Control takes a different direction entirely. It's a document processing SDK where PDF is one output format among many. A few things that make TX Text Control distinct:

WYSIWYG document editing : A browser-based editor lets users preview and edit documents visually before generating the final PDF, no additional tool required. Page-oriented layout : Documents are built on a native pagination model, featuring section breaks, headers and footers, and page numbering. Accessibility compliance : PDF/UA and PDF/A-3a are supported, authored through the document model. A validation library is also available, currently in preview. Complete document lifecycle : templates, mail merge, track changes, electronic signatures, and PDF output are all part of a single SDK. Beyond PDF generation, TX Text Control also handles multi-format conversion, forms, annotations, and document security .

In practice, document requirements rarely stay static. What starts as "we need to generate PDFs" tends to grow: editable templates, user-facing document review, accessible output for compliance, and audit trails. Some teams discover this during their initial evaluation. Others run into it after they've already shipped with a PDF library and realize they need more.

This article is written for both scenarios: whether you're choosing your first .NET PDF library or considering adding a comprehensive document pipeline alongside or in place of IronPDF.

PDF Generation: Native Document Engine vs. Chromium Browser The most fundamental difference between these two libraries is how they produce PDFs.

IronPDF embeds a full Chromium browser engine. Calling RenderHtmlAsPdf() launches a headless Chrome process, loads your HTML, CSS and JavaScript, and prints to PDF. Since HTML has no native concept of physical pages, page boundaries and print behavior are determined by how Chromium interprets CSS print rules, not by explicit document structure.

TX Text Control works with its own internal binary format and renders PDF directly from it without an HTML intermediate step. It uses a page-based document model similar to that of Word. TX Text Control automatically handles pagination during rendering. This means that features such as widow/orphan control, repeating table headers, per-section headers and footers, page numbering, and font embedding are all native to the engine.

Where IronPDF is strong : content that's already HTML, such as web pages, Razor views, and styled reports. Chromium renders complex CSS (grid, flexbox, media queries) with high fidelity.

Where TX Text Control .NET Server is strong : documents that need to behave like documents with predictable page breaks, accurate print previews, page-based editing, and consistent output regardless of rendering environment.

Seeing the Difference: A Multi-Section Compliance Report To illustrate the architectural difference, we generated the same two-section compliance report sample with both libraries. The document includes a "Draft" cover page with its own header and a "Final Report" section with a different header. It also contains a 50-row data table with a repeating header row and page numbering that restarts on Section 2.

TX Text Control .NET Server: Programmatic Approach TX Text Control builds the report as a single document with native sections. Each feature, such as per-section headers, repeating table headers, and page numbering restart, is a direct property on the document model:

using TXTextControl;

using (ServerTextControl tx = new ServerTextControl()) { tx.Create();

// Section 1: "Draft" header tx.Sections[1].HeadersAndFooters.Add(HeaderFooterType.Header); HeaderFooter header1 = tx.Sections[1].HeadersAndFooters .GetItem(HeaderFooterType.Header); header1.Selection.Text = "DRAFT — Internal Review";

// ... Section 1 body content ...

// Section 2: different header, page numbering restarts tx.Sections.Add(SectionBreakKind.BeginAtNewPage); tx.Sections[2].Format.RestartPageNumbering = true;

tx.Sections[2].HeadersAndFooters.Add(HeaderFooterType.Header); HeaderFooter header2 = tx.Sections[2].HeadersAndFooters .GetItem(HeaderFooterType.Header); header2.ConnectedToPrevious = false; header2.Selection.Start = 0; header2.Selection.Length = -1; header2.Selection.Text = "AB Technologies GmbH — Final Compliance Report";

// Table with repeating header row tx.Tables.Add(50, 3, 10); Table table = tx.Tables.GetItem(10); table.Rows.GetItem(1).IsHeader = true; // repeats on every page

// ... populate table data ...

// One document, one save tx.Save("ComplianceReport.pdf", StreamType.AdobePDFA); } The code produces a single document with a single tx.Save() call.

TX Text Control .NET Server: Template Approach But there's a simpler path. A business user can design the entire report with sections, headers, footers, table styling, page numbering, and more, directly in the TX Text Control editor . The SDK then uses the template to automatically generate the PDF.

This sample template is designed in a precompiled demo application, TX Text Control Words:

using TXTextControl;

using (ServerTextControl tx = new ServerTextControl()) { tx.Create(); tx.Load("compliance-report.docx", StreamType.WordprocessingML); tx.Save("ComplianceReport.pdf", StreamType.AdobePDFA); } This is the WYSIWYG principle in practice. Template files are with merge fields, repeating blocks, and conditional logic. Business users own the templates by creating and editing them in the document editor without involving the development team. Template changes don't require code deployments. The business team owns the layout; the development team owns the data pipeline.

IronPDF: Programmatic Approach (the only option) Achieving the same result in IronPDF requires rendering each section as a separate PDF, then merging them because HTML has no concept of document sections:

using IronPdf;

// Section 1: separate renderer with "Draft" header var renderer1 = new ChromePdfRenderer(); renderer1.RenderingOptions.HtmlHeader = new HtmlHeaderFooter { HtmlFragment = " DRAFT — Internal Review " };

string section1Html = @" ";

var pdf1 = renderer1.RenderHtmlAsPdf(section1Html);

// Section 2: separate renderer with different header var renderer2 = new ChromePdfRenderer(); renderer2.RenderingOptions.CssMediaType = PdfCssMediaType.Print; // required for repeating table header renderer2.RenderingOptions.HtmlHeader = new HtmlHeaderFooter { HtmlFragment = " AB Technologies GmbH — Final Compliance Report " };

string section2Html = $@" ";

var pdf2 = renderer2.RenderHtmlAsPdf(section2Html);

// Must merge separate PDFs — no single-document section model var merged = PdfDocument.Merge(pdf1, pdf2); merged.SaveAs("ComplianceReport.pdf"); Producing this PDF requires two renderer instances, two HTML strings, and a merge call. Note that CssMediaType.Print must be set explicitly, and without it, table headers don't repeat across pages. Layout lives in HTML and CSS without a template engine. Every change to the document structure means a developer modifies code and redeploys.

The Structural Difference TX Text Control IronPDF Document model Single document with native sections Separate HTML renders merged into one PDF Per-section headers ConnectedToPrevious = false via code or defined in editor Requires separate renderers + merge Repeating table headers IsHeader = true or set visually in editor + CssMediaType.Print (not default) Page numbering restart RestartPageNumbering = true or configured in template Implicit from separate renders Layout ownership Developer or Business User Developer only Template changes Edit in rich text editor, or code change Code change + redeploy WYSIWYG preview Editor shows exact PDF output No native editor preview Mail merge Merge fields in code or template C# string interpolation PDF Accessibility and Compliance Both TX Text Control and IronPDF support PDF/UA, so this section focuses on how TX Text Control handles accessibility from authoring through validation.

TX Text Control .NET Server 34.0 introduced built-in PDF/UA compliance and tagged PDF generation. Headings, alt text, table headers, and reading order are authored through the document model and carry directly into the exported PDF's tag structure. Combined with the WYSIWYG editor and page-oriented layout, the document you design is the document your users receive structurally, visually, and in terms of accessibility.

Here's an example that creates a tagged, accessible document and exports it as PDF/A-3a with PDF/UA-compatible structure:

using TXTextControl;

using (ServerTextControl tx = new ServerTextControl()) { tx.Create();

// Semantic heading tx.Selection.Bold = true; tx.Selection.FontSize = 480; tx.Selection.ParagraphFormat.StructureLevel = 1; tx.Selection.Text = "Accessibility Compliance Report\r\n"; tx.Selection.Bold = false; tx.Selection.FontSize = 240; tx.Selection.ParagraphFormat.StructureLevel = 0; tx.Selection.Text = "This report documents WCAG conformance.\r\n\r\n";

// Image with alt text TXTextControl.Image chart = new TXTextControl.Image("chart.png", 4); chart.DescriptiveText = "Bar chart showing compliance scores: Engineering 96%, Legal 91%"; tx.Images.Add(chart, -1); tx.Selection.Text = "\r\n";

// Tagged table with header row tx.Tables.Add(3, 2, 10); Table table = tx.Tables.GetItem(10); table.Rows.GetItem(1).IsHeader = true; table.Cells.GetItem(1, 1).Text = "Department"; table.Cells.GetItem(1, 2).Text = "Score"; table.Cells.GetItem(2, 1).Text = "Engineering"; table.Cells.GetItem(2, 2).Text = "96%"; table.Cells.GetItem(3, 1).Text = "Legal"; table.Cells.GetItem(3, 2).Text = "91%";

// Export as PDF/A-3a with document title (required for PDF/UA) TXTextControl.SaveSettings saveSettings = new TXTextControl.SaveSettings(); saveSettings.DocumentTitle = "Accessibility Compliance Report";

tx.Save("ComplianceReport.pdf", StreamType.AdobePDFA, saveSettings); } The PDF output was validated using PAC (PDF Accessibility Checker) , a tool that evaluates PDF files against the PDF/UA standard:

TX Text Control also includes a built-in PDF/UA validation library ( TXTextControl.PDF.Validation , currently available as a preview) that lets developers validate compliance and verify digital signatures directly in C#. The library reports where compliance gaps exist, such as missing alternative text, incorrect structural elements, or missing metadata. Results can be exported as JSON for programmatic access.

Learn More

This article shows how to use TX Text Control together with the OpenAI API to automatically add descriptive texts (alt text and labels) to images, links, and tables in a DOCX. The resulting document is then exported as a PDF/UA compliant PDF document.

Automating PDF/UA Accessibility with AI: Describing DOCX Documents Using TX Text Control and LLMs

Capabilities: What Each Library Can and Can't Do Beyond PDF generation, enterprise teams need to evaluate what else each library handles. This section summarizes the key capability differences.

Document Editing TX Text Control .NET Server includes a browser-based WYSIWYG document editor compatible with Microsoft Word, embeddable in ASP.NET Core, Angular, React, or Blazor applications. End users can create, review, edit, and approve documents before PDF output, with track changes, comments, and document protection built in.

IronPDF has no editing UI . If your workflow requires non-developers to interact with documents before they become PDFs, this is a deciding factor.

Refer to this article for practical examples

Enterprise JavaScript rich text editors outperform open source and basic alternatives for document automation. This guide covers five document workflows with TX Text Control: contract generation via MailMerge, multi-party review with track changes, interactive form processing, role-based security, and large document management.

5 Document Workflows You Can Automate With JavaScript Rich Text Editor

Electronic Signatures Both libraries can apply digital signatures with X.509 certificates, stamp visual signature images, and add interactive signature fields programmatically. TX Text Control adds the ability for end users to visually place signature fields in the browser editor without writing code, and signature fields can be embedded directly in DOCX templates as part of the document lifecycle. For teams where non-developers need to define where signatures go (legal teams, compliance officers), that distinction matters.

Learn More

PDF documents are widely used for sharing information because of their fixed layout and cross-platform compatibility. However, it is crucial to ensure the integrity and authenticity of these documents, especially when sensitive information is involved. Digitally signing PDFs is an effective way to prevent tampering and verify the document's source.

Why Digitally Signing your PDFs is the Only Reliable Way to Prevent Tampering

Learn More

These articles cover the capability comparison in more detail:

Document SDK Comparison: Complete Document Processing vs. PDF SDK How To Choose the Right C# PDF Generation Library: Developer Checklist

Total Cost of Ownership: Single SDK vs Multiple Products IronPDF Lite starts at $799 per developer (1 project, 1 location, perpetual license). That covers PDF generation. For enterprise teams, a more relevant question is what their workflow requires beyond PDF generation. Additional capabilities require separate products or integrations, each with its own licensing costs.

Capability TX Text Control IronPDF Ecosystem PDF generation ✅ Included IronPDF DOCX creation/manipulation ✅ Included IronWord (separate license) Document editing (browser) ✅ Included Not available Mail merge templates ✅ Included Not available Electronic signatures ✅ Included IronPDF PDF/UA compliance ✅ Included IronPDF Barcode generation ✅ Included IronBarcode (separate license) TX Text Control .NET Server uses a per-developer perpetual license model. A single license covers the complete document workflow: authoring, WYSIWYG editing, mail merge, electronic signatures, and PDF/A and PDF/UA output. Deployment to production servers requires runtime licenses; the base tiers already include 2 production licenses, with unlimited deployment available at higher tiers. Licenses include one year of updates and support. See full pricing here .

With IronPDF, the PDF workflow itself is covered, but the surrounding pipeline isn't. Template-driven generation, document editing before PDF output, and advanced signing require either custom development or additional products. Iron Software offers the Iron Suite bundle covering all 10 products, but that shifts the conversation from a single PDF library to a multi-product platform with the licensing and maintenance overhead that comes with it. However, enterprise licensing requires contacting their sales team.

IronPDF pricing referenced from ironpdf.com/licensing as of April 2026. Pricing may have changed; verify current rates before making procurement decisions.

Feature-by-Feature Comparison Evaluation Area TX Text Control IronPDF Architecture Native document model, WYSIWYG Chromium-based HTML rendering DOCX templates & mail merge Business users can edit Code only Browser-based document editor MS Word-compatible Not available Track changes & comments Supported Not supported Form fields PDF AcroForms compatible Fill & flatten Electronic signatures Code + visual editor placement Code-only placement PDF/UA accessibility Authored tag structure Via dedicated methods PDF/A archival Supported Supported HTML-to-PDF rendering Supported Core strength, high CSS fidelity Chromium dependency Not required Required Licensing Single SDK, per-developer and production server Per-developer + separate products for additional capabilities Cross platform Supported Supported Conclusion IronPDF handles PDF generation and manipulation, with HTML as the input format. TX Text Control is a document processing library that accepts a wide range of input formats, including DOCX, RTF, HTML, and PDF, and outputs in multiple formats. PDF is one of its primary delivery formats. This distinction shapes everything in this comparison.

If your requirement is purely HTML-to-PDF conversion without editing, templating, or document lifecycle features, a Chromium-based renderer may be sufficient.

Choose TX Text Control .NET Server if you need a complete document workflow, such as authoring, editing, mail merge, electronic signatures, accessibility compliance, and PDF output under a single SDK. It fits in legal, compliance, and contract workflows where documents go through multiple hands before becoming a final PDF.

The right choice depends on where your requirements sit today and where they're likely to go.

If you're already using IronPDF and considering a migration to TX Text Control, contact our sales team to discuss your requirements.

Frequently Asked Questions What is the main difference between TX Text Control .NET Server and IronPDF? TX Text Control is a document processing SDK with a native page-oriented document model, a WYSIWYG editor, and PDF as one output format. IronPDF is an HTML-to-PDF library that uses an embedded Chromium engine to render web content as PDF. TX Text Control covers the full document lifecycle: editing, templates, compliance, and signatures. IronPDF focuses on PDF generation from HTML.

Which library is better for PDF/UA accessibility compliance? Both support PDF/UA. TX Text Control generates the tag structure directly from its document model. Headings, alt text, and table headers are authored through the API and carry through to PDF output. IronPDF offers dedicated PDF/UA export methods that process HTML into tagged PDFs. Both can produce compliant output.

Can TX Text Control .NET Server convert HTML to PDF? Yes. TX Text Control .NET Server can import HTML and export it as PDF, and goes further by supporting DOCX, RTF, and other formats as input, with page-oriented layout and section control in the output.

How difficult is it to migrate from IronPDF to TX Text Control .NET Server? It depends on how deeply IronPDF is integrated into your workflow. If you're using IronPDF for HTML-to-PDF rendering, the migration involves replacing rendering calls with TX Text Control's document API. If you're also using other Iron Software products, TX Text Control can consolidate those into a single SDK. Contact our sales team to discuss your specific setup.

Is TX Text Control .NET Server only for enterprise, or can smaller teams use it too? TX Text Control is used across team sizes. The per-developer and production license means smaller teams aren't paying per document. If your workflow involves document editing, templating, or compliance, the single SDK reduces the number of moving parts regardless of team size.

Getting Started TX Text Control .NET Server provides a 30-day free trial with full enterprise features and no limitations. For step-by-step setup in ASP.NET Core, Angular, React, or Blazor, see the getting started guides.

TX Text Control .NET Server

DS Server

Server & Web

Windows Forms

WPF

ActiveX

Core Technologies

Blog

Core Technologies

Blog

Authors

Latest Posts

Support Resources

Documentation

Support

Getting Started

Other Resources

About Us

Industry events

Company

Contact

Newsletter

Legal

Sign in

Create account

Text Control Account

ServerTextControl

Post tagged with ServerTextControl in 2026

Server & Web

Windows Forms

WPF

ActiveX

Core Technologies

​

Latest Posts

​

Support

Getting Started

​

Other Resources

Company

Contact

Newsletter

Legal

Text Control Account

​

​

ServerTextControl

Post tagged with ServerTextControl in 2026 ​

April 2026

Post tagged with ServerTextControl in 2026