PSWriteHTML generates reports from PowerShell without writing HTML

A module for people who do not write HTML

PSWriteHTML is a PowerShell module for generating HTML reports, pages and emails without any knowledge of HTML, CSS or JavaScript. The only prerequisite stated is basic PowerShell knowledge, and that framing is the whole product. You have data in PowerShell, and you want a page a human can read, and the module is the layer that knows about markup so you do not have to.

The audience is the operations and support side of an organisation. A Windows administrator who needs to publish a DHCP or Active Directory report, a support team that wants a status page, a team that has a table of data and wants it to look like a dashboard rather than a CSV attachment. None of these people are going to hire a front end developer, and the alternative, writing a template by hand for every report, is where the effort goes.

The scale of the examples in the repository matches that. The Examples directory contains more than two dozen separate projects, including Example-Charts, Example-Diagrams and Example-DiagramsMermeid for Mermaid diagrams, Example-Calendars, Example-Carousel, Example-Accordion, Example-Comparing for the visual comparison of two or more objects, Example-ConvertToCSS, Example-Formatting, Example-Gages, Example-IconsAndColors, Example-InfoCard, Example-Headings, Example-BuildingTags, Example-ContainerPanelSection, Example-Disclaimer, Example-Emails, Example-Experiments, Example-IE, Example-DashimoStyle and Example-InlineOtherHTMLFile. Each one is a working sample rather than a snippet.

The repository layout is a normal PowerShell module: a manifest, PSWriteHTML.psd1, a module file, PSWriteHTML.psm1, with the public and private functions separated into Public and Private, assets in Resources, a Docs folder, the Examples, a Tests directory, a Website folder and a Build folder, plus a CHANGELOG.MD.

Install-Module is the supported route, GitHub is the development copy

The documentation is unusually clear about which copy to use. You can take the sources and use them from the repository, but the recommended path for consumers is the PowerShell Gallery, and the author's stated reason is practical: when publishing to the gallery the modules are stripped of junk and minimised into a single file, which makes them faster to load and use. The documentation goes further and says it encourages using the module from the gallery and treating GitHub as a highly development version.

The install is one command, available in PowerShell 5.1:

Install-Module -Name PSWriteHTML -AllowClobber -Force

The documentation explains that the Force and AllowClobber flags are not necessary, but that they skip errors in case some appear. That is a useful hint, because the module ships a lot of commands and name collisions with existing functions in a session are the likely failure.

The dependency story has two versions depending on when you look. Historically PSWriteHTML was composed of several of the author's other modules. To run it from source you need PSSharedGoods, and PSSharedGoods in turn needs Connectimo and PSWriteColor, and the documentation states plainly that it will fail without them even though PSWriteHTML itself does not use them directly. Since version 0.0.61, that changed. Every dependency is baked into the published PSWriteHTML, so you do not need to download any other module unless you want to contribute to the project.

That distinction is the one to keep in mind. A gallery install is one module with no dependencies. A source checkout is three modules that have to be installed and kept in step.

The upgrade warning is the most useful paragraph in the docs

The documentation does not simply tell you how to update. It tells you how not to break yourself.

The update command is straightforward:

Update-Module -Name PSWriteHTML

And then the paragraph that follows is the part worth repeating to your team. The important thing, as it is put, is that if something works for you in production, keep using it until you test the new version on a test computer. The reason given is blunt: the author does changes that may not be big, but big enough that auto-update will break your code, and the example offered is a small rename to a parameter, after which your code stops working.

That is a real risk in a module this size. A report generator that exposes dozens of cmdlets and a large object model has a wide surface for renames, and PowerShell scripts that call them are usually scheduled tasks in a corner of a server with nobody watching. The instruction to close and reopen the PowerShell session after an update is also worth noting, since an old version of the module stays loaded in an open session.

This turns an ordinary module into one that needs a version pinning policy. If you are adopting it in an environment where reports run on a schedule, treat the gallery version as a dependency you control, not something that updates itself.

A fork of ReportHTML that became a rewrite

The project started as a fork of the ReportHTML module, and the documentation explains why in a sentence that also tells you about the state of the ecosystem: it was forked because ReportHTML was outdated and not maintained, and the fork was intended to address some of its problems and add more features. The documentation then says that as it stands PSWriteHTML is a complete rewrite.

That is worth pausing on, because a fork that becomes a rewrite is a different animal with a different upgrade story. The original lineage explains the command naming, the general shape of the API and the reason the author cares about HTML generation from a systems angle. The rewrite explains why the internals bear little resemblance to the module it started from.

The author also runs a family of related projects built on top of it, and the article list in the documentation is effectively a catalogue of use cases. Statusimo is a PowerShell generated status page, Dashimo is a PowerShell generated dashboard with table conditional formatting, charting and icons, Out-HtmlView is described as an HTML alternative to Out-GridView, and Emailimo is a way to send styled emails from PowerShell. One of the posts announces that Emailimo was merged into PSWriteHTML, along with Internet Explorer support and no dependencies, which matches the baking of dependencies into the published module.

The other posts cover specific features rather than whole modules, and they read as a design history of the object model: nested tabs, diagram updates, diagram events, a calendar object, working with HTML in PowerShell, creating diagrams, and comparing two or more objects visually in a cross platform way.

So the practical picture is that PSWriteHTML is the base layer, and the dashboards and status pages are built on it. If you want the widget, you may end up wanting the sibling module that wraps it.

The Examples folder and the sibling modules are the real documentation

Because the API surface is large and the module is aimed at people who are not front end developers, the examples do more work than a reference manual would.

Each directory under Examples is a self contained sample, and the names map directly to the features you would want. Example-Charts and Example-DashimoStyle cover the dashboard case, Example-Diagrams and Example-DiagramsMermeid cover the diagram case including Mermaid syntax, Example-Comparing and Example-ComparingOutHtmlView cover the Out-HtmlView use case, Example-Emails covers the email path, and Example-ConvertToCSS shows how the styling is exposed to the user. There is also a pair of scripts, Example-GenerateHelp.ps1 and Example-GenerateHelpCalendar.ps1, and an Example-Experiments directory, which suggests the author keeps a scratch space in the public repository.

The Docs and Website directories in the repository root hold the formal documentation, and the CHANGELOG.MD at the root is the version history. The tests are not an afterthought either: there is a Tests directory and a PSWriteHTML.Tests.ps1 file at the root, and the CI workflow for PowerShell tests is linked from the project header.

Two details from the header are worth knowing for deployment. There is a PowerShell Gallery badge for the stable version and another for the preview version that includes pre-releases, so a preview channel exists. And there is a jsDelivr badge for the author's CDN repository, which suggests the JavaScript and CSS assets the module embeds are also served from a CDN, which matters if you generate reports in an environment with no outbound internet access.

Where a template engine would serve you better

The honest limitation is about control. The module gives you components, and it gives them to you in a style the author designed, and the style is the point, because the audience does not write CSS. If you need to produce a specific pixel layout, match a design system, or embed an interactive widget that is not one of the provided pieces, you are fighting the abstraction rather than using it.

The alternative is a general purpose HTML templating approach, where you keep a template file and feed it your data. The difference in approach is real. A template approach gives you total freedom over the output, and it costs you the knowledge of HTML and CSS that PSWriteHTML is specifically designed to remove. It also gives you a debugging model that is a file you can open, rather than a set of PowerShell parameters.

There is a second alternative, which is to not use HTML at all for the audience you have. A CSV attachment or a plain text file costs nothing and is what many recipients actually want. The module earns its place when the recipient needs to see a chart, a status overview or a comparison, and would rather open a page than read a table.

And a third, narrower point. The module is for generating documents from data you already have in PowerShell. It is not a scheduler, a data collector or a dashboard server. Dashimo and Statusimo are the pieces that add a dashboard or a status page around it, and the documentation itself routes you to those posts for those use cases.

The other limitation is the one the author states himself, and it is not a design limitation at all. This is a module that will change under you, and the versioning discipline has to come from you.

MIT licensed, releasing every few months, with the gallery as the channel

The licence is MIT, in the LICENSE file at the root, and the module is published to the PowerShell Gallery, which is where the badges point and where the install command comes from.

The release history shows a project shipping on a quarterly rhythm. v1.39.0 on 2025-09-04, v1.40.0 on 2025-12-14 and v1.41.0 on 2026-03-08. The repository is not archived, and the last push was on 2026-10-03, which is months after the last tagged release, so work is landing on the branch ahead of the published package. There is a preview channel on the gallery as well, so a team that wants the newest features can take them and accept the instability.

The dependency story has also simplified over time, from three modules required for a source checkout to a single self contained published package since version 0.0.61. That is a real improvement in the operational profile, and it is the reason to take the gallery copy rather than a clone.

The upgrade cost is therefore concentrated in one place. Installing and updating are single commands, the package is small and self contained, and MIT terms mean you can vendor it if a machine will never reach the gallery. What you have to manage is version discipline, and the documentation has already told you how the author thinks about that: keep the version that works in production, and test the new one on a test computer first.

Editorial conclusion

PSWriteHTML is worth adopting if your team already works in PowerShell and needs to publish operational data as a readable page or an email, because it removes the front end from the task entirely and the published package carries no dependencies. It is the wrong choice if you need precise control over the markup, if your readers need to interact with the result beyond the components the module provides, or if you have no PowerShell at all. Before you install it, read the upgrade warning in the project documentation, because a parameter rename is enough to break working automation, and pin the version that works on your production machines, and note that the newest release is v1.41.0 from 2026-03-08 while the repository was pushed to on 2026-10-03.

Frequently asked questions

Official sources

1. EvotecIT/PSWriteHTML on GitHub
2. Issues
3. License: MIT
4. README
5. Releases