# XAML Styler: the formatter that makes a XAML diff readable instead of noisy

> XAML Styler is a Visual Studio extension that rewrites XAML according to a configurable set of styling rules, and it ships as three separate products: a VS2022 extension, a VS2019 extension and a JetBrains Rider plugin, plus a console build on NuGet for script integration. The rules live in a wiki and the whole thing is Apache-2.0 licensed.

**Xavalon/XamlStyler** — Visual Studio extension to help format your XAML source code

- Repository: https://github.com/Xavalon/XamlStyler
- Stars: 1,383 · Forks: 160
- Language: C#
- License: Apache-2.0
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/xavalon-xamlstyler

## The whole product is one context menu entry

XAML Styler is a Visual Studio extension that formats XAML source code based on a set of styling rules, and the README states the purpose plainly: it can help you or your team maintain a better XAML coding style as well as a much better XAML readability.

The getting started instruction is a single sentence. Right-click with any file and select Format XAML to format your XAML source code. There is no configuration step before the first use, no project file to add and no build integration to wire up. The extension is installed from the Visual Studio Marketplace, and the first thing it does is give you one more entry in a context menu you already open ten times a day.

That simplicity is the design. The tool does not try to be a XAML editor, a code generator or a refactoring engine. It takes a file that is already correct and rewrites its layout.

The value of that is in the diff rather than in the file. XAML is a verbose language where a small change to an attribute value can produce a large reformatting difference, and a reviewer's attention goes to the whitespace rather than to the change. A formatter that everyone agrees on removes the whole category of noise from review, and that is a much bigger effect than it sounds when the codebase has thousands of XAML files.

The alternative to an extension is a build step, and the project supports that route too, which is the subject of a later section. The project is C#, Apache-2.0 licensed, and the repository root holds a build/ directory, a src/ directory, a logo.svg, CONTRIBUTING.md and CODE_OF_CONDUCT.md.

## Three IDE extensions and a console build, all from one repository

The downloads section is the most informative part of the README, because it shows the project is not a single extension but four shipped artefacts.

There is a Visual Studio 2022 extension under the marketplace identifier TeamXavalon.XAMLStyler2022, and a separate Visual Studio 2019 extension under TeamXavalon.XAMLStyler. They are two listings, which is what happens when an extension has to target two different Visual Studio extension hosts, since the VS2019 host cannot load a VS2022 package.

Then there is a JetBrains Rider plugin, listed on the JetBrains plugin marketplace under the name xaml-styler with identifier 14932. That is the notable one, because Rider is a different IDE on a different platform with a different extension model, and a project that maintains an extension for it is going beyond the Visual Studio family. The repository topics include jetbrains-rider alongside uwp, uwp-applications and uwp-apps, which places the origin of the tool in the Universal Windows Platform world, and the Rider support is what carried it further.

The fourth artefact is a console build, XamlStyler.Console, published on NuGet. A console build is not an extension, it is a command line program, and its presence is the reason the wiki has a Script Integration page, linked from the table at the top of the README alongside Documentation, Release Notes and Contributing.

That combination is the design decision worth understanding. The formatting rules are the valuable part, and the project separated them from the host so that the same rules can be applied from an IDE, from a Rider plugin and from a script. A team that wants to enforce formatting in continuous integration needs exactly that third form.

The README also links a Gitter chat, which tells you where the project's community lives.

## The version scheme encodes the year and month, which tells you the release habit

The release names are the tell, and they are unusual enough to be worth reading carefully.

The three recent releases are Release-3.2504.1, Release-3.2501.8 and Release-3.2411.0. The first two digits after the 3. are the year and the month, so 2504 is April 2025, 2501 is January 2025 and 2411 is November 2024. The final number is a build counter within that month, so 3.2504.1 is the first release of April 2025, 3.2501.8 the eighth of January 2025, and 3.2411.0 the first of November 2024.

That scheme tells you the release process without any release notes. Builds are cut on demand, often more than once in a month, and the counter resets each month. It is the convention that suits an extension that ships whenever a change is ready rather than on a schedule, and it also means the number after the dot is not a semantic version increment, so you cannot read compatibility out of it.

The dates attached to those three releases are 2025-05-02, 2025-02-04 and 2024-11-26. So the releases are not always cut in the month their name implies: the 3.2504.1 build was published in May, and the 3.2501.8 build in February. The name is the month the build was started, and the tag date is when it went out.

The last push to the repository was on 2026-04-14, which is nearly a year after the most recent published release. The repository is not archived, but the published extension has not been updated in that period, and a user installing from the marketplace gets the 2025 build rather than the current state of the source. The release notes are linked from the top of the README, and they are the place to check what actually changed in each build.

## Script integration is how the formatting becomes a team rule rather than a habit

The Script Integration page in the wiki is linked from the README header, and the presence of the console build on NuGet makes it the most consequential thing in the project for anyone beyond a single developer.

The distinction matters. An extension applies formatting when a developer asks for it, which means every developer has to remember, and the codebase can still drift because nothing enforces the result. A script integration applies the same rules without an IDE, which means the same rules can be part of a build, a pre-commit hook or a continuous integration job, and the formatting stops being a matter of individual discipline.

The value of that depends entirely on whether the console build and the extensions share one rule set, and the fact that both come from the same src/ tree and the same wiki is the reason to believe they do. A team that has written its own formatting rules for its XAML, and enforced them in CI, would otherwise have to reproduce the extension's behaviour in a separate tool, and any divergence between the two would show up as a fight in review.

The wiki is also where the rules themselves are documented. The README's phrasing, formats XAML source code based on a set of styling rules, points at a configurable rule set rather than a fixed style, and the Documentation link is the wiki. So the extent to which this tool is useful to a team depends on how many of its rules match what that team already wants, and how many of its rules can be turned off.

The repository's topic list gives a hint about the domain the rules cover, with uwp, uwp-applications, uwp-apps, visual-studio-extension, xaml, xaml-source and xaml-styler, so the rule set was built around UWP flavoured XAML with elements, attributes and markup extensions that have their own layout conventions.

## Where XAML Styler is the wrong tool

The limits here are narrow, because the tool does one thing, and they are mostly about scope and about who can use it.

The first is that it only helps teams that hand-write XAML. If your XAML is generated, or if the XAML in your project is a small number of resource dictionaries that nobody touches, there is nothing for a formatter to do. A form designer driven workflow produces XAML that no one formats by hand, and the tool is irrelevant there.

The second is that the formatting is only as good as the rule set for your XAML dialect. The tool came out of the UWP world, and a team working on WPF or Avalonia or a specific UI framework will find that some rules describe constructs their XAML does not have, and that the interesting question is which rules to disable. The README does not enumerate the rules, so that assessment means reading the wiki.

The third is the four-artefact maintenance surface, which is a real cost for the project rather than a risk for the user, but it becomes a risk for the user in one way. Because the VS2019 and VS2022 extensions are separate packages and the Rider plugin is a third implementation, a feature added to one is not automatically in the others, and a team using a mix of IDEs may get different formatting from each. The release counter in the version numbers suggests frequent builds, which is good for keeping up with IDE changes and bad for guaranteeing feature parity across the three.

The fourth is the release gap. The last push was on 2026-04-14 and the last published release was in May 2025, so the marketplace build and the repository have drifted by about a year. A team that installs the extension today gets a build that predates whatever Visual Studio has changed since, and if a newer Visual Studio breaks the extension, the fix may exist in the source and not in the marketplace.

The fifth is the platform. A Visual Studio extension and a Rider plugin cover Windows developers on those two IDEs, and the console build on NuGet is the only route for a CI environment, which is a .NET runtime and has to be provisioned like any other build dependency. There is no shell script or container in the repository root for that, so the CI integration is something you assemble.

## Conclusion

XAML Styler is worth adopting for any team that writes XAML by hand, because formatting is where XAML code review normally burns time, and this tool makes the formatting decision once, in configuration, rather than in every reviewer's head. It is the wrong tool for a project that does not use XAML, and the wrong choice for a team that wants one canonical format enforced in CI without anyone installing an IDE extension, which is where the console build on NuGet comes in. Before rolling it out, read the wiki, in particular the script integration page, and check that the rules you enable match the XAML dialect your project uses, since the tool grew out of the UWP world.

## FAQ

### What is XAML Styler and what does it do?

It is a Visual Studio extension that formats XAML source code based on a set of styling rules, intended to help a team maintain a consistent XAML coding style and improve XAML readability. You use it by right-clicking a file and selecting Format XAML.

### Which IDEs does XAML Styler support?

There is a separate extension for Visual Studio 2022 and another for Visual Studio 2019, both on the Visual Studio Marketplace, and a JetBrains Rider plugin on the JetBrains plugin marketplace. A console build named XamlStyler.Console is published on NuGet for script and CI use.

### How can I apply XAML Styler rules in a build or CI job?

Use the XamlStyler.Console package on NuGet, which is the command line form of the tool. The wiki has a Script Integration page describing this, and the console build comes from the same source as the IDE extensions so the same rules apply.

### How are XAML Styler versions numbered?

The version encodes the year and month of the build followed by a counter within that month, so 3.2504.1 is the first build of April 2025 and 3.2501.8 the eighth of January 2025. The recent releases are 3.2504.1, 3.2501.8 and 3.2411.0.

### Where are the XAML Styler formatting rules documented?

In the project wiki, which the README links as Documentation alongside the script integration page, the release notes and the contributing guide. The rules are configurable rather than fixed, so the wiki is where you check which ones apply to your XAML.

## Sources

- [Issues](https://github.com/Xavalon/XamlStyler/issues)
- [License: Apache-2.0](https://github.com/Xavalon/XamlStyler/blob/master/LICENSE)
- [README](https://github.com/Xavalon/XamlStyler/blob/master/README.md)
- [Releases](https://github.com/Xavalon/XamlStyler/releases)
- [Xavalon/XamlStyler on GitHub](https://github.com/Xavalon/XamlStyler)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/xavalon-xamlstyler