If you suspect and error in your XML get a quick validation on your XML File by copying and pasting your XML document into an online tool like https://www.liquid-technologies.com/online-xml-validator. This saves you the hassle of starting up a desktop editor and installing a plugin. Online XML validators are great for checking small XML documents without having to install a desktop tool. Be aware that your XML config files might contain sensitive data, do not use online validation tools if this is the case.
A Great free and secure solution is the VSCode extension: XML Language Support by Red Hat. The UX is highly intuitive and a desktop editor like VSCode gives you a secure location to run verifications on XML files that contain confidential data.
In this post I quickly run through the XML validation rules and what a well formed XML document needs to be valid, as well as 7 tools, both desktop and online, to verify validity and how they compare.
XML stands for Extensible Markup Language. XML has a basic set of rules know as XML syntax that applies to all XML documents. The validators I cover here verifies the XML syntax.
An XML document also has a structure. This is the extensible part. In order to communicate data using XML the send and receiver of the document need to understand the structure of the document. They need to agree on what elements will appear in the document and what they mean. The XML Syntax is like the letters of the alphabet, and the XML document structure is the language.
Here is a quick review of the XML Syntax Rules:
All of the validators in my list verify these basic XML rules.
An XML document will typically include the XML Prolog:
<?xml version="1.0" encoding="UTF-8"?>
The prolog is optional and must appear first in the document. It does not count as an element.
After the prolog, a valid document must have only one root element. This element is the parent element of all elements in the document.
An XML element is made up of a start tag and an end tag with content in the middle. Here are some examples.
<closed>Some data or elements</closed>
This element is opened by the “<closed>” tag and closed by the “</closed>” tag. Closing tags have a forward slash before the name to identify them as closing tags.
The above element is self contained, because it does not enclose any data or further elements it can be closed with the shorthand notation of adding the slash to the end of the name.
In valid XML elements are not allowed to be overlapped. An element cannot contain only the start tag or end tag of another element, it must include both tags or none.
An incorrectly nested structure might look like this:
It’s obvious to see the problem in this small example, but in large XML documents it can be more difficult to detect and resolve this issue.
This is a correctly nested structure:
Tag names have strict character limits to be precise. Tag names must start with an alpha character. Numbers and special characters cannot be used to start a tag name.
Only the following special characters are allowed in a tag name:
Colon is generally reserved for namespace names, but nevertheless, is valid in a tag name. Spaces are not allowed in tag names.
As a strict specification, case is part of the tag name so,
Start and end tags must match.
Double quotes or single quotes are both valid, but normally double quotes are used. For example, the element a with attribute “name” and value “value” would appear as follows
See the W3 School pages for more info W3 Schools XML
My big warning with online validation tools is to be careful uploading or pasting XML that has sensitive data in it, like passwords. You can’t be sure that these sites aren’t scraping your XML for this information. For example, XML files with unencrypted connection strings should not be uploaded into online XML validation tools.
This is a simple online validator. The page claims that it is the best online XML validator, but this is not true (as is usually the case with these types of claims). It suffers from some UI design flaws that make it difficult to trust in the sense that it appears a bit ‘slapped together’ (and, is this site pulling my xml data into a data collection database?).
I really like this online validator. The UI is polished and validation errors are flagged in the context of the XML. The editor window will highlight errors in red even before the “Validate” button is pressed so if you are editing your XML in the editor window can see errors as you type. The validator is quick and error messages are accurate.
If you are a Visual Studio user then this tool is already installed and ready for use. Loading Visual Studio is slow and even opening files can burden you system with intellisense lookups. Visual Studio has strong built in XML validation with no extensions or plug-ins required. XML and config file support is enabled by default with validation and editing support. The Resharper extension enhances Studio's XML support with some additional visual cues in the UI and fix suggestions (Resharper displays a red indicator at the top of the scroll bar if a file is invalid).
Sublime is a powerful commercial editor with a broad extension library. The Exalt extension is required to perform XML validation. Install it by clicking "Preferences"->"Package Control"
Select "Install Package" and search for "Exalt". Install the Exalt package into Sublime to enable XML editing and validation support. Exalt supports both "xml" and "config" file extensions. If you paste your XML content into an editor window make sure to save the content into a file with one of these extensions to enable validation.
Sublime Exalt flags error with an orange dot in the left margin next to the line numbers and underlines the offending line. The exact error is displayed in the status bar, which can be a bit difficult to see. A better UX might be to display the error on hover of the error dot or the line in error (or both).
On long documents the dot may be obscured and require you to scroll. It is also displayed in the scroll map of the document on the right, but this may also be obscured until you scroll. The status bar is the place to look for errors on large documents, and if there is an error proceed to scroll the document the pin point it.
VSCode is one of my favorite editors. It's free and mutliplatform with a huge library of extensions. I run in on my Raspberry Pi without too much difficulty. It's built on Electron so it is a resource hog, but for it's free-ness I can live with that.
There are 2 extensions that I tried for XML validation. The XML tools extension can be added by clicking the extensions 'blocks' in left bar and searching for "XML".
The XML Tools Extension will validate an XML document and display an error message if the document is invalid. The error is displayed in the "Explorer" and there is no indication in the document itself that there is an error or where it is. For this reason, I would not use VS Code XML Tools for XML validation.
Red Hat's XML Language Support extension for VS Code provides by far the best XML validation experience. Validation Errors are underlined with a red squiggly line and hovering over an error displays the specific validation error message. This is exactly how I expect a validation tool to behave, especially a desktop validator.
You can see in the above screen shot that Red Hat XML validation has detected the improper nesting of the <a> element and is displaying an error pointing out the problem.
The XML Language Support extension running on VSCode is the clear winner. Make this your goto solution to quickly check XML files and configs!