QuestPDF is excellent when C# is the product boundary
QuestPDF deserves a respectful comparison. It is a modern PDF generation library for C# developers, with a fluent API, strong typing, a large documentation surface, a Companion App for preview and debugging, and a licensing model that is unusually clear for a PDF SDK.
The product question is not “which one can create a PDF?” Both can. The useful question is where the PDF boundary should live: inside a .NET application that owns the layout, bytes, and lifecycle, or as an infrastructure service that multiple products and languages call.
Quick decision guide
- Pick QuestPDF when C# is the document source of truth, the app must run offline, or you need local operations on existing PDFs.
- Pick gPdf when one PDF layer should serve Node, Python, Go, .NET, jobs, and regional systems through the same HTTP API.
- Pick gPdf when layout changes should be template revisions, not C# rebuilds and service redeploys.
Same document family, different ownership model
With QuestPDF the application owns PDF generation — a real strength: C# kept near your domain model, run and debugged locally, with no runtime call to an external API.
The trade-off is that your team also owns the rest of the production surface:
- CPU and memory for rendering.
- Font discovery and fallback in each deployment environment.
- Barcode library integration and print QA.
- Native package and deployment concerns for charting or custom graphics integrations.
- Monitoring, retries, and failure handling.
- Regional deployment when users or warehouses are global.
- Rollouts whenever the document layout changes.
With gPdf, that surface moves outward: the application sends a DocumentRequest or template_id + data, and the service owns the renderer, edge runtime, fonts, barcode primitives, PDF/A output, and e-invoice packaging — less attractive if you want every detail in C#, more attractive if PDF generation should be a utility layer callable from any stack.
Three trade-offs a hosted API has to answer honestly
Most “library vs API” pitches skip the three questions a .NET architect asks first. A fair comparison answers them out loud.
1. Where the document data goes. This page is largely about invoices, statements, and e-invoices — documents full of names, addresses, tax IDs, and amounts. With QuestPDF those bytes are built inside your process and never leave. The public gPdf API transmits the payload to the renderer, but the renderer is zero-retention: the request JSON is held in a Cloudflare Workers V8 isolate only for the render (~4 ms typical) and released when the response completes — never stored, logged, sampled, or trained on, with operational logs limited to HTTP status and duration (security, DPA). EU / global data-residency selection and enterprise on-prem / private deployment narrow or close the exposure further. Even so, keeping generation in-process with zero setup is a legitimate — sometimes decisive — reason a finance or public-sector team picks QuestPDF.
2. The failure mode. A library has no third party that can go down; generation can only fail on infrastructure you already own. A hosted API adds an availability dependency you do not control. The right way to adopt gPdf is to treat render calls like any other external call — timeout, retry, queue, and ideally a degraded-mode fallback. If document generation sits on a critical synchronous path, weigh “operate it yourself” against “depend on a vendor’s uptime.”
3. The latency profile. In-process generation is a function call with no network. A hosted call is a network round-trip. For batch and async jobs this is noise. For “user clicks, the PDF must appear now,” in-process is structurally faster — gPdf’s edge PoPs make the hop small, but it is still TLS plus a round-trip, where QuestPDF’s is a method call.
None of these makes gPdf the wrong choice; they define when it is the right one — for teams whose document data can leave the process, whose flows tolerate a network hop, and who would rather depend on a vendor’s uptime than operate a render fleet themselves.
Licensing and price model
QuestPDF’s public licensing page says a commercial license is required only for companies above $1M USD in annual gross revenue. The Community tier is free for eligible individuals, open-source projects, non-profits, and companies below that revenue threshold, under MIT terms. The same public page lists two perpetual commercial tiers: Professional at $999 plus local tax for teams of up to 10 developers, and Enterprise at $2,999 plus local tax covering an entire organization with no developer counting. Both include one year of updates and unlimited projects, servers, and deployments, and the license never expires for the last version received.
The enforcement model is also unusually light. The license is set with a single line — QuestPDF.Settings.License = LicenseType.Community; — with no license key, no activation server, and, per QuestPDF’s own configuration page, no network calls and no data leaving the machine. It is an honor-system model: you select the tier you are eligible for. There is no per-document vendor bill, and a paid license runs anywhere, including fully offline.
gPdf prices the rendering service directly. The public Basic plan starts at $5/month for 100K pages, with overage starting at $0.00005/page. That is a vendor bill, but it also removes the separate project of operating PDF generation: no render cluster, no NuGet deployment path, no regional warm pool, no font package per app, and no PDF service to patch.
So the cost comparison is not “$999 vs $5” — the license is the small line. The real comparison is:
QuestPDF total = license (one-time) + your hosting + your engineer-time + on-call
gPdf total = page bill (infrastructure, fonts, scaling, and edge included)At the public per-page math, gPdf overage is $0.05 per 1,000 pages ($50 per 1M, $500 per 10M). A one-time $2,999 Enterprise license only breaks even against that bill near ~60M pages — and that figure ignores QuestPDF’s hosting and engineer-months, which push the real crossover much further in gPdf’s favour unless you already run the render infrastructure cheaply. The rule of thumb: if you would have to build and staff a render service just to use the library, gPdf usually wins on total cost long before the per-page bill catches the license; if that infrastructure already exists and is nearly free to you, the perpetual license wins at scale.
Development workflow: Fluent C# vs templates
QuestPDF’s fluent API is a good fit when developers own the document shape. Strong typing, method chains, reusable C# components, IDE refactors, and the Companion App all make sense when the PDF is part of the application codebase.
gPdf fits a different workflow. Developers can still author JSON directly, but production systems usually move toward templates. A designer, operator, or engineer adjusts layout in gPdf Studio. The approved layout becomes a template, and the backend keeps rendering with template_id + data.
That difference matters when the document changes often. If a carrier label, invoice, packing slip, or statement layout changes, gPdf can keep the runtime stable while only the template moves. With QuestPDF, the layout is C# code, so the normal path is a code change, test, build, deploy, and rollback plan.
Neither workflow is universally better: QuestPDF optimizes for C# developers who want the document as code; gPdf for operational templates shared across systems.
Compliance: both products are serious
This is not a comparison where gPdf wins by saying the competitor lacks compliance features. QuestPDF’s current public material lists strong standards support, including PDF/A, PDF/UA-1, and EN 16931 e-invoicing through a ZUGFeRD 2.1 / Factur-X example built on the UN/CEFACT Cross Industry Invoice (CII) standard. That example sets PdfA = true, embeds the factur-x.xml payload with AddAttachment(), extends the document with XMP metadata, and validates the result with veraPDF (for PDF/A-3b) and the Mustang Project (for ZUGFeRD). It is a complete, honest recipe — and your pipeline owns every step of it.
gPdf packages the same standards as an API contract. JSON Render exposes six PDF/A profiles (1b, 2b, 3b, 4, 2u, 3u) plus PDF/UA-1 through settings.profile, Template Render reuses the same document model, and E-Invoice Render exposes a dedicated POST /api/v1/e-invoice/render endpoint that produces Factur-X / ZUGFeRD PDF/A-3b packages with embedded EN 16931 CII XML. The difference from the QuestPDF recipe is what the service does for you: gPdf runs the PDF/A-3b and e-invoice validation server-side, supports synchronous inline or polled object delivery, and offers EU or global data residency as request settings rather than steps you assemble and operate. QuestPDF fits when that validation should live inside your own .NET pipeline; gPdf when it should be a hosted contract many systems share.
Fonts and barcodes: integration effort is the real comparison
QuestPDF has a capable font model. It ships Lato 2.015 by default, auto-loads system and deployment-directory fonts, lets you register custom fonts through FontManager, and supports fallback chains. That gives developers control. But the same documentation is candid about the catch: “in most cloud deployments, few or no fonts are available, which may lead to unexpected results,” and it recommends disabling environment fonts and explicitly registering what you need. In other words, on a container or serverless target the font environment is yours to plan, ship, and test — and a missing glyph either becomes a placeholder character or, if you enable CheckIfAllTextGlyphsAreAvailable, a thrown exception.
gPdf makes fonts part of the service boundary. The renderer bundles a multi-script set — Latin, Greek, Cyrillic, Arabic, Hebrew, Bengali, Tamil, Thai, Vietnamese, monospace, and CJK with per-script fallback to Noto KR / JP / SC. It resolves silent font choices through implicit auto selection, and explicit choices through prefer or strict. Callers do not ship a CJK font, register Noto assets in a .NET app, or tune fallback per deployment target. They send data; the renderer owns the font environment, the same in every region.
The barcode comparison has a similar shape. QuestPDF’s barcode docs show a solid approach using ZXing.Net rendered as vector SVG, and they explicitly note that ZXing.Net is not included in the QuestPDF package — you install it from NuGet and wire it in:
// QuestPDF: add the separate ZXing.Net package, encode, render to SVG, embed.
// dotnet add package ZXing.Net
var writer = new ZXing.BarcodeWriterSvg {
Format = ZXing.BarcodeFormat.CODE_128,
Options = new ZXing.Common.EncodingOptions { Width = 320, Height = 80 }
};
string svg = writer.Write("INV-2026-001").Content;
container.Svg(svg);
// GS1-128 with Application Identifiers and FNC1 framing is hand-wired on top.With gPdf, barcode generation is a first-class schema element. The request declares the format, content, physical size, and an optional human-readable line — and GS1 formats are native, so Application Identifiers go straight into content:
{
"type": "barcode",
"format": "gs1_128",
"content": "(01)00012345678905(21)SN12345",
"x": 12, "y": 60, "width": 80, "height": 18,
"barcode_text": { "enabled": true, "position": "bottom" }
}For one .NET app, installing ZXing.Net and testing the output may be easy. For many services and templates — especially logistics and retail workloads that need GS1-128, SSCC, GTIN, GS1 DataMatrix, or GS1 QR with the human-readable interpretation line — pushing barcode behavior into the document API is simpler to maintain than re-implementing the same ZXing wiring in every service.
Where QuestPDF clearly wins
Beyond running offline and keeping document data inside your perimeter (covered above), and when the PDF code itself is part of the product — a team that needs to inspect, extend, or own the rendering path — QuestPDF holds two capability areas squarely outside gPdf’s scope:
- Operations on existing PDFs. QuestPDF can load existing files and merge them, select / reorder / reverse / filter pages, apply overlays, add attachments, set XMP metadata, linearize for web delivery, and both encrypt and decrypt with 40/128/256-bit security. gPdf can password-protect and permission-gate the PDFs it generates, but it does not open, merge, or decrypt files it did not create.
- Charts, maps, and custom graphics. QuestPDF integrates charting libraries (ScottPlot, LiveCharts, Microcharts), embeds Mapbox maps, and exposes a SkiaSharp canvas for arbitrary 2D drawing. gPdf can draw vector art with the
pathelement (SVG path data) or embed an SVG / PNG chart produced upstream, but it has no built-in charting engine, maps, or canvas — so if data-driven charting is central, that tooling lives with QuestPDF.
Where gPdf clearly wins
gPdf wins when an organization does not want every product team to own its own PDF service — polyglot stacks, global workflows, and ERP / OMS / WMS / ecommerce / fintech / ticketing systems rendering documents from structured data, with templates that change independently of code. In those environments a local library often starts cheap and becomes a fleet: one service per language, one deployment path per region, one font plan per container, one set of barcode regressions per team. gPdf turns that fleet into one HTTP contract.
Serverless makes the boundary clearest. On AWS Lambda, Cloud Run, or Azure Functions, QuestPDF still runs inside the application — your team packages the .NET runtime, fonts, native dependencies, and enough CPU / memory for peak PDF work, and owns the cold starts. gPdf is already the render service: the function POSTs a small template_id + data request to the edge and gets PDF bytes back, with no renderer to warm or per-region worker to scale.
Migration shape
The migration from QuestPDF to gPdf is not a line-for-line rewrite. It is a boundary change: the C# code that builds the PDF becomes either a JSON document request or a published template.
Before / after — the C# document-build call collapses to one HTTP POST (click to expand)
- // Before: generate the PDF inside a .NET application.
- Document.Create(container =>
- {
- container.Page(page =>
- {
- page.Size(PageSizes.A4);
- page.Margin(30);
- page.Header().Text("Invoice").FontSize(24).SemiBold();
- page.Content().Column(column =>
- {
- column.Item().Text($"Invoice number: {invoice.Number}");
- column.Item().Text($"Total: {invoice.Total:C}");
- });
- });
- })
- .GeneratePdf("invoice.pdf");
+
+ // After: render through the shared gPdf template from C#.
+ using System.Net.Http.Headers;
+ using System.Net.Http.Json;
+
+ using var client = new HttpClient();
+ client.DefaultRequestHeaders.Authorization =
+ new AuthenticationHeaderValue("Bearer", key);
+
+ var response = await client.PostAsJsonAsync(
+ "https://api.gpdf.com/api/v1/template-render",
+ new {
+ template_id = "invoice-v2",
+ data = new {
+ invoice_number = invoice.Number,
+ total = invoice.Total,
+ currency = invoice.Currency
+ }
+ });
+
+ response.EnsureSuccessStatusCode();
+ byte[] pdfBytes = await response.Content.ReadAsByteArrayAsync();After that boundary moves, layout changes can become template revisions instead of application deployments. The application still owns business data and workflow decisions; gPdf owns rendering.
Pricing and sourcing note
QuestPDF information on this page was checked on 2026-06-02 against official QuestPDF sources: License and Pricing, License configuration, Features Overview, Companion App features, Barcodes, Font management, and ZUGFeRD example. Pricing and feature pages can change; procurement teams should re-check the vendor page before making a buying decision. QuestPDF and related marks belong to their respective owners, and this comparison is not endorsed by them.
Related PDF generation scenarios
Teams comparing QuestPDF and gPdf often search for QuestPDF alternatives, QuestPDF commercial license cost, .NET PDF generation API, C# invoice PDF generation, hosted PDF API for .NET, JSON to PDF API, PDF/A API, ZUGFeRD API, Factur-X API, GS1-128 barcode API, barcode PDF generation, QuestPDF cloud fonts, shipping label PDF API, and PDF generation without operating a render service.
FAQ
Does gPdf replace QuestPDF?
No. gPdf replaces the need to operate a PDF generation service for structured business documents. QuestPDF remains a strong local C# library when the PDF should be generated inside the application.
Is QuestPDF free?
QuestPDF’s public licensing page says the Community tier is free under MIT terms for eligible individuals, open-source projects, non-profits, and companies under $1M USD annual gross revenue. Companies above that threshold need a perpetual commercial license: Professional at $999 plus local tax for up to 10 developers, or Enterprise at $2,999 plus local tax organization-wide, each including one year of updates.
Can gPdf generate charts or maps like QuestPDF?
Not as a built-in engine. QuestPDF integrates charting libraries (ScottPlot, LiveCharts, Microcharts), Mapbox maps, and a SkiaSharp canvas that render in-document. gPdf can still draw vector charts with the path element (which accepts SVG path data) and shapes, or embed an SVG / PNG produced by any charting library as an image. The difference is that QuestPDF computes and renders the chart in-process, whereas with gPdf you produce the chart art and gPdf places it. If data-driven charting or maps are central to the document, QuestPDF is the better fit.
Which product is cheaper?
It depends on the boundary. QuestPDF can be cheaper for .NET teams that are eligible for Community terms or that already operate the render infrastructure. gPdf can be cheaper when the alternative is building, hosting, and maintaining a PDF service across products or regions.
Does gPdf store or log my document data?
No. The JSON you send and the PDF gPdf returns are not stored. Each request renders inside a single Cloudflare Workers V8 isolate, held in memory only for the render — about 4 ms typically — and released when the response stream completes; gPdf does not retain, log, sample, or train on DocumentRequest content. Operational logs keep only HTTP status and duration for 30 days and contain no request bodies. See the security policy, privacy policy, and DPA. For workloads that cannot transmit data at all, on-prem / private deployment keeps it inside your perimeter.
Can QuestPDF run without internet access?
Yes. QuestPDF’s license configuration page says there is no license key or activation server, and computations are performed locally. That is one of the clearest reasons to pick QuestPDF.
Can gPdf render arbitrary C# QuestPDF layouts?
No. gPdf does not execute C# layout code. A migration means converting the document shape into a gPdf JSON request or a saved gPdf template.