Some links on this page are affiliate links: if you buy through them we may earn a commission, at no extra cost to you.
For a .NET 7 application that needs to turn an HTML string into a PDF, use a renderer built for HTML—such as IronPDF’s Chromium-based ChromePdfRenderer—rather than routing the conversion through System.Drawing.Common. The direct conversion is short; avoiding warnings depends on the renderer and its dependencies supporting your target operating system. Do not suppress a platform warning as a substitute for that compatibility. One important qualification: .NET 7 reached end of support on May 15, 2024, so treat it as a maintenance target, not the default for a new service.
Convert an HTML string directly to PDF
IronPDF documents ChromePdfRenderer.RenderHtmlAsPdf for passing an HTML string and receiving a PdfDocument. Its documented rendering engine is Chromium, and its documentation lists .NET 7 as a supported runtime. A minimal C# conversion looks like this:
using IronPdf;
var renderer = new ChromePdfRenderer();
var pdf = renderer.RenderHtmlAsPdf("<h1>Hello IronPDF</h1>");
pdf.SaveAs("output.pdf");The code illustrates the conversion path: provide markup, receive a PDF document, and save it. To run it in an application, add the IronPDF package using the package installation method documented for the version you select, then check that version’s .NET 7 compatibility, native dependencies, and licensing terms. Those details can change between releases; the API example alone does not establish that every package version or deployment image will work without warnings.
For a string assembled at runtime, pass the complete markup where the example uses the literal. Make sure the string is valid HTML and includes the content you intend to print. This method is for HTML input; it does not require you to save the markup to a file first.
#1 Best Overall
When the HTML refers to other files
A string can contain references to stylesheets, scripts, fonts, or images that are not present in the string itself. Those resources must be resolvable by the renderer. IronPDF’s tutorial describes supplying a suitable base directory for local resources, but the exact API call should be checked in the documentation for your selected package version. Do not assume relative browser paths, local-file access, or outbound network access will behave identically on a developer workstation, a container, and a production host. Test with the actual resource locations and deployment permissions.
For remote assets, verify that the runtime environment can reach the host and that the renderer is allowed to load the resource. For local assets, verify that the deployed files exist at the paths the renderer resolves. If a PDF has missing styles or images while the conversion itself succeeds, resource resolution is a more useful first check than changing the PDF save step.
What “without warnings” means in .NET 7
A warning-free build is not the same thing as hiding a warning. Microsoft’s .NET platform guidance explains that System.Drawing.Common became Windows-specific in this context: in .NET 6, non-Windows use could trigger a platform analyzer warning, and the compatibility switch that temporarily enabled Unix support was removed in .NET 7. Microsoft states that, starting with .NET 7, the System.Drawing.EnableUnixSupport switch has been removed and System.Drawing.Common can no longer be used on non-Windows operating systems.
Consequently, setting or retaining that switch is not a fix for a .NET 7 Linux deployment. If an HTML-to-PDF path or an ancillary image-processing step pulls in System.Drawing.Common, the right response is to identify which dependency uses it and choose a platform-compatible path. Microsoft lists SkiaSharp, ImageSharp, Aspose.Drawing, and Microsoft.Maui.Graphics as alternatives for drawing tasks. That list does not mean each is a drop-in replacement for every operation; confirm the API and licensing fit for your particular use.
For this workflow, the practical definition of “without warnings” is that the selected renderer and all of its transitive image, font, and native components support both the target framework and the operating system where the application runs. A successful compilation on Windows does not prove a Linux container will work. Conversely, a warning about a platform-specific dependency should not be silenced merely to produce a clean build: doing so can conceal a runtime exception or a deployment incompatibility.
Choose a renderer based on rendering and deployment needs
These options use different architectures. The most important questions are whether you need direct HTML-string input and modern browser rendering, how you will package the renderer or browser, and who owns process lifecycle and licensing. No comparative performance benchmark is established here, so there is no defensible speed ranking.
Rank #4
| Option | What is documented | Fits when | Trade-off to evaluate |
|---|---|---|---|
| IronPDF | ChromePdfRenderer.RenderHtmlAsPdf accepts an HTML string and returns a PDF document; Chromium-based rendering and .NET 7 compatibility are documented. |
You want an application-integrated renderer for HTML, CSS, JavaScript, and images. | It is a commercial dependency. Verify the selected version’s package, native deployment requirements, and license terms. |
| PuppeteerSharp | It is a .NET port of Puppeteer. Its API documents launching a headless browser, navigating, and calling PdfAsync. |
You need explicit control over a browser page and its lifecycle. | Browser acquisition, process management, and orchestration are operational responsibilities to plan for. |
| wkhtmltopdf | The official project describes an LGPL command-line tool using the Qt WebKit rendering engine. | An existing system is already organized around the binary and its process model. | It uses an older WebKit engine and an external binary deployment model. Check modern CSS and JavaScript needs, maintenance, and security posture before adopting it. |
| Document-layout libraries | The sources considered here do not establish QuestPDF or PDFsharp-style APIs as direct HTML-string renderers. | You can define the document as layout and components rather than use existing HTML as the source. | Using an existing HTML string may mean rebuilding the document in a different layout model. |
For an existing HTML string that relies on contemporary CSS or JavaScript, a Chromium-based renderer is the most direct documented fit among these options. That is an architectural match, not a claim that one library is universally best or that every browser feature will render identically in every environment. Evaluate font availability, asset loading, page-break control, isolation, Linux/container behavior, licensing, and support against your own document and hosting model.
Deploy and validate the conversion
- Choose a supported package version. Check the renderer’s current documentation for its supported framework, operating systems, native requirements, and license terms. Do not infer these from an example targeting .NET 7.
- Run the conversion in the deployment environment. Test the same operating system and container image used in production, not just a Windows development machine. Confirm that the PDF is written to the expected path and can be opened.
- Use representative markup. Include the kinds of CSS, images, fonts, scripts, and long content that real documents use. Verify that external and local resources resolve as intended.
- Inspect output and logs. Check for missing assets, layout differences, renderer errors, and platform warnings. Address the dependency or resource issue rather than suppressing its warning.
- Revalidate after upgrades. Package versions can change their runtime requirements. Recheck deployment and output when updating the renderer or moving to another .NET release.
For a long-running service, also consider how conversion work is isolated and scheduled, how failures are surfaced, and what resource limits apply to the host. The sources cited for these APIs do not provide a comparative performance benchmark or universal memory and concurrency figures; measure those against your own documents and deployment rather than assuming a particular throughput.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Common problems and fixes
- A warning or exception mentions
System.Drawing.Commonon Linux. Find which direct or transitive dependency uses it. Replace that drawing operation with a suitable cross-platform alternative or use a renderer whose dependencies support the target OS. The .NET 7 Unix compatibility switch is removed, so trying to re-enable it is not a recovery path. - The PDF is missing CSS, images, or fonts. Check whether those resources are embedded, locally available, or remotely reachable. For local references, configure the renderer’s documented base directory or resource-resolution mechanism for your version. Check paths and permissions in the deployed environment.
- The conversion works locally but fails in a container. Compare operating system, native dependencies, fonts, file access, and network access between the two environments. Use the renderer’s deployment documentation for the exact package version.
- JavaScript-dependent content is absent or incomplete. Confirm that the chosen renderer supports the needed JavaScript and that content has time to load before rendering. Do not assume a static HTML-to-PDF conversion waits for arbitrary application behavior unless the selected API documents that behavior.
- The build is clean only after suppressing a warning. Undo the suppression while diagnosing the dependency. A warning can identify a genuine OS incompatibility, and removing it from the build output does not make the component portable.
- The PDF layout differs from a browser preview. Check fonts, viewport-related CSS, resource access, and page-break rules in the renderer’s environment. Validate a representative PDF with the exact renderer version you intend to deploy; no fidelity percentage or cross-library layout guarantee is established here.
Account for .NET 7’s support status
Microsoft’s lifecycle table gives .NET 7 a support window from November 8, 2022, through May 15, 2024. That support has ended. If you are maintaining a .NET 7 application, the conversion example and platform-warning explanation remain relevant to that target, but plan a move to a currently supported .NET release. For a new application, evaluate a supported target first and then confirm the renderer’s compatibility with it.
Or skip the browser setup
ScreenshotNeo is a website screenshot API and MCP server, not a drop-in converter for an arbitrary HTML string. If your markup is already published at a URL and your goal is a clean capture of that live page, its API offers a one-request route. The example below captures a URL; it does not turn an in-memory C# HTML string into a PDF.
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://example.com -o shot.webpSee the ScreenshotNeo API documentation for the request options and supported output formats. ScreenshotNeo accepts cookie and consent banners like a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets before capture; those steps can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits are not billed, and response headers report the page verdict and billing status. Its MCP server provides take_screenshot, get_page_info, and capture_pdf tools for AI agents and other MCP clients. The Free plan includes 1,000 shots per month with no card; paid plans start at $5 for 3,000 shots.
Recommended Free Tools
Sign up for ScreenshotNeo’s free plan: 1,000 screenshots a month, no card required.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
