Stimulsoft's AllowHtmlTags Is Not a Rendering Engine

Two ways to get markup into a document, and only one of them is what most people mean by the phrase.

// Report engine: a boolean on a text field, and an interpreter behind it
invoiceHeader.AllowHtmlTags = true;
invoiceHeader.Text = "<b>Invoice</b> <font-size=\"14\">2026-08</font-size>";

// Rendering engine: the page itself, stylesheet and all
using PdfDocument invoice = new ChromePdfRenderer().RenderHtmlAsPdf(invoiceHtml);

Both lines put styled content on a page. The first accepts a fixed list of inline tags inside one field. The second hands the whole document to a browser. Confusing them turns an existing library of HTML templates into a redesign nobody scheduled.

Full disclosure. We build IronPDF at Iron Software, and this read looks at where Stimulsoft's 21-tag interpreter and per-runtime SKUs cost a team, and where IronPDF renders the whole stylesheet from one licence.

A Tag Property Is Not a Rendering Engine

Stimulsoft's AllowHtmlTags documentation lists what a text component accepts, namely b, i, u, s, sub, sup, strong, em, strike, color, background-color, font, font-face, font-name, font-family, font-size, font-color, letter-spacing, word-spacing, line-height, and text-align. Twenty-one tags, all inline text formatting, and the documentation is explicit that ordered and unordered list tags are among the exceptions that are not supported. Tags may appear only in the Text property of a Text component, not anywhere else in the report.

As bold, colour, and spacing inside a report field, that is a reasonable feature and what it was built for. As an HTML path, the gaps are structural rather than cosmetic, because what a browser engine accepts includes external stylesheets, CSS layout, and script execution, and none of the three exist here. A team with existing email templates rebuilds the layout inside the designer using report objects, then maintains two versions of the same document, one for the browser and one for the report. IronPDF takes the browser version and stops there.

How Far Does One Report Definition Travel?

The cross-platform claim is the strongest thing about the product, and it holds. The engine is split into separate products by runtime, with Reports.NET for WinForms and classic ASP.NET, Reports.WEB for ASP.NET Core, MVC, Blazor, and Angular across .NET 6 through .NET 10, plus Reports.JS, Reports.JAVA, Reports.PHP, and Reports.PYTHON, and a single .mrt or .mrz definition moves between them without a rebuild. For a team shipping the same report layout to a desktop client and a web front end, that is design work done once instead of twice. IronPDF covers the whole .NET side of that spread from one package, so the template never needs porting between SKUs.

Its standalone Designer is cross-platform too, shipping as a Windows executable, a macOS .dmg, Linux .rpm and .deb packages, and a browser-hosted version, where most competing designers are Windows-only with a separately sold, feature-reduced web viewer alongside. Version 2026.3 landed in July 2026 on a predictable quarterly cadence, adding real-time shared report editing, a Vue.js viewer, IntelliSense in the Windows standalone designer, and new chart types. The runtime grant is perpetual rather than a pure subscription, meaning a licence keeps working after the update-and-support window lapses, and no royalties are owed for the report engine or the embedded designer at runtime. That grant is the ceiling of what the SKU covers, because an IronPDF template is the HTML a team already maintains, with nothing to install on any of the three.

Tag Interpreter Against Browser Engine

Scoped to the slice where both tools produce a file.

Capability (document output only)	Stimulsoft Reports	IronPDF
HTML tags accepted in a text field	21 inline tags, list tags excluded	0 excluded, <table>, <ul>, Grid, and Flexbox
Encryption and permissions	40-, 128-, and 256-bit with user and owner passwords	128- and 256-bit AES, with permission flags
Certificate-based signatures	Signature fields on export	PdfSignature on the returned PdfDocument
PDF/A export	Supported, with layers dropped in PDF/A mode	Supported, layers preserved
Merging or stamping an existing PDF	Outside the report engine	PdfDocument.Merge and split
Producing a PDF without a designer file	Built around authoring an .mrt or .mrz template first	Code-first, markup or a URL in, PdfDocument out

Table 1. Document output only, Stimulsoft Reports against IronPDF, excluding the designer and data-binding surface.

The PDF/A row is the fairest one in the table, because Stimulsoft supports the format with one documented behaviour to plan around rather than a gap, while IronPDF keeps the layers.

Which SKU Decides Your Operating System?

Three constraints follow from how the product is packaged, and all three are purchase-time decisions rather than configuration.

• Reports.NET and Reports.WEB are licensed separately: needing both a desktop and a web front end means buying two products or stepping up to the Ultimate bundle. Tiers run Single for one developer, Team for up to four, Enterprise for up to fifteen, and WorldWide for unlimited, with Team and above including one build server licence. Prices move, so check the current figures. The structure is the part that matters, because the SKU count is set by your architecture rather than your headcount.
• The SKU also decides the container story: Stimulsoft.Drawing, the cross-platform drawing engine built on ImageSharp and SixLabors Fonts to replace the Windows-only System.Drawing, ships in the .NET Core product packages, meaning Reports.WEB and Dashboards.WEB, Reports.BLAZOR and Dashboards.BLAZOR, and Reports.ANGULAR. Reports.NET is not among them. Which package was licensed therefore decides whether a Linux container is a supported target at all, and that is an awkward thing to discover after procurement.
• A licence key gates initialization: report and dashboard components need a key registered through StiLicense.Key or a LoadFrom* call before they initialize, and Stimulsoft's own evaluation-limitations documentation confirms that without one a watermark prints on every report page and dashboard panel. That makes secret management a startup-path concern, re-verified on every deployment target the report runs on, in a way a runtime key applied once in code is not.

The CVE record needs the same care as the SKU list, because the vendor name spans several codebases. Four advisories attach to the 2023.1 line. CVE-2023-25261 at 9.8 allows arbitrary local file read and write through included source code, against Designer Desktop 2023.1.4 and Designer Web and Viewer Web 2023.1.3. CVE-2023-25260 at 7.5 is local file inclusion in Designer Web, CVE-2023-25262 at 7.5 is server-side request forgery in Designer Web, and CVE-2023-25263 at 5.5 is a static secret letting connection strings stored in .mrt files be decrypted after decompiling the assembly. The first three are scoped to design-time and viewer tooling rather than the engine assembly a compiled application ships. Two older 9.8 entries, CVE-2020-15865 and CVE-2021-42777, both trace by NVD to a 2013-era build, Stimulsoft Reports 2013.1.1600.0, with a server-side C# compilation feature. A trio from 2024 belongs elsewhere again, because CVE-2024-24396 and CVE-2024-24397 name Stimulsoft Dashboard.JS while CVE-2024-24398 names Stimulsoft Dashboard.PHP, so calling all three an npm package problem gets one of them wrong. Setting the misattributed ones aside, what stays on the record is a designer-and-viewer cluster from 2023 with no fixed version listed in NVD or GitHub's database, on a product line that has shipped a dozen quarterly releases since.

What IronPDF Does With the Stylesheet Instead

Which half of the workload is the designer being charged to? Where a finished stylesheet is the input, the report definition drops out entirely.

using IronPdf;

var invoiceRenderer = new ChromePdfRenderer();
invoiceRenderer.RenderingOptions.PaperSize = IronPdf.Rendering.PdfPaperSize.A4;
// Print media so the template's own page rules and breaks are honoured
invoiceRenderer.RenderingOptions.CssMediaType = IronPdf.Rendering.PdfCssMediaType.Print;

using PdfDocument invoice = invoiceRenderer.RenderHtmlAsPdf(File.ReadAllText("invoice.html"));
invoice.SaveAs("invoice-2026-08.pdf");

IronPDF returns a paginated PDF with the template's tables, lists, and layout intact and its text selectable, with no allowlist to design around and no separate SKU per runtime. Headers, footers, and paper sizes are set on the same renderer, and an MVC project can hand over a Razor view instead of a rendered string.

Most estates running Stimulsoft split the work rather than replace anything. Analyst-built reporting stays in the designer, where cross-tabs, subreports, drill-down parameters, and scheduled distribution live and a rendering library offers nothing. The invoices, receipts, and statements never destined for a designer move to a render call. Stimulsoft's ceiling sits at that seam, since the tag interpreter, the runtime key, and the SKU decision are charged to both halves even when only one of them opens the designer. There is a full walkthrough of the renderer half, and IronPDF has a free trial for putting one of your existing templates through it first.

If you have had to pick between Reports.NET and Reports.WEB for a project that needed both a desktop and a web front end, how did the SKU maths work out? Tell us in the comments, because that decision seems to get made once and then quietly constrain the deployment target for years.

Stimulsoft is a trademark of its owner and this piece is not affiliated with the company. The tag support, packaging, licensing, release, and CVE details above are drawn from Stimulsoft's own documentation, NVD, and the GitHub Advisory Database as they stood at the time of writing. If a detail has changed since, correct us in the comments.