HTML to PDF in .NET and C#, rendered the way a browser renders it
EvoPdf Next converts HTML, CSS and JavaScript to PDF with a Chromium-based engine packaged as a .NET Standard 2.0 library. One API on Windows, Linux and macOS, x64 and ARM64, in web, console and desktop applications, on Azure and in Docker. It generates PDF/UA documents for accessibility and PDF/A documents for archiving directly from the HTML, with headers, footers, bookmarks and tables of contents built from the content.
Version 14.60.1. Building EVO PDF libraries since 2010. Evaluate without registration; the demo output is watermarked until you set a license key. Perpetual licenses from 450 USD, or 1200 with redistribution and unlimited servers, covering Next and Classic. Developers are never counted.
Quick start · C# guide · Documentation · Samples and demos on GitHub · AI agent skills
dotnet add package EvoPdf.Next.HtmlToPdf.Windows
This is the Windows package; EvoPdf.Next.HtmlToPdf.Linux and EvoPdf.Next.HtmlToPdf.MacOS work the same way. The all-components EvoPdf.Next.Windows / .Linux / .MacOS packages include it too.
using EvoPdf.Next; // URL to PDF var converter = new HtmlToPdfConverter(); byte[] pdf = converter.ConvertUrl( "https://www.evopdf.com"); File.WriteAllBytes("UrlToMemory.pdf", pdf); // HTML string to PDF, with base URL converter = new HtmlToPdfConverter(); pdf = converter.ConvertHtml("<b>Hello World</b>", "https://www.evopdf.com"); File.WriteAllBytes("HtmlToMemory.pdf", pdf);
- Windows 10 / 11 / Server 2016–2025, x64 and ARM64
- Linux 64-bit, x64 and ARM64
- macOS 12+ on Apple Silicon
- .NET 6 → 10, .NET Standard 2.0
- .NET Framework 4.6.2 – 4.8.1
- Azure App Service, Functions, Cloud Services & VMs · Docker
From NuGet to your first PDF in three steps
Add the package for your platform
Shown for Windows x64. The Linux, ARM64 and macOS packages are listed in the packages section.
dotnet add package EvoPdf.Next.HtmlToPdf.Windows
Import the namespace
Every EvoPdf Next component lives in the same namespace, so HTML, Word and Excel conversion sit side by side in one project.
// add this using statement at the top of your C# file using EvoPdf.Next;
Convert
An HTML string or a URL in, PDF bytes out. Each method has a …Async variant.
var converter = new HtmlToPdfConverter(); byte[] pdf = converter.ConvertHtml( "<b>Hello World</b> from EVO PDF !", null); File.WriteAllBytes("HtmlToMemory.pdf", pdf);
Convert a URL
var converter = new HtmlToPdfConverter(); byte[] pdf = converter.ConvertUrl("http://www.evopdf.com"); File.WriteAllBytes("UrlToMemory.pdf", pdf);
Return the PDF from an ASP.NET Core action
byte[] pdf = converter.ConvertHtml(html, baseUrl); return new FileContentResult(pdf, "application/pdf") { FileDownloadName = "HtmlToPdf.pdf" };
What you do not have to build yourself
A headless browser prints a page and stops there. Public institutions and regulated industries now require PDF/UA and PDF/A compliance, checked with validators. Business documents need more than a screenshot of a web page. EvoPdf Next generates documents that meet those standards, with tables of contents and outlines built from the content, headers and footers sized automatically from their HTML, digital signatures, HTML stamps and interactive content such as PDF forms.
Accessible and archivable PDFs, generated directly from HTML
- PDF/UA-1 and PDF/UA-2 tagged documents produced automatically from the HTML structure and validated in veraPDF, PAC and Adobe Acrobat
- PDF/A-2a, 2b, 3a, 3b, 3u, 4 and 4f for archiving, alone or combined with PDF/UA (PDF/UA-2 + PDF/A-4, for example)
- Table of contents and hierarchical bookmarks built from H1 to H6 tags, or from any element you mark with a
data-headingattribute - HTML forms become interactive PDF forms, with their fields, options and actions
- Internal links stay links inside the PDF
Page layout you control from HTML
- Headers and footers written in HTML, with placeholders for the page number and the page count; their height is measured from the content and odd pages, even pages and the first page can each get their own
- Convert only the elements you select, or leave selected elements out
- The PDF position of any HTML element is returned after conversion, so you can stamp, sign or annotate exactly there
- Table headers and footers repeated on every page; page breaks controlled from CSS
- Several HTML pages merged into one PDF, HTML stamps with rotation and opacity
Security, signatures and delivery
- Digital signatures with a timestamp, from a certificate file or the certificate store
- Open and permissions passwords: print, copy, edit and form filling can each be allowed or denied
- Viewer preferences: how the document opens, page mode and layout, window title
- File attachments embedded in the generated PDF
How the page is requested and rendered
- Custom HTTP headers and cookies on the request, GET or POST, pages behind authentication
- Conversion triggered when the page loads, after a delay or from your own JavaScript, once async data has arrived
- Screen or print media type, web fonts, SVG kept as vectors
- HTML to JPEG, PNG and WEBP with the same options
And when the PDF exists, the work is usually not over. A headless browser cannot extract its text, render its pages to images or extract the images embedded in it; the other EvoPdf Next components do, in the same namespace and under the same license. See what else is in the toolkit.
Perpetual licenses, with a year of updates and support
The HTML to PDF license covers the HTML to PDF converter, Next and Classic. The EVO PDF Toolkit license covers every component on this site: HTML to PDF plus Word, Excel, RTF and Markdown to PDF, the Core PDF API and the PDF tools, Next and Classic. After purchase you receive a license key by email; set it in your code and the demo stamps disappear.
Deployment License
- For your own application, not for applications you distribute to customers
- Updates and standard support for the first year
Company License
- Redistribute inside your own applications to your customers, at no extra cost
- Updates and priority support for the first year
One rendering engine for your application, a private browser for every document
The converter keeps one headless Chromium engine running for your application and renders each document in its own browser inside it, with its own cookies, cache and storage. What you get per second depends on your hardware and your documents. What stays true on any machine is the relationship between cores, parallel conversions and memory.
A Chromium engine integrated with the library
The rendering engine is a Chromium build shipped with the library and integrated with it, not a Chrome executable driven over a debugging port. It asks less of the machine and it runs where a Chrome installation cannot, Windows Azure App Service included.
Every document starts clean
Each conversion gets a new browser with a private context that is discarded when the PDF is delivered. Nothing carries over from one document to the next: no cookies, no cache, no state. A page that misbehaves affects its own conversion and nothing else.
Scales with the cores you give it
Conversions run in parallel from as many threads as you like. Throughput grows almost in a straight line up to the number of processors: a 16 core server finishes 16 to 18 invoices a second, a laptop core about 3. How many conversions run at once is one setting, with a default that fits the machine.
Sizing a server
Allow 0.5 to 1 GB for the resident engine and 150 to 200 MB for every conversion you want running at the same time. A machine with 8 cores running 8 conversions at once needs roughly 2.5 GB for the converter, on top of whatever your own application uses.
Stable over long runs
Thousands of conversions in a row end with the same memory footprint as the first few hundred, with the disk quiet under any load. The converter works normally on machines with no outbound internet access.
These figures come from a console application we wrote to measure the converter: throughput, latency, memory and handle counts across a range of concurrency levels, repeated in reverse to catch a machine that throttles, with a long run that samples the memory every few hundred conversions.
A package for each platform
The Windows and Linux packages without an architecture suffix target x64; the ARM64 builds carry the .Arm64 suffix. The macOS packages are the exception: there is a single build, for Apple Silicon. The metapackages reference every EvoPdf Next component for that platform.
Runtime requirements
The rendering engine is inside the package you install: a current Chromium build, updated with the library, in the standard packages, with no separate engine package and no reduced feature set. Nothing is downloaded at first run and no browser has to be installed on the machine.
The Windows and macOS runtimes need no extra dependencies. On Linux some system packages may be required: the Getting Started on Linux guide lists them per distribution.
| Target | HTML to PDF only | All components (metapackage) |
|---|---|---|
| Windows x64 | EvoPdf.Next.HtmlToPdf.Windows | EvoPdf.Next.Windows |
| Windows ARM64 | EvoPdf.Next.HtmlToPdf.Windows.Arm64 | EvoPdf.Next.Windows.Arm64 |
| Linux x64 | EvoPdf.Next.HtmlToPdf.Linux | EvoPdf.Next.Linux |
| Linux ARM64 | EvoPdf.Next.HtmlToPdf.Linux.Arm64 | EvoPdf.Next.Linux.Arm64 |
| macOS (Apple Silicon only) | EvoPdf.Next.HtmlToPdf.MacOS | EvoPdf.Next.MacOS |
| Windows x64 + Linux x64 | EvoPdf.Next.HtmlToPdf | EvoPdf.Next |
All packages are on nuget.org, including the EvoPdf.Next metapackages. Deployment guides: Azure App Service · Azure Functions · Docker · Build and publish the demo app
Install and run on Windows, Linux and macOS
The HTML to PDF Converter uses a platform-specific runtime shipped inside the NuGet package. Windows and macOS need nothing else; on Linux a few system packages may be required, depending on the distribution: the Getting Started guides list them.
Windows
Windows 10, 11 and Windows Server 2016–2025, x64 and ARM64. No additional dependencies.
Getting Started on Windows →Linux
64-bit distributions, x64 and ARM64. The guide lists the system packages per distribution.
Getting Started on Linux →macOS
macOS 12 and later on Apple Silicon (ARM64). No additional dependencies.
Getting Started on macOS →Docker
Complete Dockerfiles for Linux (x64, ARM64) and Windows Server containers, with the runtime dependencies and the build commands.
Docker page →Azure
App Service on Windows and Linux, Azure Functions, Container Apps and AKS: plan sizing, the Linux startup command, ConfigureRuntime.
Runs in Linux and Windows containers. EvoPdf Next works in the official Microsoft ASP.NET Core images (aspnet:8.0, aspnet:10.0), x64 and ARM64, with four apt packages added in the Dockerfile. The demo application ships ready to publish and run as a container, so the same image can go from your laptop to CI to Kubernetes or Azure.
Each demo has its source code in the documentation
The online demo is the same ASP.NET application you download, running on our servers. Whatever you try there, the documentation has the complete controller code behind it, ready to paste into your project. The list below is the HTML to PDF part; the demo also covers PDF creation and editing, Word, Excel, RTF and Markdown to PDF, plus text and image extraction.
EvoPdf Next is more than HTML to PDF
The HTML to PDF converter is one of nine components in EvoPdf Next. The others share the same namespace and package layout and can be added to the same project. They are licensed together as the EVO PDF Toolkit: 650 USD for a Deployment License, 1400 USD for a Company License, HTML to PDF included, Next and Classic alike.
Core PDF API
Create PDFs from text, images and shapes; stamp, merge, secure and digitally sign existing documents.
Word to PDF
Convert complex DOCX documents to PDF, with tables of contents, headers, footers, stamps and security.
Excel to PDF
Convert XLSX workbooks to PDF with headers, footers, stamps and document security.
RTF to PDF
Convert RTF documents to PDF with tables of contents, headers, footers and stamps.
Markdown to PDF
Convert Markdown documents to PDF with tables of contents, headers, footers and stamps.
PDF to Text
Extract text in the original layout or optimized for reading; search text and get the position of matches.
PDF to Image
Render PDF pages to PNG with control over color space, resolution and transparency.
PDF Images Extractor
Extract the images embedded in a PDF as PNG, preserving transparency.
EvoPdf Classic: the original engine, actively supported and licensed alongside Next
EvoPdf Classic uses our own rendering engine, in production for many years, with a small footprint and low memory and disk requirements. The Classic New Edition adds ECMAScript 6, WOFF 2, HTTP/2 and TLS 1.3 to the HTML5, CSS3 and SVG support of the original engine. It runs on Windows: the New Edition on .NET Framework 4.0 and later and on .NET 6 to 10, the original edition on .NET Framework 2.0, 3.5 and 4.0. Your HTML to PDF license covers Classic and Next alike.
Moving from Classic to Next
The license stays the same and the class names will look familiar, but the namespace changes from EvoPdf to EvoPdf.Next, the packages change and the rendering engine is new, so expect compile errors on the first build and some options that moved. The migration guide covers the API differences, how authentication, redirects and cookies are configured in Next, how page size, margins and images are handled and what to expect from the size of the generated PDF.
Runnable samples and skills that teach AI assistants EvoPdf Next
Every documentation sample as code, the complete demo applications and agent skills for Claude Code, GitHub Copilot, Cursor and Codex, including a Classic to Next migration skill.
Download the demo application
The same ASP.NET application that runs the online demo on this site, as a project with complete C# source code and NuGet references, plus build and publish instructions for Windows, Linux, macOS, Azure and Docker. The library itself comes from NuGet.