XML Notepad: a Windows editor built around XPath and schemas

A dedicated XML tool rather than a text editor with XML highlighting

XML Notepad is a Windows program that provides a simple intuitive User Interface for browsing and editing XML documents, and the emphasis on browsing is the clue about how it works. A general-purpose editor gives you a text buffer and syntax colouring, which is enough to read XML and useless for the questions XML raises, such as what does this XPath select, what does the schema say this element may contain, or what does this transform produce. This tool answers those with what it calls XML Schema aware Intellisense, a find dialog that supports XPath, support for XInclude, XSLT transforms with an inline viewer of the output, automatic conversion of .csv, .json and .html files, handy statistics about the document and an XML diff to compare two similar documents. The audience is therefore the person who has to look inside a data file: an integration developer tracing a config problem, a support engineer with a customer's export, a developer checking what a feed actually contains. The project also points at a vibrant community with many updates and bug fixes, and it is published by Microsoft under the MIT licence with the Microsoft Open Source Code of Conduct.

Four ways to install, three of them Windows-native

The README lists four installation routes, and the differences between them are about convenience and trust rather than function. The ClickOnce installer is described as the most convenient, installed directly from the web browser. The standalone downloadable installer is there for anyone who needs something that works offline, in which case you download the zip, copy it to the target machine, unzip it there and run the installer inside it. The Windows MSIX installer is included in each GitHub release under the expandable Assets heading, for people who need a trusted Windows installer. The fourth is the package manager, and the instruction is a single command:

winget install XmlNotepad

with the honest caveat that this is a bit behind right now due to problems updating the winget repo. That last comment is worth more than it looks, because a stale package in the system package manager is a worse experience than a browser click that fetches the current build, and the release history shows a steady stream of builds, 2.9.0.22 from 2026-06-08, 2.9.0.21 from 2026-03-28 and 2.9.0.20 from 2026-03-27, which is what makes the winget lag noticeable. The project's site is microsoft.github.io/XmlNotepad, and the last push to the repository was on 2026-10-03, so the application is still being worked on.

The feature set, taken one at a time

Each of the advertised features answers a different question about an XML document, and it is worth reading them as a workflow rather than a list. XML Schema aware Intellisense is about authoring, and it means the completion list is filtered by what the schema permits rather than by what the document happens to contain. The find dialog that supports XPath is about navigation, which is the feature that separates this from a text editor, because an XPath query is a way of asking a question about structure rather than about text. Support for XInclude is about assembly, letting a document be composed from other documents at parse time instead of being pasted together. XSLT transforms with an inline viewer of the XSLT output is about verification, so you can see what a transform produces without leaving the tool or opening a browser. Automatic conversion of .csv, .json and .html files is about getting data in, which is the practical bridge between the messy formats a system exports and the XML a schema describes. The stats about the document and the diff between two similar documents cover the inspection and the comparison cases, and the diff in particular is the feature a reviewer of a change to a data contract will use most.

The design document, and how the application is put together

The README links to a separate XML Notepad Design document, described as the place for information about how the application is built, and that link is the most useful pointer in the file for anyone evaluating the project. It tells you that a desktop XML editor is not a trivial program, because the interesting behaviour lives in how the document tree, the schema, the query engine and the transform engine are wired to the user interface, and a separate design document is the right place for that. The repository layout supports the same reading. There is src/ for the application, tools/ for supporting tooling, docs/ for the documentation sources, a .vscode/ directory, and the build and publish entry points in build.cmd, publish.cmd and runtest.cmd. The documentation itself is a mkdocs site, with mkdocs.yml at the root and mkdocs-local.yml for running it locally, which is the same tooling choice many modern open source projects have made for their hand-written guides. The change history and the help pages are both hosted on the project site, and the help pages are the first place a new user should look for the details the README summarises.

Where XML Notepad is the wrong tool

The limits follow from the platform and the model. The first and largest is that this is a Windows program, and every one of the four documented install routes assumes it, from ClickOnce and the MSIX package to the winget manifest, so a developer on macOS or Linux gets nothing without a virtual machine, and a team that standardises on a cross-platform editor has to make an exception for this one tool. The second is that the interface is a document tree. That is exactly right for a configuration file or a service response of a few thousand lines, and it is the wrong shape for a multi-gigabyte export where you want to stream, filter and transform rather than hold a tree in memory. The third is the scope. This is a viewer and editor for XML documents, not a pipeline: the CSV, JSON and HTML conversion is a convenience at the door, and the XSLT support gives you a preview of a transform, but there is no scripting, no validation gate for a pipeline, and no integration story beyond the GUI. The fourth is a licensing oddity that is easy to miss, because the repository is MIT while the project is hosted under the microsoft GitHub organisation, so if your organisation has a policy about Microsoft-owned dependencies, that conversation is a separate one from the licence.

How this differs from an XML mode in a general-purpose editor

The realistic alternative is the XML support that already exists inside the editor your team uses, whether that is a general-purpose code editor with an XML extension or a plain text editor with syntax highlighting. The difference in approach is where the document model lives. A general-purpose editor treats XML as text, so the buffer is a string, and anything beyond colouring, such as completion, path-aware navigation or transform preview, depends on an extension being installed and configured against your schema. A dedicated XML tool treats the document as a tree from the start, so the tree view, the schema-aware completion, the XPath find dialog and the XSLT preview are consequences of the model rather than features bolted onto a text buffer. The cost of that choice is the same thing that makes it good, the tool is specialised and it is Windows-only, so a cross-platform team ends up maintaining two ways of looking at XML. For a support engineer or a consultant who lives in one document type on one platform, the dedicated tool is clearly the better instrument. For a product team with a mixed stack, the general-purpose editor with a good XML extension is usually the lower-friction answer, and this tool is the one to reach for when a specific problem, a particular schema, or a transform that has to be checked properly justifies a dedicated program.

Editorial conclusion

Adopt XML Notepad if you work with XML on Windows and want a dedicated tool with schema-aware completion, an XPath find dialog, XSLT preview and a two-document diff rather than a general-purpose text editor. Do not adopt it on macOS or Linux, since every documented installation route is a Windows one, and do not adopt it for very large documents without testing, because it is a desktop tree view over the document rather than a streaming tool. Before you install, note that the winget route is described as being a bit behind, so prefer the ClickOnce or MSIX installer, and check the design document linked from the README for how the application is built.

Frequently asked questions

Official sources

1. License: MIT
2. microsoft/XmlNotepad on GitHub
3. Project website
4. README
5. Releases