QuestPDF excelle lorsque C# est la frontière du produit
QuestPDF mérite une comparaison respectueuse. C’est une bibliothèque moderne de génération PDF pour développeurs C#, avec API fluide, typage fort, documentation large, Companion App pour prévisualiser et déboguer, et un modèle de licence inhabituellement clair pour un SDK PDF.
La question produit n’est pas « lequel peut créer un PDF ? ». Les deux le peuvent. La question utile est où doit vivre la frontière PDF : dans une application .NET qui possède la mise en page, les octets et le cycle de vie, ou comme service d’infrastructure appelé par plusieurs produits et langages.
Guide de décision rapide
- Choisissez QuestPDF quand C# est la source de référence du document, quand l’application doit fonctionner hors ligne ou quand vous avez besoin d’opérations locales sur PDF existants.
- Choisissez gPdf quand une seule couche PDF doit servir Node, Python, Go, .NET, jobs et systèmes régionaux via la même API HTTP.
- Choisissez gPdf quand les changements de mise en page doivent être des révisions de modèle, pas des recompilations C# et redéploiements de service.
Même famille documentaire, modèle de propriété différent
Avec QuestPDF, l’application possède la génération PDF. C’est une vraie force : C# reste près du modèle de domaine, s’exécute et se débogue localement, et aucun appel à une API externe n’a lieu à l’exécution.
La contrepartie est que votre équipe possède aussi le reste du périmètre de production :
- CPU et mémoire pour générer.
- Découverte des polices et secours dans chaque environnement de déploiement.
- Intégration de bibliothèque de codes-barres et QA d’impression.
- Packages natifs et contraintes de déploiement pour graphiques ou intégrations visuelles personnalisées.
- Supervision, réessais et gestion des échecs.
- Déploiement régional quand utilisateurs ou entrepôts sont mondiaux.
- Déploiements à chaque changement de mise en page du document.
Avec gPdf, ce périmètre se déplace vers l’extérieur : l’application envoie un DocumentRequest ou template_id + data, et le service possède le moteur de rendu, l’environnement à l’edge, les polices, les primitives de codes-barres, la sortie PDF/A et l’empaquetage de facture électronique. C’est moins attractif si vous voulez chaque détail en C# ; plus attractif si la génération PDF doit devenir une couche utilitaire appelable depuis n’importe quelle pile.
Trois compromis qu’une API hébergée doit expliquer franchement
La plupart des arguments “bibliothèque vs API” sautent les trois premières questions d’un architecte .NET. Une comparaison honnête les traite explicitement.
1. Où vont les données du document. Cette page parle surtout de factures, relevés et factures électroniques : des documents pleins de noms, adresses, identifiants fiscaux et montants. Avec QuestPDF, ces octets sont construits dans votre processus et ne sortent jamais. L’API publique de gPdf transmet les données du document au moteur de rendu, mais celui-ci est à rétention zéro : le JSON de requête est maintenu dans un isolate V8 de Cloudflare Workers seulement pendant la génération (environ 4 ms typiques) et libéré à la fin de la réponse ; il n’est jamais stocké, journalisé, échantillonné ni utilisé pour l’entraînement, et les journaux opérationnels se limitent au statut HTTP et à la durée (security, DPA). La résidence UE / globale et le déploiement entreprise sur site / privé réduisent ou ferment encore l’exposition. Malgré cela, garder la génération dans le processus sans configuration reste une raison légitime, parfois décisive, pour qu’une équipe finance ou secteur public choisisse QuestPDF.
2. Le mode d’échec. Une bibliothèque n’a pas de tiers susceptible de tomber ; la génération ne peut échouer que sur une infrastructure que vous possédez déjà. Une API hébergée ajoute une dépendance de disponibilité que vous ne contrôlez pas. La bonne façon d’adopter gPdf est de traiter les appels de génération comme tout appel externe : délai d’expiration, réessai, file d’attente et, si possible, alternative en mode dégradé. Si la génération documentaire est sur un chemin synchrone critique, comparez “l’exploiter vous-même” à “dépendre de la disponibilité d’un fournisseur”.
3. Le profil de latence. La génération dans le processus est un appel de fonction sans réseau. Un appel hébergé est un aller-retour réseau. Pour les lots et tâches asynchrones, c’est du bruit. Pour « l’utilisateur clique et le PDF doit apparaître maintenant », l’exécution dans le processus est structurellement plus rapide. Les PoP à l’edge de gPdf réduisent le saut, mais il reste TLS plus un aller-retour ; avec QuestPDF, c’est un appel de méthode.
Rien de tout cela ne rend gPdf mauvais ; cela définit quand il est le bon choix : des équipes dont les données documentaires peuvent sortir du processus, dont les parcours tolèrent un saut réseau et qui préfèrent dépendre de la disponibilité d’un fournisseur plutôt qu’exploiter leur propre flotte de génération.
Modèle de licence et prix
La page publique de licences QuestPDF indique qu’une licence commerciale n’est obligatoire que pour les entreprises dont le chiffre d’affaires annuel brut dépasse 1 million USD. Le niveau Community est gratuit, sous termes MIT, pour les personnes éligibles, projets open-source, organisations à but non lucratif et entreprises sous ce seuil. La même page liste deux niveaux commerciaux perpétuels : Professional à 999 USD plus taxes locales pour équipes jusqu’à 10 développeurs, et Enterprise à 2 999 USD plus taxes locales pour toute l’organisation sans compter les développeurs. Les deux incluent 1 an de mises à jour et projets, serveurs et déploiements illimités ; la licence n’expire pas pour la dernière version reçue.
Le modèle d’application est aussi très léger. La licence se fixe avec une seule ligne : QuestPDF.Settings.License = LicenseType.Community;. Pas de clé de licence, pas de serveur d’activation et, selon la page de configuration de QuestPDF, pas d’appels réseau ni de données qui sortent de la machine. C’est un modèle fondé sur la confiance : vous choisissez le niveau auquel vous êtes éligible. Il n’y a pas de facture fournisseur par document, et une licence payante tourne partout, y compris totalement hors ligne.
gPdf tarife directement le service de génération. Le plan public Basic démarre à 5 USD/mois pour 100 000 pages, avec dépassement à partir de 0,00005 USD par page. C’est une facture fournisseur, mais elle retire aussi le projet séparé d’exploiter la génération PDF : pas de cluster de génération, pas de chemin de déploiement NuGet, pas de groupe régional préchauffé, pas de paquet de polices par application et pas de service PDF à corriger.
La comparaison de coût n’est donc pas “999 USD vs 5 USD” ; la licence est la petite ligne. La vraie comparaison est :
QuestPDF total = licence (paiement unique) + votre hébergement + temps de développement + astreinte
gPdf total = facture par page (infrastructure, polices, montée en charge et exécution à l'edge incluses)Avec le calcul public par page, le dépassement gPdf coûte 0,05 USD par 1 000 pages (50 USD par 1 million, 500 USD par 10 millions). Une licence Enterprise unique de 2 999 USD ne rejoint cette facture qu’autour de 60 millions de pages, et ce chiffre ignore l’hébergement et les mois d’ingénierie de QuestPDF, qui repoussent le croisement réel plus loin en faveur de gPdf sauf si vous exploitez déjà l’infrastructure de génération à très bas coût. Règle pratique : si vous devriez construire et doter en personnel un service de génération seulement pour utiliser la bibliothèque, gPdf gagne souvent en coût total bien avant que la facture par page rattrape la licence ; si cette infrastructure existe déjà et vous coûte presque rien, la licence perpétuelle gagne à l’échelle.
Mode de développement : C# fluide vs modèles
L’API fluide de QuestPDF convient quand les développeurs possèdent la forme du document. Typage fort, chaînes de méthodes, composants C# réutilisables, refactorisations dans l’IDE et Companion App ont du sens quand le PDF fait partie du code applicatif.
gPdf correspond à un autre mode de travail. Les développeurs peuvent toujours écrire du JSON directement, mais les systèmes de production évoluent souvent vers des modèles. Un designer, opérateur ou ingénieur ajuste la mise en page dans gPdf Studio. La mise en page approuvée devient un modèle, et le serveur continue de générer via template_id + data.
Cette différence compte quand le document change souvent. Si une étiquette transporteur, une facture, un bon de préparation ou un relevé change, gPdf peut garder l’environnement d’exécution stable et ne déplacer que le modèle. Avec QuestPDF, la mise en page est du code C# ; le chemin normal est donc changement de code, tests, compilation, déploiement et plan de retour arrière.
Aucun mode n’est universellement meilleur : QuestPDF optimise pour les développeurs C# qui veulent le document comme code ; gPdf pour des modèles opérationnels partagés entre systèmes.
Conformité : les deux produits sont sérieux
Ce n’est pas une comparaison où gPdf gagne en disant que le concurrent manque de fonctionnalités de conformité. La documentation publique actuelle de QuestPDF liste une prise en charge solide des standards, notamment PDF/A, PDF/UA-1 et facturation électronique EN 16931 via un exemple ZUGFeRD 2.1 / Factur-X basé sur le standard UN/CEFACT Cross Industry Invoice (CII). Cet exemple définit PdfA = true, intègre le fichier factur-x.xml avec AddAttachment(), étend le document avec des métadonnées XMP et valide le résultat avec veraPDF (pour PDF/A-3b) et Mustang Project (pour ZUGFeRD). C’est une recette complète et honnête, et votre chaîne possède chaque étape.
gPdf empaquette les mêmes standards comme contrat API. JSON Render expose six profils PDF/A (1b, 2b, 3b, 4, 2u, 3u) plus PDF/UA-1 via settings.profile, Template Render réutilise le même modèle documentaire, et E-Invoice Render expose une route dédiée POST /api/v1/e-invoice/render qui produit des paquets Factur-X / ZUGFeRD PDF/A-3b avec XML EN 16931 CII intégré. La différence face à la recette QuestPDF est ce que le service fait pour vous : gPdf exécute la validation PDF/A-3b et facture électronique côté serveur, prend en charge une livraison synchrone en réponse directe ou par objet consulté, et propose résidence UE ou globale comme options de requête, pas comme étapes à assembler et exploiter. QuestPDF convient quand cette validation doit vivre dans votre chaîne .NET ; gPdf quand elle doit être un contrat hébergé partagé par de nombreux systèmes.
Polices et codes-barres : l’effort d’intégration est la vraie comparaison
QuestPDF a un modèle de polices capable. Il embarque Lato 2.015 par défaut, charge automatiquement polices système et polices du répertoire de déploiement, permet d’enregistrer des polices personnalisées via FontManager et prend en charge les chaînes de secours. Cela donne du contrôle aux développeurs. Mais la même documentation est franche sur le piège : dans la plupart des déploiements cloud, peu ou pas de polices sont disponibles, ce qui peut produire des résultats inattendus ; elle recommande de désactiver les polices d’environnement et d’enregistrer explicitement ce dont vous avez besoin. Autrement dit, en conteneur ou en environnement serverless, l’environnement de polices est à vous de le planifier, l’empaqueter et le tester ; un glyphe manquant devient un caractère de remplacement ou, si vous activez CheckIfAllTextGlyphsAreAvailable, une exception.
gPdf fait des polices une partie de la frontière du service. Le moteur de rendu embarque un jeu multi-écritures : latin, grec, cyrillique, arabe, hébreu, bengali, tamoul, thaï, vietnamien, monoespacement et CJK avec secours par écriture vers Noto KR / JP / SC. Il résout les choix silencieux par sélection automatique implicite et les choix explicites par prefer ou strict. Les appelants n’expédient pas de police CJK, n’enregistrent pas de ressources Noto dans une application .NET et n’ajustent pas le secours par cible de déploiement. Ils envoient des données ; le service possède l’environnement de polices, identique dans chaque région.
La comparaison codes-barres a une forme similaire. La documentation QuestPDF montre une approche solide avec ZXing.Net converti en SVG vectoriel, et précise que ZXing.Net n’est pas inclus dans le package QuestPDF : vous l’installez depuis NuGet et le câblez :
// 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.Avec gPdf, la génération de codes-barres est un élément de schéma de première classe. La requête déclare format, contenu, taille physique et ligne lisible optionnelle ; les formats GS1 sont natifs, donc les identifiants d’application vont directement dans 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" }
}Pour une seule application .NET, installer ZXing.Net et tester la sortie peut être simple. Pour de nombreux services et modèles, surtout en logistique et commerce de détail avec GS1-128, SSCC, GTIN, GS1 DataMatrix ou GS1 QR et ligne d’interprétation lisible, déplacer le comportement codes-barres dans l’API documentaire est plus maintenable que recâbler ZXing dans chaque service.
Là où QuestPDF gagne clairement
Au-delà de l’exécution hors ligne, du maintien des données dans votre périmètre et des cas où le code PDF fait partie du produit, c’est-à-dire quand une équipe doit inspecter, étendre ou posséder le chemin de génération, QuestPDF conserve deux domaines clairement hors périmètre gPdf :
- Opérations sur PDF existants. QuestPDF peut charger des fichiers existants et les fusionner, sélectionner / réordonner / inverser / filtrer des pages, appliquer des superpositions, ajouter des pièces jointes, définir des métadonnées XMP, linéariser pour le web et chiffrer et déchiffrer en 40/128/256 bits. gPdf peut protéger par mot de passe et permissions les PDF qu’il génère, mais il n’ouvre, ne fusionne ni ne déchiffre les fichiers qu’il n’a pas créés.
- Graphiques, cartes et graphismes personnalisés. QuestPDF intègre des bibliothèques de graphiques (ScottPlot, LiveCharts, Microcharts), embarque des cartes Mapbox et expose un Canvas SkiaSharp pour dessin 2D arbitraire. gPdf peut dessiner du vectoriel avec l’élément
path(SVG path data) ou intégrer un graphique SVG / PNG produit en amont, mais il n’a pas de moteur graphique, cartes ou Canvas intégrés ; si la visualisation de données est centrale, cet outillage vit mieux avec QuestPDF.
Là où gPdf gagne clairement
gPdf gagne lorsqu’une organisation ne veut pas que chaque équipe produit exploite son propre service PDF : piles polyglottes, parcours mondiaux et systèmes ERP / OMS / WMS / e-commerce / fintech / billetterie qui génèrent des documents depuis des données structurées, avec des modèles qui changent indépendamment du code. Dans ces environnements, une bibliothèque locale commence souvent bon marché et devient une flotte : un service par langage, un chemin de déploiement par région, un plan de polices par conteneur, un jeu de régressions codes-barres par équipe. gPdf transforme cette flotte en un contrat HTTP.
Le serverless rend la frontière très nette. Sur AWS Lambda, Cloud Run ou Azure Functions, QuestPDF tourne toujours dans l’application : votre équipe empaquette l’environnement .NET, les polices, les dépendances natives et assez de CPU / mémoire pour les pics PDF, et elle possède les démarrages à froid. gPdf est déjà le service de génération : la fonction envoie par POST une petite requête template_id + data à l’edge et reçoit les octets PDF, sans moteur de rendu à préchauffer ni worker régional à mettre à l’échelle.
Forme de migration
La migration de QuestPDF vers gPdf n’est pas une réécriture ligne à ligne. C’est un changement de frontière : le code C# qui construit le PDF devient soit une requête JSON de document, soit un modèle publié.
Before / after — l'appel C# de construction de document se réduit à un HTTP POST (cliquez pour développer)
- // 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();Après ce déplacement de frontière, les changements de mise en page peuvent devenir des révisions de modèle au lieu de déploiements applicatifs. L’application reste propriétaire des données métier et des décisions de parcours ; gPdf possède la génération.
Note sur prix et sources
Les informations QuestPDF de cette page ont été vérifiées le 2026-06-02 auprès de sources officielles QuestPDF : License and Pricing, License configuration, Features Overview, Companion App features, Barcodes, Font management et ZUGFeRD example. Les pages de prix et fonctionnalités peuvent changer ; les équipes achats doivent revérifier la page fournisseur avant décision. QuestPDF et les marques associées appartiennent à leurs propriétaires respectifs, et cette comparaison n’est pas approuvée par eux.
Scénarios liés de génération PDF
Si vous comparez QuestPDF et gPdf, examinez aussi quand une API JSON-to-PDF, une API de PDF de facture, une API d’étiquettes d’expédition, des codes-barres GS1-128, PDF/A ou Factur-X/ZUGFeRD doivent devenir une capacité partagée plutôt qu’une bibliothèque exploitée dans chaque application.
FAQ
gPdf remplace-t-il QuestPDF ?
Non. gPdf remplace le besoin d’exploiter un service de génération PDF pour des documents métier structurés. QuestPDF reste une solide bibliothèque C# locale quand le PDF doit être généré dans l’application.
QuestPDF est-il gratuit ?
La page publique de licences QuestPDF indique que le niveau Community est gratuit sous termes MIT pour personnes éligibles, projets open-source, organisations à but non lucratif et entreprises sous 1 million USD de chiffre d’affaires annuel brut. Les entreprises au-dessus de ce seuil doivent utiliser une licence commerciale perpétuelle : Professional à 999 USD plus taxes locales jusqu’à 10 développeurs, ou Enterprise à 2 999 USD plus taxes locales pour toute l’organisation, chacune incluant 1 an de mises à jour.
gPdf peut-il générer des graphiques ou cartes comme QuestPDF ?
Pas comme moteur intégré. QuestPDF intègre des bibliothèques de graphiques (ScottPlot, LiveCharts, Microcharts), des cartes Mapbox et un Canvas SkiaSharp qui rend dans le document. gPdf peut tout de même dessiner des graphiques vectoriels avec l’élément path (qui accepte SVG path data) et des formes, ou intégrer un SVG / PNG produit par n’importe quelle bibliothèque comme image. La différence est que QuestPDF calcule et rend le graphique dans le processus, tandis qu’avec gPdf vous produisez le visuel et gPdf le place. Si les graphiques basés sur données ou les cartes sont centraux dans le document, QuestPDF convient mieux.
Quel produit coûte le moins cher ?
Cela dépend de la frontière. QuestPDF peut coûter moins cher pour des équipes .NET éligibles aux termes Community ou qui exploitent déjà l’infrastructure de génération. gPdf peut coûter moins cher quand l’alternative consiste à construire, héberger et maintenir un service PDF entre produits ou régions.
gPdf stocke-t-il ou journalise-t-il mes données documentaires ?
Non. Le JSON que vous envoyez et le PDF retourné par gPdf ne sont pas stockés. Chaque requête est générée dans un isolate V8 Cloudflare Workers, conservée en mémoire seulement pendant la génération, environ 4 ms typiques, puis libérée quand le flux de réponse se termine ; gPdf ne retient, ne journalise, n’échantillonne ni n’entraîne sur le contenu DocumentRequest. Les journaux opérationnels conservent seulement statut HTTP et durée pendant 30 jours, sans corps de requête. Consultez la politique de sécurité, la politique de confidentialité et le DPA. Pour les charges qui ne peuvent transmettre aucune donnée, un déploiement sur site / privé les garde dans votre périmètre.
QuestPDF peut-il fonctionner sans accès Internet ?
Oui. La page de configuration de licence QuestPDF indique qu’il n’y a pas de clé de licence ni serveur d’activation, et que les calculs sont effectués localement. C’est l’une des raisons les plus nettes de choisir QuestPDF.
gPdf peut-il générer des mises en page QuestPDF C# arbitraires ?
Non. gPdf n’exécute pas de code de mise en page C#. Une migration implique de convertir la forme du document en requête JSON gPdf ou en modèle gPdf enregistré.