Spire.PDF's License Key Trial vs IronPDF's Setup

Download Spire.PDF, wire up the first HTML-to-PDF conversion, and the PDF that comes back has a red evaluation warning stamped across it. That's not a bug. It's the default state of every e-iceblue trial until a license key gets applied, and the path from that first download to a clean output file runs through more steps than the quickstart page implies.

Full disclosure. We build IronPDF at Iron Software, and this read looks at where Spire.PDF's evaluation watermark and per-evaluation license key request cost a team, and where IronPDF renders the same page from one bundled package.

We went through e-iceblue's own documentation, its GitHub repositories, its support forum, and its published licensing terms for this one, not an older comparison's assumptions about where the product stands in August 2026. If you want the broader picture of choosing a .NET PDF library before narrowing to Spire.PDF's specific approach, or just the general pattern for rendering HTML to PDF in C#, both live on Iron Software's site.

What does the trial gate?

Every e-iceblue product runs in evaluation mode until a license is applied, and clearing that gate happens in code rather than through a settings screen in the installer.

// Install-Package Spire.PDF
using Spire.Pdf.License;

LicenseProvider.SetLicenseKey("YOUR-TEMPORARY-KEY");
LicenseProvider.LoadLicense();

That call has to run before the first render, and e-iceblue retired the older shared Spire.License.LicenseProvider namespace that still turns up in search results and older tutorials in favor of the product-specific one shown above. Getting a working key during evaluation means emailing support or posting on e-iceblue's own forum for a temporary license, usually valid for one month, or filing a separate enterprise request for a longer window if the team qualifies for one. It's a step a developer has to discover before the first clean PDF comes out, and the quickstart doesn't mention it.

The license that finally clears the watermark has its own ceiling, too. Developer Small Business licenses one developer at one location for internal use, and the terms state directly that it doesn't cover a public-facing website, a Docker container, or any SaaS, PaaS, or IaaS deployment. Shipping past that requires stepping up to the OEM tier before the application can go live, a second licensing conversation most teams don't plan for until the deployment plan is already set.

What does Spire.PDF get right?

Spire.PDF's Chrome-based converter is a real browser under the hood, not an approximation of one.

// Install-Package Spire.PDF
using Spire.Pdf;

var converter = new ChromeHtmlConverter(@"C:\Program Files\Google\Chrome\Application\chrome.exe");
var options = new ConvertOptions();

converter.ConvertToPdf("https://example.com/invoice", "invoice.pdf", options);

ChromeHtmlConverter drives an actual, already-installed copy of Chrome, executing JavaScript and laying out dynamic content the way Chrome itself would, and e-iceblue told forum users on 17 January 2025 that new feature work is landing on this path rather than the older Qt-based converter. The rest of the library covers more ground than most budget competitors attempt. Beyond HTML input, Spire.PDF converts to and from Word, Excel, PowerPoint, SVG, PostScript, PCL, Markdown, JSON, and raster images, on top of merge, split, form filling, and watermarking on existing PDFs, all from one package. e-iceblue's lighter NuGet package extends that further, with no evaluation warning at all, just its 10-page and 3-page caps enforced in the library's own code rather than a marketing rounding. What all three of those share is the same shape underneath, real capability sitting behind a second piece of infrastructure that the API call alone doesn't provide.

How do Spire.PDF and IronPDF compare?

With those strengths on the table, here is how the two libraries line up across the capabilities that matter for a rendering pipeline.

Capability	Spire.PDF	IronPDF
Rendering engine included in the package	Not included, ChromeHtmlConverter drives a customer-installed Chrome, or a downloaded Qt plugin	Yes, ChromePdfRenderer ships with Chromium bundled in the NuGet package
Applying a license in code	Spire.Pdf.License.LicenseProvider.SetLicenseKey plus LoadLicense, requested per evaluation	One key set once, no evaluation watermark to clear afterward
Linux and Docker HTML-to-PDF	Supported, needs a virtual display server and a manual dependency install	Supported without extra setup
Entry-level tier	e-iceblue's page-capped NuGet package, 10 pages per document and 3 pages on conversion output	Trial key covers the full API, delivered by email on signup
Public website or cloud deployment	Requires the OEM tier	Included at every commercial tier
OCR	Sold as a separate e-iceblue product	Available through IronOCR
Export format range	Word, Excel, PowerPoint, SVG, PostScript, PCL, Markdown, JSON, images	Built around PDF creation and editing from HTML, images, and existing PDFs
Entry list price	$999, Developer Small Business, one developer, one location, internal use only	Quote-based

Where does container setup add friction?

Neither rendering engine ships pre-installed, and each one asks for a different kind of setup before it runs anywhere outside a developer's own Windows machine.

• The legacy converter needs a plugin fetched separately per platform: the Qt-based plugin has to be downloaded for Windows x86, Windows x64, macOS, or Linux, unzipped next to Spire.Pdf.dll, and pointed at through HtmlConverter.PluginPath, with the Microsoft Visual C++ 2015 Redistributable installed alongside it.
• The Chrome-based converter needs Chrome itself: ChromeHtmlConverter drives a copy of Chrome that has to already be on the machine at a path supplied in code, which means provisioning it, patching it, and keeping it at a version the library was tested against, on every machine the code runs on.
• Linux and Docker need a virtual display server before either engine renders anything: e-iceblue's own support guidance calls for getting Xvfb running and routing the process through xvfb-run, alongside a dependency list that includes libgdiplus, xfonts-base, xfonts-75dpi, dbus, libnss3-dev, libasound2, and libegl1. Support threads from January 2025 describe the Qt path as closely tied to the host system environment, and show conversions failing outright in containers missing one of those packages.

Cross-platform builds add one more wrinkle worth planning around. Targeting .NET 6 or later without Windows means dropping System.Drawing.Common for the netstandard2.0 build built on SkiaSharp, which drops the System.Drawing.Printing.PrintSettings class along the way.

Does Spire.PDF carry any CVEs?

Spire.PDF's own code has a clean record across the databases that would show one. NVD returns zero results for a Spire.PDF or e-iceblue keyword search, the GitHub Advisory Database lists no advisories against the NuGet package, and Snyk reports no direct vulnerabilities. For a closed-source product with no public advisory feed, that means no CVE in the library's own code turns up across any of the three, not that none could ever exist.

Maintenance is active. Spire.PDF for .NET sits at version 12.8.3, published 14 August 2026. That lighter package lags several releases behind at 12.4.0 from April 2026 and carries no support of any kind. Spire.PDF also has no OCR and no redaction built in. e-iceblue sells OCR as a separate product line entirely, so a pipeline that needs both scanned-document text extraction and PDF generation ends up licensing and integrating two products from the same vendor instead of one.

No key to renew, no watermark

The same job, turning a URL into a PDF with JavaScript rendered, looks different from the first line here.

// Install-Package IronPdf
using IronPdf;

IronPdf.License.LicenseKey = "IRONPDF-MYLICENSE-KEY1A";

var renderer = new ChromePdfRenderer();
PdfDocument pdf = renderer.RenderUrlAsPdf("https://example.com/invoice");
pdf.SaveAs("invoice.pdf");

Setting that key happens once at startup, using the licensing setup IronPDF documents, and Chromium ships inside the package itself, so there's no separate Chrome install to provision, no Qt plugin to unzip per platform, and no Xvfb setup to script into a Dockerfile before a Linux container can render the same page. The trial key itself arrives differently too. IronPDF's key lands by email as soon as the signup form is submitted, not after a support ticket or a forum post asking for a temporary one.

A project that never exceeds that lighter package's 10-page ceiling gets real, usable capability inside that cap. Where the calculus shifts is deployment count. The more machines and containers a rendering pipeline runs on, the more that second-binary tax compounds, and that's the point where bundling the engine starts saving more than it costs.

Is the watermark worth working around?

A project small enough to live inside Spire.PDF's lighter, page-capped package still comes with setup attached, a license key to request, and a browser or display server to keep patched before Linux or Docker enters the picture. For a pipeline that's already past the page cap and running across more than one machine, IronPDF's bundled Chromium and single license key remove that entire layer of setup instead of adding one.

Has your team requested a temporary Spire.PDF license during evaluation, or gone straight for a paid tier to skip the watermark? We would like to hear how that request-and-wait step played out in the comments.

Spire.PDF is a trademark of its owner, and this piece is not affiliated. The details above are drawn from e-iceblue's public documentation, its support forum, and public vulnerability databases as they stood at the time of writing. If a detail has changed since, correct us in the comments.