XtraReports, HTML, and Where the Layout Should Live

The XtraReports designer is an excellent piece of software, which makes choosing difficult. The real question isn't whether it can layout a page, but rather who still uses it and the cost of extracting a .repx layout from a suite that only DevExpress tools can read.

So the honest way to compare DevExpress XtraReports against a code-first library like IronPDF is not a feature grid. It is what each option adds to your deployment, what it charges every year to stay current, and what it costs to walk away from once the person who drew the reports has moved to another team. Those three numbers outlast any single release.

For transparency, our team at Iron Software builds IronPDF. This looks at architecture and long-term cost, and we flag where XtraReports is the stronger choice.

One naming point clears up before anything else, because it derails half the searches on this topic. DevExpress now sells and documents the product as DevExpress Reporting, yet the class a developer instantiates is still XtraReport in the DevExpress.XtraReports.UI namespace, the vendor docs still live under docs.devexpress.com/XtraReports/, and the .repx designer format never changed name. A hunt for an XtraReports alternative is not a hunt for a dead product. It is the same engine DevExpress ships today wearing branding that moved while the codebase stayed put.

The smallest thing worth looking at first is what a server actually runs when IronPDF turns data into a report, because the deployment surface is right there in the C# PDF reports workflow. The layout language is HTML and CSS, so a monthly usage report is a handful of lines with no canvas to pin anything to.

// dotnet add package IronPdf
using IronPdf;

var renderer = new ChromePdfRenderer();
PdfDocument report = renderer.RenderHtmlAsPdf(
    "<h1>Monthly Usage Report</h1><p>No .repx file, no designer, just markup the team already owns.</p>");
report.SaveAs("usage-report.pdf");

Nothing else ships beside that. There is no .repx definition to version in source control, no report designer that has to stay installed somewhere so the format remains editable, and no viewer control to license next to the service. Whether that reads as a lean deployment or a missing safety rail depends entirely on who authors the reports, which is the decision this whole comparison turns on.

What Ships to Production With Each Choice

The deployment surface is the part teams underestimate, because it stays invisible until an audit or a container rebuild forces someone to write it down.

An XtraReports deployment carries more than a rendering call. It carries the .repx report definitions, which serialize the banded layout into a format only DevExpress tooling opens. It carries the report designer somewhere in the organization, because a definition nobody can edit is a liability rather than an asset. If the reports are shown in an app, it carries a WinForms or WPF viewer control across whichever targets you support. Each of those is a real capability, and each is also one more artifact to version, patch, and keep compatible across .NET upgrades for years.

An IronPDF deployment carries the library and a Chromium engine it manages for you. The report definitions are HTML files that live in the same repository as the rest of the code, readable in any pull request. On Linux and in containers the story is a slim image, and the April 2026 release cut the engine image from 2.89 GB to roughly 1.14 GB while clearing four high-severity CVEs, which matters when the same image is pulled on every deploy.

The honest trade is that Chromium is memory-hungry by design, so the real capacity question is not whether a page renders correctly but how many concurrent renders a container takes before you pay for a bigger box. The XtraReports engine is lighter per render because it draws synchronously from an object graph already sitting in memory. Neither answer is free, and the right one depends on your throughput profile rather than a benchmark headline.

XtraReports and IronPDF Side by Side

Here is the head-to-head, written to describe the trade rather than crown a winner, with the rows that commit a team the longest sitting near the bottom.

Dimension	XtraReports (DevExpress Reporting)	IronPDF
Current branding	DevExpress Reporting, class and docs still say XtraReports	IronPDF, no rename history
Report definition	.repx designer file, or an XtraReport built in code	.html or .cshtml, plain text and diffable
Rendering engine	Proprietary document and printing engine	Chromium, the engine behind Chrome
Business-user designer	Yes, embeddable at runtime	No
Export formats	PDF, DOCX, XLSX, RTF, CSV, HTML, image	PDF, with HTML in and PDF out
Built-in data binding	Yes, SQL, Entity Framework, XPO, JSON, XML	You bind data in your own code
Viewer control	Yes, WinForms and WPF with print preview	No, generation only
Deployment surface	Definitions, designer, and viewer alongside the app	Library plus a managed Chromium engine
Licensing model	Per-developer annual subscription	Perpetual, per-developer
Best fit	Business-authored, multi-format enterprise reports	Code-driven, HTML-templated PDFs on a server

Table 1. A capability comparison rather than a scoreboard, where the definition-format and licensing rows commit a team for longer than any single feature row.

What a Band Actually Is, in Code

Most comparisons stop at ExportToPdf and treat the report as a sealed box, which skips the part that disorients people leaving XtraReports, namely what sits inside the box. Reports drawn in the designer serialize to .repx, but the identical object model builds straight in code, which DevExpress documents in its reports-in-code guide. Seeing that model is the fastest way to understand what a migration actually translates.

Read a code-built XtraReport the way you read a layout, and one thing jumps out. Every piece carries a coordinate. A DetailBand has a HeightF, an XRLabel has a WidthF, and each control sits at a fixed spot on a fixed canvas measured in report units. A band is a horizontal slice of the page, and the engine stacks those slices in a known order, page header, then detail repeated once per row, then page footer. Data binding runs through ExpressionBindings instead of a template. The mental model is a drawing surface with things pinned to it.

The HTML version throws that surface away. There is no Bands collection and no coordinate on anything, because the document flows. Boxes size to their content, text wraps where the line runs out, and the renderer decides where one page ends and the next begins. That last part is the adjustment that catches people, because in a flowed document a page break can land in the middle of a row unless a break-inside rule set to avoid says otherwise.

using IronPdf;

var renderer = new ChromePdfRenderer();
renderer.RenderingOptions.HtmlHeader = new HtmlHeaderFooter
{
    HtmlFragment = "<div style='text-align:center'>Customer Report</div>"
};

string html = $"<h1>{customer.Name}</h1><p>Account {customer.AccountId}</p>";
PdfDocument pdf = renderer.RenderHtmlAsPdf(html);
pdf.SaveAs("customer-report.pdf");

RenderingOptions.HtmlHeader and HtmlFooter stand in for the page header and footer bands, and the headers and footers guide covers the page-number tokens that drop into them. What a team gives up is the self-documenting object model, the one where a HeightF tells you exactly how tall a row is. What it gets back is a layout anyone who writes CSS can read and change without first learning the XtraReport surface.

The Bill Over Three to Five Years

The two licensing models point in opposite directions, and the shape of the bill matters more than any current figure, because figures move and the shape is what a team lives inside.

DevExpress Reporting is a per-developer annual subscription. A team licenses per developer per year, and renewing keeps everyone on the latest release as DevExpress ships it. IronPDF uses perpetual per-developer licensing instead, where a version is bought once and owned, with a full-function trial to evaluate first. Because exact numbers age, the current tiers live on the IronPDF licensing page rather than in a snapshot here that would go stale.

The trade cuts both ways, which is the point. A subscription keeps a team current automatically and never strands anyone on an unsupported version, and it also never stops billing, so a five-person team pays five seats every year whether or not the reporting changed. A perpetual license is a larger one-time commitment that then belongs to the team, and it also means a version that ages unless a renewal refreshes it.

Where the crossover lands is a function of team stability. A small, steady team that is not chasing yearly designer refreshes tends to come out ahead on perpetual across a three-to-five-year horizon, because the recurring seats keep charging long after the reports stopped changing. A team that wants the newest release every year, and that values the embeddable designer staying current, gets more from the subscription. Confirm the live numbers with whichever vendor you evaluate, because both of them move.

Who Maintains the .repx After the Author Moves On

Bus factor is the quiet cost. The person who lays out reports on the banded canvas builds real institutional knowledge, and when that person changes teams the .repx files stay behind as definitions their replacement cannot read without learning the designer first.

That is a manageable cost while the reports are actively maintained and someone owns the tooling. It becomes an exit cost the day the reports need to change and the designer is two Windows upgrades behind, or the day an audit asks how a figure on page four is calculated and the answer lives inside a format no text editor opens. The definition is fine right up until the moment it is not, and that moment tends to arrive on a timeline nobody scheduled.

A code-first definition inverts that risk. When the layout is HTML and CSS in the repository, a new hire reads it the way they read any other file, blames it in git, and changes it in a pull request a reviewer can see. The tribal knowledge is smaller because the skill is the web stack the team already has, not a band-and-control model specific to one product. That does not make the reports better. It makes them cheaper to inherit, which is a different and longer-lived kind of value.

Where XtraReports Earns Its Keep

IronPDF does not win every scenario, and naming the cases where XtraReports is the better buy matters more than winning the comparison, because a migration that fights the actual requirement costs more than the license it was meant to save.

• ✅ Non-developers draw the reports. The visual banded designer and the embeddable End-User Report Designer let an analyst drop a field on the canvas and see where it lands, no code in the loop. A flowed HTML template hands authorship back to developers, not to the people who need it.
• ✅ One definition has to become many formats. The same XtraReport object model exports to PDF, DOCX, XLSX, RTF, and CSV from one source, because that model is format-neutral until the moment it is drawn. Matching that spread with a code-first stack means additional libraries, and every library is one more dependency to license and patch for years.
• ✅ Grouped bands carry running totals. GroupHeaderBand and GroupFooterBand treat grouped sections and subtotals as first-class page furniture wired to SQL, Entity Framework, or XPO. The same output is reachable in CSS, but it is deliberate layout work rather than a property you flip on.
• ✅ An interactive viewer is part of the deliverable. WinForms and WPF viewer controls with print preview and parameter panels come in the box. IronPDF generates the PDF and leaves the viewing to whatever already opens PDFs.

When two or more of those describe the project, staying on XtraReports is the cheaper decision over any horizon, and the recurring subscription is buying something the team genuinely uses.

Translating Bands and Controls into Flow

A large share of production reporting is not interactive at all. It is a scheduled job or an API endpoint turning data into a PDF nobody opens in a designer. When that is the real workload, the concept mapping off .repx is small, and the mapping doubles as the exit cost of leaving the format behind.

XtraReports concept	XtraReport API	IronPDF and HTML equivalent
Report definition	XtraReport subclass or .repx file	HTML template, string, file, or Razor view
Repeating row section	DetailBand	A loop emitting <tr> or repeated <div> blocks
Column layout	XRTable / XRTableRow / XRTableCell	<table> / <tr> / <td>
Static or bound text	XRLabel plus ExpressionBindings	<span> or <div> filled by interpolation
Image	XRPictureBox	<img>, file path or data URI
Page header and footer	PageHeaderBand / PageFooterBand	RenderingOptions.HtmlHeader / HtmlFooter
Grouped subtotal sections	GroupHeaderBand / GroupFooterBand	Repeated <section> per group, built in your loop
Page numbers	XRPageInfo control	{page} and {total-pages} placeholders
Export to PDF	ExportToPdf / ExportToPdfAsync	RenderHtmlAsPdf / RenderHtmlAsPdfAsync

Table 2. Concept mapping at the band and control level rather than the export call, direct where the models line up and candid where re-authoring is the real cost.

The IronPDF equivalent for a batch job owns nothing but code the team can read. Rendering is async so a worker streams a run of invoices without blocking, and the header comes from rendering options rather than a banding model.

using IronPdf;

var renderer = new ChromePdfRenderer();
renderer.RenderingOptions.TextFooter.RightText = "Page {page} of {total-pages}";

foreach (var invoice in await billing.GetDueInvoicesAsync())
{
    string html = InvoiceTemplate.Build(invoice); // Razor or plain string composition
    PdfDocument pdf = await renderer.RenderHtmlAsPdfAsync(html);
    pdf.SaveAs($"invoice-{invoice.Number}.pdf");
}

For invoices, statements, and single-level detail reports, translating a layout into HTML is usually a few hours once the data is reachable in code. Reports leaning on nested GroupHeaderBand sections or cross-tabs carry more of that one-time cost, because those concepts have no one-line HTML equivalent and rebuilding them in CSS grid or table rowspans is where the hours actually go. Teams already rendering from a Razor view get the closest thing to a designer, since the template and the data live in the same place. Release cadence is worth weighing too, because a long-lived pipeline bets on the dependency staying current, and IronPDF ships roughly monthly with recent additions like PDF/UA accessibility and PDF/A archival output.

Which Should You Choose

After the deployment, the renewal, and the exit are all on the table, the decision usually resolves into one of three paths.

• 🚀 Stay with XtraReports, now DevExpress Reporting, when business users design the reports, when the team relies on the designer or a WinForms and WPF viewer, when one definition has to export to several formats, or when grouped-band layouts are load-bearing. The subscription is buying something used.
• 💡 Move to IronPDF when reports are code-driven and HTML-based, when existing web templates can be reused, when the deploy target is Linux or a container, or when a perpetual license beats renewing seats that keep charging after the reports stopped changing.
• ⚠️ Run both, which is more common than teams expect. Some keep DevExpress for interactive, user-designed reports and add IronPDF for high-volume, server-side jobs that never touch a designer.

The thread through all three is that the word reporting hides two different commitments, one where a person owns the layout on a design surface and one where code owns it as text, and the commitment a team actually has decides which one is cheaper to carry for years.

What does your production reporting look like once you strip away the demo? Are the .repx files still opened and edited by a person each quarter, or have they quietly become a scheduled job writing PDFs nobody views in a designer? Tell us in the comments, because that answer decides more than any table above.

If it is the second case, we think a short prototype is worth running before the next renewal decides for you. Start a trial, point ChromePdfRenderer at one report you already ship, and set the output next to what XtraReport.ExportToPdf produces today, because that one experiment answers the ownership question better than any comparison here, including ours.

DevExpress and XtraReports are trademarks of Developer Express Inc. We have no affiliation with DevExpress, and the details above rest on their public documentation. If we have a detail wrong, tell us in the comments, and we will correct it.