Papyra and the .NET reporting landscape
Most .NET reporting products are not competitors to Papyra - they are a different category solving a different problem. This page says which one you need, including the cases where the answer is not Papyra.
The short answer
Two categories, one question
Ask who owns the report. If the answer is a business user with a designer, you want a reporting suite. If the answer is a developer with a repository, you want a document engine.
Reporting suite
DevExpress Reporting, Telerik Reporting, Stimulsoft, FastReport, ActiveReports, Syncfusion
A report is a template bound to a data source. Someone designs it in a visual designer - often at runtime, often not a developer - the engine binds parameters, runs the query, lays out bands, and a viewer control shows the result inside your app with print and export buttons. Charts, barcodes, cross-tabs and subreports come in the box; a report server schedules and delivers.
You are buying a product with a UI. That is a large surface, and it is worth paying for when the people who need to change a report are not the people who deploy the application.
Code-first document engine
Papyra, QuestPDF, MigraDoc
A document is a function of your data. You compose it with a fluent API, the layout engine measures and paginates, and each renderer emits bytes. There is no designer, no template file, no viewer control - the document is source code, so it is reviewed, diffed, tested and refactored like the rest of your application.
You are buying a library with no UI. The surface is small on purpose: it does the typography and pagination, and your code does everything else.
In fairness
What the suites do that Papyra doesn't
This table is stacked against us, and accurately so. If you need a report designer, declarative data binding, a viewer control or a report server, buy the suite - no amount of fluent API makes up for them.
SupportedPartly supportedHandled differentlyNot supported
| Capability | Reporting suites | Papyra |
|---|---|---|
| End-user report designer | Supported: Web + desktop, embeddable | Partly supported: Designer app (beta), for developers |
| Report stored as a template file | Supported: XML / binary, edited without a rebuild | Handled differently: C# source, compiled with your app |
| Built-in data binding | Supported: SQL, EF, OData, JSON, objects | Handled differently: You pass your own objects |
| Parameters + expression language | Supported: Yes, plus scripting | Handled differently: Plain C# |
| Charts, gauges, barcodes, maps | Supported: Yes | Not supported: No - bring your own image |
| Cross-tabs, subreports, drill-down | Supported: Yes | Not supported: Nested tables only |
| Embeddable report viewer control | Supported: Blazor, Angular, React, WPF, WinForms | Not supported: No - you get bytes, you serve them |
| Report server: scheduling, delivery | Partly supported: Separate product or add-on | Not supported: No |
| PDF, DOCX, XLSX, HTML output | Supported: Export of a rendered report | Supported: A native renderer per format |
| PDF/A archival output | Partly supported: Available in several suites | Supported: 2b default, 3b/4 opt-in, veraPDF-verified |
| Free tier | Partly supported: Syncfusion Community, revenue-capped; FastReport OSS is MIT but feature-reduced | Supported: Free under $1M revenue, no feature gates |
Capabilities vary between the six suites; the column describes what the category offers, not a guarantee for every product in it. The older members of the same category - SAP Crystal Reports, and RDLC with Microsoft's Report Viewer - sit on the same side of the line. Papyra's own gaps are listed on theknown limitations page and theroadmap.
The other direction
Where Papyra earns its place
Four renderers, not four exporters
A suite renders a report and then serializes that rendering to Word or Excel. Papyra runs a separate renderer per format off one layout tree - DOCX gets real sections and TOC fields, XLSX gets worksheets and anchored drawings. Your composition code never branches.
Archival PDF as the default
PDF/A-2b out of the box, PDF/A-3b and PDF/A-4 on request, with embedded subsetted fonts, an sRGB output intent and a consistent XMP packet. Every supported standard is validated against veraPDF in the test suite - and ZUGFeRD/Factur-X hybrid invoices come from the same switch.
Three NuGet packages, no native binaries
The PDF writer is ours: objects, cross-reference tables and content streams, emitted directly. Nothing to ship per RID, nothing to install in a container, no headless browser to keep alive. It deploys wherever .NET deploys.
Documents that live in git
A report is C#: reviewable in a pull request, diffable line by line, unit-testable against a golden file, refactorable by the compiler. There is no binary template to merge and no designer version to keep in step with the runtime.
Like for like
Against the other document libraries
Here the comparison is fair, because everything in this table is a library a developer drives from code. Coming from QuestPDF specifically, themigration guide maps every concept.
| Papyra | QuestPDF | PDFsharp / MigraDoc | iText | Aspose.PDF | IronPDF | |
|---|---|---|---|---|---|---|
| Composition model | Fluent, code-first | Fluent, code-first | Object model (MigraDoc) | Low-level PDF + add-ons | PDF object model | HTML/CSS → PDF |
| PDF engine | Own writer, pure managed | SkiaSharp | Own, managed | Own, managed | Own, managed | Chromium + PDFium |
| Native binaries to deploy | None | SkiaSharp | None | None | None | Chrome + PDFium (hundreds of MB) |
| DOCX / XLSX from the same model | Yes, built in | No (PDF + images) | RTF only | No | Separate products | Separate products |
| PDF/A | 2b / 3b / 4, veraPDF-verified | Optional setting | Not built in | Optional | Optional | PDF/A-3b conversion |
| Entry license | Free under $1M revenue | Free under $1M revenue | MIT, free | AGPL or commercial quote | from $1,199 perpetual | from $999 perpetual |
“Optional” means the library offers the capability, usually through a setting or an add-on module - not that it is absent. Papyra's PDF/A conformance is the only entry here we validate ourselves, against veraPDF, on every build.
FAQ
Questions we get asked
Is Papyra an alternative to DevExpress Reporting or Telerik Reporting?
Only partly. DevExpress Reporting, Telerik Reporting, Stimulsoft, FastReport and ActiveReports are banded reporting suites with an end-user designer, data binding, charts and embeddable viewers. Papyra is a code-first document engine: your C# is the report. If business users must design or edit reports, buy a suite. If developers own the document and you need PDF/A, DOCX, XLSX and HTML from one model, Papyra fits.
How does Papyra compare to QuestPDF, iText, Aspose.PDF and IronPDF?
All of those are document libraries rather than reporting suites. Papyra differs by rendering the same document model to PDF, DOCX, XLSX and HTML, by writing PDF/A-2b, 3b and 4 verified against veraPDF on every build, and by shipping three managed NuGet dependencies with no native binaries - no SkiaSharp, no bundled Chromium.
Can Papyra replace a report designer for our business users?
No. The Designer app is a beta desktop tool for developers: you compose visually and copy the generated C# into your project. It is not an embeddable runtime editor, and reports it produces are compiled with your application rather than loaded from a template file.
Do we still need a reporting suite licence if we use Papyra?
Only for what Papyra does not do: charts, barcodes, cross-tabs, subreports, an end-user designer, a viewer control or a report server. Teams that need those usually keep the suite for interactive reporting and use Papyra for the documents the system generates unattended - invoices, statements, archival PDF/A and e-invoices.
Buy the other one
When Papyra is the wrong answer
We would rather you find that out here than three sprints in.
- Business users design or edit the reports. An embeddable end-user designer is the whole reason those suites exist. Papyra's Designer app is a beta tool for developers that emits C# to paste into your project - not a runtime editor.
- The report is a query. If what you want is “point it at this SQL, add these parameters, group by region,” a banded engine does that declaratively. In Papyra you write the query and the loop yourself.
- You need charts, gauges, barcodes or maps. Papyra draws text, tables, rules and images. Anything else has to arrive as an image you rendered elsewhere.
- Users must preview and print inside your app. There is no viewer control. Papyra hands you a
byte[]; serving, embedding and printing it is yours. - You are converting existing PDFs. Papyra writes documents, it does not read, merge, sign, redact or OCR them. That is what iText and Aspose.PDF are for.