A software team chose ComPDFKit to build a document management system. The vendor pitch emphasized "comprehensive PDF features" and showed a polished demo with annotations, form filling, and digital signatures working smoothly. Three months into development, marketing requested invoice generation from HTML email templates. The team discovered ComPDFKit's core SDK doesn't include HTML-to-PDF conversion—that requires purchasing the separate HtmlConverter product with its own license. The "comprehensive" toolkit turned out to be a multi-product suite where each capability required evaluation of which component to license. ComPDFKit is a mature PDF SDK with strong viewer and editor features for building PDF applications. IronPDF is a unified library focused on HTML-to-PDF conversion and programmatic PDF manipulation. This comparison helps teams understand when UI-focused SDKs serve document viewer requirements versus when server-side HTML rendering drives the architecture. IronPDF is a .NET library for HTML-to-PDF conversion and PDF manipulation. Install via Install-Package IronPdf—no separate products for HTML rendering versus PDF editing. The ChromePdfRenderer converts HTML using embedded Chromium, while PdfDocument handles merging, splitting, forms, and security. One library, one license, no UI components. For server-side teams, this means generating PDFs from web content, API responses, or data templates without building viewer interfaces. HTML-to-PDF and PDF manipulation work together in the same namespace. ComPDFKit is actively maintained by PDF Technologies Inc. as a commercial multi-platform SDK. Multiple .NET packages: ComPDFKit v3.0.0 (June 2025), ComPDFKit.NetCore v2.0.0 (May 2024), ComPDFKit.NetFramework v2.2.0 (December 2024). The SDK targets PDF viewer/editor applications with desktop UI focus (WPF SDK for Windows, UWP SDK). Also supports iOS, Android, Web, React Native, Flutter. Product suite includes: PDF SDK (viewing/editing), Conversion SDK (Office to PDF), HtmlConverter SDK (HTML to PDF—separate product). Each product requires separate licensing and integration. ComPDFKit's core PDF SDK is designed for building PDF viewer/editor UI applications. It excels at displaying PDFs, adding annotations, form filling, and digital signatures in desktop apps. However, HTML-to-PDF conversion requires the separate HtmlConverter product with additional licensing. The architectural focus on UI components means teams building server-side PDF generation (invoices from HTML, reports from templates) face integration complexity. HtmlConverter SDK is a separate NuGet package (ceTe.DynamicPDF.HtmlConverter.NET) that must be licensed and integrated alongside the core SDK. .NET 9/10 support: verify with vendor. NuGet packages list .NET 5-8 compatibility. Native library dependencies (ComPDFKitNative.so on Linux) require deployment alongside .NET assemblies. Multi-product complexity: Teams needing both PDF manipulation and HTML rendering must license and integrate multiple ComPDFKit products. Core SDK + HtmlConverter = two separate purchases, two license keys, two sets of documentation. This mirrors patterns seen in other multi-product PDF suites. UI-first architecture: ComPDFKit SDK includes viewer controls (CPDFViewer) and editor components designed for WPF/UWP desktop applications. Server-side API applications don't need UI controls but must still integrate the SDK's UI-oriented architecture. Teams report (in community forums) navigating around viewer components when only programmatic PDF operations are needed. License key management: Every ComPDFKit product requires license key verification. Keys are project-specific. Production deployments require managing license files. Trial licenses available but must be obtained through vendor contact. Commercial support from PDF Technologies Inc. Documentation available per product (PDF SDK docs, Conversion SDK docs, HtmlConverter docs separately). Community license offered for startups/individual developers—verify eligibility and limitations with vendor. Support includes 1v1 technical assistance (per marketing materials). Response times and SLA terms vary by license tier. GitHub repository provides code samples but core SDK is closed-source commercial product. The multi-product strategy creates decision overhead: which SDK for which task, how products integrate, separate licensing per component, version compatibility between products. For teams needing server-side HTML-to-PDF plus PDF manipulation, this means licensing and configuring at least two products (HtmlConverter + PDF SDK) versus a single integrated library. Desktop UI focus creates deployment surface area for server applications. Viewer controls, annotation toolbars, and UI resources ship with SDK even when building headless API services. Teams must configure which components to load and which to ignore. Aspect ComPDFKit (SDK + HtmlConverter) IronPDF Current Status Active (v3.0.0, Jun 2025) Active (regular updates) HTML Support HtmlConverter (separate product) Built-in Chromium Rendering Quality Verify with vendor Chromium (pixel-perfect) Installation Multi-package + license keys Single NuGet package Support Commercial (PDF Technologies) Commercial (Iron Software) Future Viability Active (multi-platform focus) Active using ComPDFKit.PDFDocument; using ComPDFKit.PDFAnnotation; using System; using System.IO; public class ComPdfKitAnnotator { public byte[] AddAnnotationsAndFillForm( string pdfPath, Dictionary formData) { // ComPDFKit SDK emphasizes viewer/editor UI workflows // API designed for desktop applications with UI controls // Step 1: Initialize license (required for all operations) // License verification necessary before SDK usage // Verify exact API in ComPDFKit documentation // Step 2: Load PDF document // CPDFDocument class represents PDF file CPDFDocument document = CPDFDocument.InitWithFilePath(pdfPath); if (document == null) { throw new Exception("Failed to load PDF document"); } try { // Step 3: Add text annotation (viewer-style API) // Annotations designed for interactive viewing var page = document.PageAtIndex(0); // Create annotation (API patterns from SDK samples) // Exact method names verify in ComPDFKit documentation // Typical pattern: create annotation, set properties, add to page // Step 4: Fill form fields // Form API requires iterating widgets // Field identification by name foreach (var fieldName in formData.Keys) { // Field filling pattern (verify API in docs) // ComPDFKit uses widget-based form model // Must locate field by name, get widget, set value } // Step 5: Save modified document string outputPath = Path.GetTempFileName() + ".pdf"; bool saved = document.WriteToFilePath(outputPath); if (!saved) { throw new Exception("Failed to save PDF"); } // Step 6: Read file bytes for return byte[] pdfBytes = File.ReadAllBytes(outputPath); File.Delete(outputPath); return pdfBytes; } finally { // Step 7: Release document resources document.Release(); } } } // Usage requires license key configuration // Contact ComPDFKit for license: https://www.compdf.com/contact-us var annotator = new ComPdfKitAnnotator(); var formData = new Dictionary { { "CustomerName", "Acme Corp" }, { "InvoiceNumber", "INV-2026-001" } }; byte[] pdf = annotator.AddAnnotationsAndFillForm("template.pdf", formData); Technical limitations: License key required: All SDK operations require valid license verification File-based operations: Primary APIs work with file paths, not streams UI-oriented architecture: Designed for viewer applications, not headless servers Manual resource management: Explicit Release() calls required Multi-product for complete workflow: HTML conversion requires separate HtmlConverter Desktop SDK deployment: Viewer controls ship with SDK even for server use using IronPdf; using System.Collections.Generic; using System.Threading.Tasks; public class IronPdfAnnotator { public async Task AddAnnotationsAndFillFormAsync( string pdfPath, Dictionary formData) { // Load existing PDF using var pdf = PdfDocument.FromFile(pdfPath); // Fill form fields var form = pdf.Form; foreach (var field in formData) { if (form.Fields.ContainsKey(field.Key)) { form.Fields[field.Key].Value = field.Value; } } // Add text annotation (programmatic, not UI-based) pdf.AddTextAnnotation("Review required", 0, 100, 100); return pdf.BinaryData; } } // Usage - no license key in code var annotator = new IronPdfAnnotator(); var formData = new Dictionary { { "CustomerName", "Acme Corp" }, { "InvoiceNumber", "INV-2026-001" } }; byte[] pdf = await annotator.AddAnnotationsAndFillFormAsync("template.pdf", formData); IronPDF uses server-focused APIs: stream-based operations, automatic disposal, no UI controls. See PDF generation settings. // NOTE: HTML-to-PDF requires ComPDFKit HtmlConverter // This is a SEPARATE PRODUCT from the core ComPDFKit SDK // Requires separate licensing and NuGet package // Package: ceTe.DynamicPDF.HtmlConverter.NET (verify name with vendor) using System; using System.IO; public class ComPdfKitHtmlConverter { public byte[] ConvertHtmlToPdf(string html) { // HtmlConverter is separate ComPDFKit product // Separate purchase, separate license key // Installation steps: // 1. Contact ComPDFKit for HtmlConverter license // 2. Install HtmlConverter NuGet package // 3. Configure license key for HtmlConverter // 4. Integrate HtmlConverter API (different from PDF SDK API) // Exact API pattern: verify in HtmlConverter documentation // Typical workflow (conceptual): // - Initialize HtmlConverter with license // - Configure conversion options // - Execute conversion // - Retrieve PDF bytes throw new NotImplementedException( "ComPDFKit HtmlConverter is a separate product. " + "Requires separate license and installation. " + "Contact ComPDFKit for HtmlConverter licensing: " + "https://www.compdf.com/contact-us"); } } // MULTI-PRODUCT ARCHITECTURE IMPLICATIONS: // - Core ComPDFKit SDK: PDF viewing, editing, annotations → License A // - ComPDFKit Conversion SDK: Office to PDF → License B // - ComPDFKit HtmlConverter: HTML to PDF → License C // Total licensing: negotiate with vendor for multi-product needs // Integration: configure each product separately // Deployment: multiple NuGet packages, multiple license keys Multi-product challenges: Separate HtmlConverter purchase: Not included in base ComPDFKit SDK Additional license negotiation: HtmlConverter licensed separately Multiple API integrations: Learn PDF SDK API + HtmlConverter API Version coordination: Ensure SDK and HtmlConverter versions compatible Procurement overhead: Multiple vendor discussions for complete workflow Deployment complexity: Manage multiple products in production using IronPdf; using System.Threading.Tasks; public class IronPdfHtmlConverter { public async Task ConvertHtmlToPdfAsync(string html) { var renderer = new ChromePdfRenderer(); using var pdf = await renderer.RenderHtmlAsPdfAsync(html); return pdf.BinaryData; } } // Usage var converter = new IronPdfHtmlConverter(); string html = @"

Invoice #2026-001

Customer: Acme Corporation

Item	Amount
Services	$1,500.00
License	$2,000.00

Total: $3,500.00

"; byte[] pdf = await converter.ConvertHtmlToPdfAsync(html); // HTML-to-PDF included in base IronPDF package // No separate HtmlConverter product needed IronPDF includes Chromium-based HTML rendering in base package. No additional products to license. See HTML string to PDF guide. // ComPDFKit SDK architecture focuses on UI viewer controls // Designed for WPF, UWP desktop applications using ComPDFKit.Controls.PDFControl; using System.Windows.Controls; public class ComPdfKitViewerIntegration { public void IntegrateViewerInDesktopApp(Grid container) { // ComPDFKit provides CPDFViewer control for WPF apps // Rich UI features: toolbar, annotation tools, form filling var pdfViewer = new CPDFViewer(); // Configure viewer properties // UI customization: show/hide toolbars, annotation palette // Event handlers for user interactions container.Children.Add(pdfViewer); // Load PDF into viewer // Viewer displays PDF with interactive controls // SERVER-SIDE CONSIDERATION: // API services don't need viewer controls // But SDK includes UI components in deployment // Teams must work around viewer-focused architecture // when building headless PDF processing } } // ARCHITECTURAL MISMATCH FOR SERVER SCENARIOS: // - Server APIs generate PDFs programmatically (no UI) // - ComPDFKit SDK ships with viewer controls and UI resources // - WPF/UWP dependencies in SDK even for console apps // - Need to isolate programmatic APIs from UI components // - Deployment includes viewer assets unused in server context UI architecture considerations: Viewer controls included: SDK ships with CPDFViewer for desktop apps WPF/UWP dependencies: Desktop UI framework requirements Server deployment overhead: UI components deployed to servers unnecessarily API isolation needed: Separate viewer features from programmatic APIs Desktop licensing model: SDK priced for desktop app integration Documentation emphasis: Heavy focus on viewer customization vs. server APIs using IronPdf; using System.Threading.Tasks; public class IronPdfProgrammaticApi { public async Task GenerateInvoiceAsync(InvoiceData data) { // No UI components - pure programmatic API // Designed for server-side PDF generation string html = BuildInvoiceHtml(data); var renderer = new ChromePdfRenderer(); using var pdf = await renderer.RenderHtmlAsPdfAsync(html); // Add watermark programmatically pdf.ApplyWatermark("

DRAFT

"); return pdf.BinaryData; } private string BuildInvoiceHtml(InvoiceData data) { return $@"

Invoice #{data.InvoiceNumber}

Total: ${data.Total}

"; } } // SERVER-OPTIMIZED: // - No viewer controls // - No UI framework dependencies // - Headless Chromium rendering // - Stream-based operations // - Async/await throughout // - Standard .NET deployment IronPDF has no UI components. Headless processing for APIs and background jobs. See ChromePdfRenderer API. ComPDFKit Concept IronPDF Equivalent CPDFDocument class PdfDocument class InitWithFilePath() PdfDocument.FromFile() PageAtIndex() pdf.Pages[index] WriteToFilePath() pdf.SaveAs() or pdf.BinaryData Release() Dispose() (automatic with using) License key verification License in code or config CPDFViewer control N/A (no UI components) HtmlConverter (separate) ChromePdfRenderer (built-in) Conversion SDK (separate) Built-in conversion Multi-product suite Single library WPF/UWP focus Server-first architecture Desktop licensing model Server/desktop licensing Feature Category ComPDFKit IronPDF Status Maintenance Active (v3.0.0, Jun 2025) Active Architecture Multi-product suite Unified library Primary Focus PDF viewer/editor UI Server-side PDF generation Support Commercial Support PDF Technologies Inc. Iron Software Documentation Per-product docs Unified documentation Community License Startups/individuals Trial available Content Creation HTML to PDF HtmlConverter (separate) Built-in Chromium PDF Viewer UI CPDFViewer control (WPF/UWP) N/A (headless only) Annotations UI-focused annotation tools Programmatic annotations Form Filling Interactive + programmatic Programmatic PDF Operations Create PDFs SDK + Viewer Yes Merge PDFs SDK Yes Split PDFs SDK Yes Extract Text SDK Yes Digital Signatures SDK Yes Watermarks SDK Yes Encryption SDK Yes Development .NET Framework .NET Framework 4.6.2+ .NET Core / .NET 5+ .NET Core 2.1+, .NET 5-8 3.1+ / 5-10 Installation Multiple NuGet packages Single NuGet package License Keys Required per product License in code/config API Style UI-oriented + programmatic Server-optimized UI Components Included (WPF/UWP) None ComPDFKit: # Core PDF SDK Install-Package ComPDFKit.NetCore # or for .NET Framework: Install-Package ComPDFKit.NetFramework # For HTML-to-PDF, also need HtmlConverter: # 1. Contact ComPDFKit for HtmlConverter license # 2. Install HtmlConverter package (verify package name with vendor) # 3. Configure license keys for each product # For Office conversion: # Install-Package ComPDFKit.Conversion.SDK (verify with vendor) using ComPDFKit.PDFDocument; // License verification required // Contact: https://www.compdf.com/contact-us CPDFDocument document = CPDFDocument.InitWithFilePath("file.pdf"); // ... operations ... document.Release(); IronPDF: Install-Package IronPdf # All features included: HTML-to-PDF, manipulation, forms using IronPdf; var renderer = new ChromePdfRenderer(); using var pdf = renderer.RenderHtmlAsPdf("

Hello

"); pdf.SaveAs("output.pdf"); ComPDFKit is a mature multi-platform SDK with 20+ years backing (ceTe Software/PDF Technologies Inc.) serving enterprises that build PDF viewer and editor applications. The SDK excels at desktop PDF applications with rich UI controls, annotation toolbars, and interactive form filling in WPF and UWP environments. For teams building PDF readers, document editors, or annotation tools into Windows desktop apps, ComPDFKit provides comprehensive viewer components. However, the multi-product architecture creates integration complexity for server-side scenarios: HTML-to-PDF requires the separate HtmlConverter product with additional licensing, Office conversion requires the Conversion SDK, and complete workflows span multiple products with separate license keys and documentation. The UI-focused architecture means server applications deploy viewer controls and desktop dependencies they don't use. The story that opened this comparison—discovering HTML conversion requires a separate product after licensing the core SDK—reflects a common pattern with multi-product PDF suites. Teams building server-side PDF generation face procurement overhead coordinating multiple licenses and integration complexity managing multiple SDKs. Migration from ComPDFKit to IronPDF makes sense when: Primary need is server-side HTML-to-PDF generation (not desktop PDF viewing) Team prefers unified library over multi-product suite HtmlConverter licensing adds complexity or cost to ComPDFKit deployment Desktop UI components unnecessary for headless API services Simplified procurement (single vendor, single license) reduces administrative overhead Chromium-based rendering preferred over vendor-specific HTML engine ComPDFKit serves teams building PDF viewer applications into desktop software. IronPDF serves teams generating PDFs from HTML in server applications. Evaluate based on whether you're building a PDF editor UI or processing PDFs headlessly—the architectures optimize for different use cases. If you're using ComPDFKit, did you need the HtmlConverter or Conversion SDK? How did multi-product integration work for your team? Related Resources: IronPDF HTML Conversion Guide Pixel-Perfect PDF Rendering

Menu

#Compdfkit

ComPDFKit vs IronPDF: a technical breakdown for 2026