Convert PDF to Image in C#: The One-Liner That Isn't in 2026

\ TL;DR: Rendering a PDF page to an image in C# is a one-liner in every library here. Rendering it correctly, at the right fidelity, and at scale is where they diverge, and the divergence lives in four places the tutorials skip: native-dependency footprint, thread-safety, DPI/fidelity control, and memory under batch. Ghostscript is powerful but brings a native dependency and a licensing decision; PDFium wrappers render beautifully but aren't thread-safe; in-process libraries like IronPDF trade a license cost for zero native dependencies. Here's how each scores against the four criteria, with code. Disclosure: I'm a developer advocate at Iron Software, which makes IronPDF, one of the libraries I evaluate below. I'd rather lose your trust once by hiding that than every time you notice the bias myself. So I'll call out where IronPDF is the wrong choice as readily as where it's the right one, and I'll source the claims that matter. (On HackerNoon I've checked the "vested interests disclosed" box in the story settings.) The one-liner that isn't If you search "pdf to image c#," every result will show you roughly the same thing: load a PDF file, call one method, get a PNG image. And that's accurate. Every library in this article can rasterize a page in a single line. If your job is to render one well-behaved PDF on your dev machine and look at the output, you're done, pick any of them and move on. The pattern that shows up again and again, in the questions developers actually bring to forums and GitHub issues, is that the one-liner ships fine and then the trouble starts somewhere it wasn't being watched. The image file looks soft when it's blown up for print. The container that worked locally throws a missing-native-library error in production. The thumbnail service that handled ten documents falls over at ten thousand because the rendering engine underneath it can only do one at a time. None of that is visible in the one-liner. All of it is decided by the library you picked before you wrote the one-liner. So this isn't a "here's the snippet" article, those already exist, and they're fine. This is an evaluation. I'm going to lay out the four criteria that actually separate these libraries in production, walk each realistic option against them with code, and end with a recommendation I'll put my name to. The goal is that by the end you can pick the right library for your constraints, not just copy a line that works in a demo. The four criteria that actually separate these libraries Rasterizing a PDF document means taking the page's vector and text content and painting it onto a pixel grid at some resolution. Every library does that. The differences that determine whether you ship cleanly come down to four things. Native-dependency footprint. Does the library render in pure managed code or your own process, or does it depend on a native binary (a gsdll, a bundled engine) that has to be present and architecture-matched on every machine? Native dependencies are where "works on my machine" goes to die: 32-bit versus 64-bit mismatches, missing libraries in slim containers, and version skew between environments. Thread-safety and concurrency. Can the renderer handle parallel work , or does it serialize to one document at a time? This is invisible at one document and decisive at a thousand. A library that locks internally is fine for a desktop viewer and a bottleneck for a high-throughput service. DPI and fidelity control. Can you set the output resolution precisely, and does the rendering preserve fonts, vectors, and layout faithfully at that resolution? A thumbnail at 72 DPI and an archival scan at 300 DPI are different jobs, and not every library gives you clean control over the tradeoff. Memory under batch. What happens to memory and handles when you render hundreds of pages in a loop? Per-page allocation that's invisible once becomes GC pressure or a leak at volume, especially when bitmaps and native handles aren't disposed. It's worth being explicit about why these four and not, say, raw speed or supported formats. Speed matters, but every modern engine here renders a page in tens of milliseconds, fast enough that the bottleneck is almost always I/O or concurrency, not the rasterization itself. Format support (PNG, BMP, TIFF, or JPEG image) is near-universal and rarely the deciding factor. The four criteria above are the ones that actually flip a project from "shipped" to "stuck," because each of them is invisible in the demo and expensive to discover in production. A library can be the fastest renderer in a benchmark and still be the wrong choice if it can't run in your container or can't parallelize in your service. Hold those four up against any library and the marketing falls away. Let's do exactly that, starting with the most powerful and most encumbered option. Ghostscript: powerful, with strings attached Ghostscript is the veteran. It's a mature, battle-tested PostScript and PDF interpreter, and through .NET wrappers like Ghostscript.NET or Magick.NET (which uses Ghostscript under the hood for PDF input) it renders PDF document pages to images at essentially any resolution you like. Unlike many PDF processing libraries commonly available via NuGet for C# projects, the first is the native dependency: Ghostscript itself is not something you just install package as a package reference before configuration. When it works, the output is excellent. // Magick.NET (backed by Ghostscript) rendering a PDF to PNG var settings = new MagickReadSettings { Density = new Density(300, 300) // 300 DPI for print-grade output }; using var images = new MagickImageCollection(); images.Read("invoice.pdf", settings); // requires Ghostscript installed int page = 1; foreach (var image in images) { image.Write($"invoice.Page{page}.png"); page++; } Ghostscript PDF to Image Conversion Output That Density setting is real DPI control, and 300 DPI here produces genuinely print-grade output. So far so good. Now the strings. The first is the native dependency. Ghostscript is not a NuGet package you can simply reference; it's a native binary that must be installed on every machine that runs the conversion, and the architecture has to match, 64-bit Magick.NET wants 64-bit Ghostscript. This is the single most commonly reported failure against this approach: code that converts perfectly on a developer's Windows box throws a NullReferenceException or a missing-gsdll64.dll error the moment it hits a server or a container where Ghostscript isn't present or isn't the matching build. The error surfaces deep in the save call, far from the real cause, which makes it a miserable debugging session for someone who's never hit it before. The second string is licensing, and it's the one that catches teams late. Ghostscript is dual-licensed under the AGPL and a commercial license. The AGPL is strong copyleft, the same network-use obligation that makes it a deliberate decision for any closed-source product, so a commercial application that ships Ghostscript-backed conversion may need a commercial Ghostscript license. That's a legal decision, not a technical one, and it belongs in the evaluation before you build, not after legal review flags it. There's a third, quieter cost: concurrency and process model. Ghostscript wrappers commonly initialize a native interpreter instance, and sharing one across threads is fraught; teams often end up serializing access or spinning up separate processes, much like the PDFium situation we'll get to next. So the "powerful" headline comes with an operational tail that the tutorial snippet never shows: install and version-match a native binary everywhere, settle a copyleft licensing question, and design a safe concurrency model around a native interpreter. So Ghostscript earns a cautionary verdict, and the caution is about operations and licensing, not capability. If you already run Ghostscript in your stack, can guarantee the matching native binary on every target, and have settled the licensing question, it's a powerful and proven choice that renders beautifully. If any of those three is an open question, the one-liner is hiding a lot of work, and I'd want you to see that work before you commit to it rather than after a deployment fails. PDFium wrappers: great fidelity, mind the lock PDFium is the rendering engine inside Google Chrome, open-sourced and wrapped for .NET by libraries like PDFtoImage and the Pdfium.Net SDK. PDFtoImage, a .NET library for this workflow, supports saving images in JPEG, PNG, and WebP formats, and its static method API fits both .NET Core and .NET Framework projects. Because it's the same engine a browser uses, fidelity is excellent and the licensing is permissive, which makes it a deservedly popular free choice. // PDFtoImage (PDFium-backed) rendering page 0 to PNG at 300 DPI using PDFtoImage; using SkiaSharp; byte[] pdfBytes = File.ReadAllBytes("invoice.pdf"); using SKBitmap bitmap = Conversion.ToImage(pdfBytes, page: 0, options: new RenderOptions(Dpi: 300)); using var stream = File.OpenWrite("invoice.page0.png"); bitmap.Encode(stream, SKEncodedImageFormat.Png, 100); PDFium Output Clean, fast, free, faithful. For a great many projects that's the end of the search, and I'd be doing you a disservice not to say so plainly: if you need free, high-fidelity rendering and your workload is single-threaded or low-concurrency, a PDFium wrapper is an excellent pick. The catch is the one almost no comparison article mentions, even though the library authors are refreshingly honest about it. PDFium is not thread-safe. PDFtoImage's own NuGet documentation states it directly: because the native PDFium library isn't thread-safe, all calls into it are protected with locks, which means you can only process one PDF at a time. If you need true parallelism, their own guidance is that you have to spawn multiple processes and distribute the work across them, then collect results over IPC. Sit with what that means for a service. A naive Parallel.ForEach over a thousand PDFs won't actually run in parallel through one PDFium wrapper; it'll serialize behind the lock, and you'll wonder why your sixteen cores are idle. The fix, multiple processes with inter-process communication, is real engineering: process orchestration, serialization, failure handling across process boundaries. That's not a reason to avoid PDFium. It's a reason to know, before you architect the service, that horizontal scaling here means processes, not threads. It's worth being fair about how surmountable this is. Plenty of high-volume systems run PDFium happily by treating it as a pool of worker processes, each handling one document at a time, fed by a queue. That's a perfectly sound architecture, and if you've built worker-pool systems before it'll feel familiar. The trap is purely the surprise: discovering the lock after you've written code that assumed thread-level parallelism, and having to re-architect the scaling model mid-project. Native-dependency management adds the second half of the cost, since any PDFium wrapper ships a native binary that has to be present and architecture-matched on every worker, the same containerization care Ghostscript demands. So PDFium wrappers earn a conditional verdict. The condition is your concurrency model. Low-concurrency or desktop work: outstanding, and free, and genuinely my first suggestion for that profile. High-throughput parallel service: capable, but you own a multi-process design and the native-dependency management that comes with any PDFium binary. Know which world you're in before you commit, because the cost of finding out late is a rewrite of your scaling layer. SkiaSharp and the "render-it-yourself" temptation SkiaSharp deserves a brief mention because it shows up in these searches and it's genuinely capable. It's a cross-platform 2D graphics library (the .NET binding for Google's Skia), and you saw it a moment ago as the surface PDFtoImage encodes onto. It can be part of a PDF-to-image pipeline, and for teams already using Skia for other rendering it's a natural building block. The temptation to watch for is treating SkiaSharp as a turnkey PDF-to-image solution on its own. It's a graphics primitive, not a PDF rasterizer; you still need something to interpret the PDF's page content before Skia paints it. Pairing it with a PDF parser is a legitimate path if you want fine-grained control over the rendering surface, but for most people the question "which PDF-to-image library?" is better answered by one of the turnkey options than by assembling your own from primitives. If you're not specifically there for the low-level control, this isn't the layer you want to be working at. In-process rendering with no native dependency The last category is used to convert PDF documents inside your own .NET process with no separate native binary to install and no concurrency lock to design around. IronPDF sits here, using a Chrome-based engine for fidelity but exposing it through managed methods on the PdfDocument object so you can convert PDF files by rasterizing all the pages in one pass. // IronPDF: convert PDF files by rasterizing all the pages to PNG, no native dependency to install using IronPdf; PdfDocument pdf = PdfDocument.FromFile("invoice.pdf"); pdf.RasterizeToImageFiles("output/invoice_page_*.png"); IronPDF Convert PDF to Image Output That's the one-liner equivalent. But the reason this category matters for an evaluation is what the method exposes when you need more than the default. RasterizeToImageFiles takes explicit DPI, dimensions, page ranges, and image format, so the fidelity control is first-class rather than an afterthought: // Explicit DPI, dimensions, page range, and format using IronPdf; using System.Linq; PdfDocument pdf = PdfDocument.FromFile("report.pdf"); pdf.RasterizeToImageFiles( "output/page_*.jpg", pageNumbers: Enumerable.Range(1, 5), // first five pages imageType: IronPdf.Imaging.ImageType.Jpeg, dpi: 150); // 150 DPI for screen-quality IronPDF RasterizeToImageFiles Output And when you need the bitmaps in memory rather than on disk, for a viewer, an upload, or further processing, ToBitmap() returns them as objects you can manipulate: // In-memory bitmaps for a single page (e.g. a WinForms/WPF viewer) using IronPdf; using IronSoftware.Drawing; PdfDocument pdf = PdfDocument.FromFile("report.pdf"); AnyBitmap[] allPages = pdf.ToBitmap(150); //example of then saving the bitmap image for (int i = 0; i < allPages.Length; i++) { allPages[i].SaveAs($"report.Page{i + 1}.png"); allPages[i].Dispose(); // Keeps memory usage low } IronPDF ToBitmap() Output The method surface is documented in the IronPDF rasterize-to-images guide . Against the four criteria, the profile is: no separate native dependency to install or architecture-match, in-process rendering so concurrency follows your normal .NET scaling rather than a process-pool workaround, explicit DPI and dimension control, and Chrome-engine fidelity. In practice, ToBitmap() lets you convert PDF pages to in-memory bitmaps for further processing, including a viewer scenario. Now the candor I promised. This is a commercial library, so it carries a license cost where PDFium wrappers don't, and because it bundles a rendering engine its package footprint is larger than a thin native wrapper. If your need is free single-threaded rendering and you're happy to manage a PDFium binary, a PDFium wrapper is the more economical fit and I'd point you there. Where in-process libraries earn their price is specifically the segment where you want high fidelity and clean DPI control without owning a native dependency or engineering around a concurrency lock. Syncfusion's converter (also PDFium-based) occupies a nearby commercial bracket and is worth a look if you're already in their ecosystem. The point of the category isn't that one product wins; it's that "no native dependency, scales like normal .NET code" is a distinct and valuable profile. DPI and fidelity: getting the quality right DPI is the setting people most often get wrong, in both directions, so it's worth its own section regardless of which library you choose. DPI (dots per inch) is the resolution at which the vector PDF is rasterized, and it's a direct quality-versus-size tradeoff. 72–96 DPI is screen resolution. It's right for thumbnails and small previews, where the image will be displayed at roughly its rendered size. Going higher just wastes bytes. 150 DPI is the sweet spot for on-screen viewing at full size and most web display. It's sharp on a modern display without the file bloat of print resolution. 300 DPI is print-grade and the standard input resolution for OCR. If the image will be printed, or fed to a text-recognition engine, this is your floor. Below it, print looks soft and OCR accuracy drops. Above 300 DPI is rarely worth it unless you're producing large-format print or zooming deeply; file size grows with the square of DPI, so 600 DPI is roughly four times the bytes of 300 for benefit most workflows never see. The fidelity half of the equation is about how the library rasterizes, not just at what resolution. Engines built on a browser core (PDFium, Chrome-based renderers) tend to handle modern PDF features, embedded fonts, transparency, and vector graphics, faithfully because they're the same engines that render the web. Where you see fidelity problems is usually missing fonts (the renderer substitutes and the layout shifts) or unusual color spaces. Whatever library you pick, the test that matters is rendering your documents, the ones with the embedded corporate font and the vector logo, not a plain-text sample, and inspecting the output at your target DPI. Batch and single-page rendering: the scale question The single-page case is the easy one, and it's what a desktop viewer or a preview endpoint needs: render one page, on demand, at display resolution. The ToBitmap example above does exactly that, rendering a single page index into an in-memory bitmap without touching the rest of the document. Batch is where the four criteria collide. Rendering a thousand documents to thumbnails is the workload that exposes everything: thread-safety decides whether you can parallelize at all, native dependencies decide whether every worker can even start, memory discipline decides whether the run finishes or dies at document 700. // Batch: reuse the renderer, dispose bitmaps, watch memory across the run using IronPdf; using IronSoftware.Drawing; foreach (var path in Directory.EnumerateFiles("in", "*.pdf")) { PdfDocument pdf = PdfDocument.FromFile(path); AnyBitmap[] pages = pdf.ToBitmap(150); for (int i = 0; i < pages.Length; i++) { pages[i].SaveAs($"out/{Path.GetFileNameWithoutExtension(path)}_p{i}.png"); pages[i].Dispose(); // dispose each bitmap — the habit that keeps batch memory flat } } Batch Rendering with IronPDF The disposal in that loop is the part that separates a batch job that finishes from one that leaks. Bitmaps hold real memory and sometimes native handles; rendering a thousand pages without disposing them is how a run that should use a few hundred megabytes balloons into an out-of-memory crash. This is true across every library here, not just this one, the lesson generalizes: in batch, dispose aggressively and measure memory across the whole run, not on a single document. And it's where the concurrency criterion pays off or punishes. With an in-process renderer that scales like normal .NET code, you parallelize batch work the way you'd parallelize anything. With a PDFium wrapper, remember the lock: parallelism means multiple processes, not a Parallel.ForEach that quietly serializes. Same workload, very different architecture, decided entirely by which library you picked. The evaluation matrix and how to choose Here's the whole evaluation in one place, scored against the four criteria that matter. Table 1: C# PDF-to-image libraries scored on production-readiness criteria (verified May 2026). | Library | Engine | Native dependency | Thread-safe? | DPI / fidelity control | License | |----|----|----|----|----|----| | Ghostscript (via Ghostscript.NET / Magick.NET) | Ghostscript | Yes — gsdll, must architecture-match | Limited; deployment-fragile | Full DPI; high fidelity | AGPL or commercial | | PDFium wrappers (PDFtoImage, Pdfium.Net) | PDFium (Chrome) | Yes — native PDFium binary | No — locked, one at a time | Full DPI; high fidelity | Permissive (free) | | SkiaSharp | Skia | Native Skia binary | N/A (graphics primitive) | You assemble it | Permissive (free) | | IronPDF | Chrome-based | None to install separately | Scales as in-process .NET | Full DPI; high fidelity | Commercial | Read it by scenario: Thumbnail / preview service at scale. Concurrency is the deciding criterion. An in-process renderer that scales like normal .NET code is the cleanest fit; a PDFium wrapper works but commits you to a multi-process design. High-fidelity or print / OCR input. Any of the Chrome/PDFium-engine options renders at 300 DPI faithfully; choose on dependency and concurrency, not on fidelity, since they're close there. Linux containers / serverless. Native-dependency footprint dominates. A library with no separate native binary to install and architecture-match avoids the most common containerized failure outright. Desktop viewer (WinForms/WPF). Single-page, low-concurrency, on-demand. A free PDFium wrapper is an excellent and economical pick here; the thread-safety lock simply doesn't bite. Budget-constrained, single-threaded. A PDFium wrapper gives you free, faithful rendering; just architect within the lock. Notice that no single library wins every row. The right answer genuinely depends on which criterion dominates your workload, which is exactly why the four-criteria lens matters more than any leaderboard. How I'd evaluate it for your project If I were choosing for your codebase, I wouldn't trust any table, including mine, over a test against your own documents. Here's the evaluation I'd run. Render your hardest real PDFs, not a sample. The scanned one, the vector-heavy one, the one with the embedded corporate font. Fidelity problems hide on real documents and never show up on plain text. Inspect at your actual target DPI. If it's going to print or OCR, look at 300 DPI output; if it's a thumbnail, look at 72. Judging print quality from a screen-resolution render tells you nothing useful. Measure memory across a full batch. Run a few hundred documents in a loop, dispose properly, and watch the memory curve. A flat curve means you're disposing right; a climbing one means a leak you want to find now, not in production. Test on the deployment target, early. Especially for native-dependency options, run it in the actual container or server, not just locally. The missing-gsdll class of failure only appears where the binary isn't. Settle licensing before you build. For Ghostscript specifically, answer the AGPL-versus-commercial question with your legal team before it's load-bearing in your architecture. Microsoft's .NET container deployment guidance is worth reading before you test any native-dependency option in a container, and the .NET imaging discussions on Stack Overflow are a good place to sanity-check edge cases other teams have already hit. The PDFtoImage package documentation is also worth reading directly for its honest notes on the PDFium concurrency model. All code here targets .NET 8 (LTS) and also runs on .NET 10; the in-process and PDFium approaches both benefit from the cross-platform improvements in recent .NET releases, and the .NET support policy is the reference for which version to standardize on. Frequently asked questions How do I convert a PDF to an image in C#? Load the PDF and call a rasterization method. With IronPDF it's pdf.RasterizeToImageFiles("page_*.png"); with a PDFium wrapper like PDFtoImage it's Conversion.ToImage(bytes, page); with Ghostscript-backed Magick.NET you read the PDF with a DPI density and write each page. The one-line call is the same shape everywhere; the library choice is what determines how it behaves in production. What is the best C# library to convert PDF to image? There isn't a single best one. Score your workload against four criteria: native-dependency footprint, thread-safety, DPI/fidelity control, and memory under batch. PDFium wrappers are best for free single-threaded or desktop work; an in-process library like IronPDF is best when you want fidelity and DPI control without a native dependency or concurrency lock; Ghostscript fits if you already run it and have settled its licensing. How do I convert a PDF to PNG in C#? PNG is the default for most of these libraries, since it's lossless and ideal for documents with text and line art. In IronPDF, specifying a .png extension in RasterizeToImageFiles selects the format automatically; in a PDFium wrapper you encode the resulting bitmap as PNG. Use PNG for text-heavy pages and JPEG only when file size matters more than crisp edges. Can I convert a PDF to an image without Ghostscript? Yes. PDFium wrappers and in-process libraries like IronPDF render without Ghostscript entirely, which also sidesteps Ghostscript's AGPL/commercial licensing question. Ghostscript is one option, not a requirement, and for many teams avoiding its native-dependency and licensing overhead is reason enough to choose a different engine. How do I set the DPI or resolution when converting a PDF to an image? Every serious library exposes a DPI parameter. Use roughly 72–96 DPI for thumbnails, 150 for on-screen viewing, and 300 for print or OCR input. Higher DPI means sharper output and larger files (size grows with the square of DPI), so match the resolution to the destination rather than maximizing it. Is PDFium thread-safe in .NET? No. The native PDFium library isn't thread-safe, and wrappers such as PDFtoImage protect all calls with locks, so you process one PDF at a time per process. For true parallelism you run multiple processes and coordinate them, rather than relying on thread-level concurrency within one process. How do I convert just a specific page of a PDF to an image? Pass a page index or range to the rasterization call. IronPDF's ToBitmap(dpi, fromPageIndex, toPageIndex) renders a single page into an in-memory bitmap, which is exactly what a desktop viewer or a preview endpoint needs; PDFium wrappers take a page index on the conversion call. My recommendation, signed After all four criteria, here's where I land, and I'll put my name to it. There's no universal winner, and any honest evaluation has to say that out loud. If you need free rendering and your workload is single-threaded or desktop, use a PDFium wrapper, the fidelity is excellent, the price is zero, and the thread-safety lock won't touch you. If you already run Ghostscript and have settled its licensing and native-dependency story, it's powerful and proven. If you want high fidelity with clean DPI control and you'd rather not own a native dependency or engineer around a concurrency lock, an in-process library like IronPDF earns its license cost in exactly that scenario, and not really outside it. What I'd ask you to take away isn't a product name. It's the four criteria. Rendering a PDF page to an image is a one-liner in all of these libraries; choosing the one that won't surprise you in production is about native dependencies, thread-safety, DPI fidelity, and memory under batch. Score your real workload against those four, test on your own documents, and the right library picks itself. Put It To The Test Ready to see how an in-process, thread-safe renderer handles your toughest, vector-heavy PDFs? Skip the environment configuration and run your own batch test today. Get Started with an IronPDF Free Trial \