EvoPdf in 2026: Two Products, One Price List

An invoice template that rendered clean in Chrome came out the same from EvoPdf's HTML to PDF Converter on Windows. The next request looked simple, moving the render step into a Linux container next to the rest of the pipeline. It did not move. The EvoPdf.HtmlToPdf package has no Linux build, and the fix is a different package, EvoPdf.Next.HtmlToPdf, sold under the same brand and price list. Everything below is checked against EvoPdf's own site, NuGet listings, and license agreement, and set next to how IronPDF renders the same page.

Full disclosure. We build IronPDF at Iron Software, and this read looks at where EvoPdf's Classic-and-Next product split and unnamed Chromium build cost a team, and where IronPDF renders the same page from one documented namespace.

Which Chromium Build and Which EvoPdf Product Are You Buying?

Next's HTML-to-PDF call is short.

// Install-Package EvoPdf.Next.HtmlToPdf
using EvoPdf.Next.Chromium;

using var converter = new HtmlToPdfConverter();
using var pdfDocument = await converter.ConvertUrlAsync("https://example.com/invoice");
pdfDocument.Save("invoice.pdf");

That call runs on a Chromium-based engine that processes modern HTML, CSS3 and JavaScript to current standards, with referenced TrueType fonts embedded in the output by default so a custom typeface does not silently fall back to a system font. The engine ships across Windows, Linux and macOS, on x64 and ARM64, with Azure App Service, Azure Functions and Docker support. HtmlToPdfConverter also exposes Task-based methods with CancellationToken support, and recent releases added PDF/UA-1 and PDF/UA-2 accessibility output. The Chromium build actually doing the rendering is never named, absent from both the vendor site and the NuGet listing, so a dependency-freshness check has nothing first-party to compare against.

Format coverage runs past HTML too. Word, Excel, RTF and Markdown convert straight to PDF from the same library, on top of extraction, merge, split, encryption and signing. A single Chromium-based renderer covers the same ground everywhere the job starts from HTML markup, a browser render, or an existing PDF, under one namespace instead of two.

Which namespace that engine actually belongs to is the harder question.

• Classic and Next split the platform story: the two live in separate namespaces, EvoPdf and EvoPdf.Next, with different class surfaces, and the price list does not say which one a purchase buys. The EvoPdf metapackage alone accounts for roughly 3.5 million NuGet downloads against a Next line only months old, so adding Linux or macOS support later means a full API migration to a different namespace, not a version bump.
• The Deployment license is scoped to a single server: at $450 for the HTML to PDF Converter, it covers one application on one machine. Scaling horizontally, across a container cluster or a second server, moves the requirement to the $1,200 Company license or a second Deployment purchase.
• There is no low-cost fallback tier, and refunds start from no: every unlicensed conversion is watermarked, and refund requests are not accepted in general, with exceptions handled case by case through sales.

What actually matters is which EvoPdf a given purchase buys and what happens the first time it needs to run somewhere Classic does not reach.

How Do EvoPdf Next and IronPDF Compare on Rendering and Licensing?

The technical differences and the licensing model line up like this, drawn from EvoPdf's own site and license agreement rather than an older comparison that predates the Classic-and-Next split.

Rendering and licensing	EvoPdf (Next)	IronPDF
HTML render call	HtmlToPdfConverter.ConvertUrlAsync in EvoPdf.Next.Chromium	ChromePdfRenderer.RenderUrlAsPdfAsync in one IronPdf namespace
Async support	Task-based, with CancellationToken	Async and await throughout, including RenderHtmlAsPdfAsync
Rendering engine transparency	Chromium build version not published	Chromium build version documented in release notes
Product-line clarity	Two products, EvoPdf and EvoPdf.Next, one price list	One product, one IronPdf package
Format range	Word, Excel, RTF and Markdown to PDF, plus manipulation	HTML, image and existing-PDF input through ChromePdfRenderer and PdfDocument, covering merge, split, encryption and signing
Cross-platform reach	Windows, Linux, macOS, x64 and ARM64	Windows, Linux and macOS, one build across all three
License model	Deployment license, one server ($450), or Company license for multiple servers and redistribution ($1,200)	Commercial license, licensed by deployment, with support and updates included

Table 1. EvoPdf Next and IronPDF, rendering and licensing terms compared directly against each vendor's own documentation.

What Does the Same Render Call Look Like Without the Product-Line Question?

A keyword search of the National Vulnerability Database, the GitHub Advisory Database and Snyk turns up no CVEs or advisories against EvoPdf's own code. EVO PDF Software is a trading name of No Limit Software, a Romanian company that also trades as Winnovative Software Solutions, stated directly on both companies' own contact pages, so a support ticket with one brand runs through the same company as the other.

IronPDF renders the same way, from one product line with one namespace to learn.

// Install-Package IronPdf
using IronPdf;

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

There is no Classic-or-Next decision to make before writing that call, and the Chromium build behind the renderer is documented rather than left as an open question, with the same rendering behavior on Windows, Linux or macOS.

A team already on Next that knows which product line it bought gets real cross-platform rendering at a comparable price point, and that part of the picture holds up. Where the calculus changes is a team currently on Classic facing a platform expansion, since moving off Classic means a rewrite to a different namespace regardless of destination, which is the moment IronPDF's single namespace removes one variable from that migration. For a template built in Razor rather than raw HTML, the same renderer takes that input too.

One Product, No Guesswork Required

EvoPdf Next is a capable, cross-platform HTML-to-PDF engine with a format range that reaches past HTML into Word, Excel, RTF and Markdown. What complicates a purchase is two products under one price list that does not say which is which, a Chromium build nobody versions, and a license scoped to a single server. Know which EvoPdf a deployment is actually running, and what scaling it will cost, before evaluating anything else about it. IronPDF skips that first question by staying one product on one namespace, which covers most of what a rendering pipeline needs to plan around. If you want to run that render call against your own EvoPdf output, IronPDF has a trial built around exactly that migration case.

Were you already on EvoPdf Classic or Next without realizing there were two separate products, and did the Deployment license's one-server scope ever catch a project off guard once a build moved into a container? Tell us about it in the comments.

EvoPdf, EvoPdf Next, and Winnovative are trademarks of their respective owners, and this piece is not affiliated with EVO PDF Software or its parent, No Limit Software. The rendering behavior, product-line split, and pricing above are drawn from EvoPdf's own documentation, NuGet listings, and license agreement as they stood at the time of writing. If a detail has changed since, correct us in the comments.