XML EDITOR BENCHMARKS

A comparative hands-on test of XML-editor functionality at different file sizes.

DISCLAIMER

The author of this article is the developer of XMLBlueprint. XMLBlueprint therefore has a direct commercial interest in the results. To reduce the risk of author bias, the benchmark methodology, test files, generator, software versions, raw measurements, and videos are published so that the results can be independently reproduced.

WHAT IS AN XML EDITOR (IN THIS ARTICLE)

XML Editors come in many shapes and sizes. The three main types are:

• Graphical/Schema editors: Best for architects designing complex data structures.
• WYSIWYG editors: Best for content authors and publishers focusing on the end product.
• Text-based editors: Best for developers and data engineers who need raw XML data.

In this article we focus on the raw text-based functionality of these XML editors.

For the purpose of this article, this is a minimal XML editor:

• XML syntax coloring
• Context-aware XML auto-completion (rather than dumb XML auto-completion): It understands the exact hierarchical rules of the document. If you are inside a <book> element, the editor will only suggest <title> or <author>. It prevents you from inserting invalid tags before you even type them.
• Real-time XML validation (rather than manual XML validation): A modern text-based XML editor treats validation like a spellchecker. The engine constantly parses the document in the background. If you type an attribute that violates the schema or forget to close a tag, it throws a red squiggly line under the exact character as you type it.

For this benchmark, we consider an editor to retain full XML-editor functionality when all three benchmark capabilities remain available.

HOW WE TESTED

Hardware Specifications

All editors were tested on a standard Windows 11 laptop with the following specifications:

• Dell XPS 16 DA 16260
• Intel Core Ultra 5 325
• 16 GB of LPDDR5 running at 7467 MT/s
• Windows 11 64bit

Setup

• Every XML editor was freshly installed to its latest version, including any additional packages required to support XML.
• All applications were tested using their default memory settings.

Testing Protocol

• Isolation: Editors and test files were evaluated one-by-one. Each test began by launching the XML editor without any open files.
• Baseline CPU: To ensure runs were not affected by caching, background processes, indexing, or garbage collection, we monitored the Task Manager and waited until the editor's CPU usage dropped below 3% before initiating a test.
• Repetition & Verification: Each test was conducted five times, and the shortest time was recorded for the results. All tests were repeated a week later, yielding similar results.
• Measurement: Validation response times were measured to the nearest second to establish relative performance tiers, as exact millisecond metrics naturally vary based on user hardware.

The Three Core Tests

For every XML editor and test file, we tested the three specific features:

• Syntax Coloring: Open the test file and check if the editor displays different colors for elements, attributes, etc.
• XML-Completion: Open the test file, go to the end of the file (Ctrl+End), remove attributes lat and lon from the last <gpx:trkpt>, and check if the editor displays a dropdown with these attributes.
• Real-Time Validation: Open the test file, go to the end of the file (Ctrl+End), remove attributes lat and lon from the last <gpx:trkpt>, and check how long it takes for the editor to display an error that the attributes are missing. Validation response time measures the time until the validation error first appears in the editor's error list; it is not intended to measure the execution time of the underlying XML validation engine.

THE TEST FILES

The test files contain a GPX structure that is repeated many times until each file was of the desired size. Each GPX test file is validated against a GPX 1.0 schema. We saved the official GPX 1.0 schema locally from the official website (https://www.topografix.com/GPX/1/0/gpx.xsd) to ensure network latency didn't interfere with the real-time validation performance metrics. There's nothing special about the GPX schema, this is not a GPX test or GPX editor test. The basic structure is given in the appendix.

THE XML EDITORS

We tested these XML editors: Editix, Liquid Studio, Notepad++, Oxygen XML Editor, Stylus Studio, Sublime Text, Visual Studio, Visual Studio Code, XMLBlueprint, XMLSpy.

Editix - Editix does not support real-time validation, only real-time well-formedness check. For files of size 100 MByte and larger Editix hangs.

Liquid Studio - At 25 MByte Liquid Studio no longer provides XML-editor functionality and falls back to plain text editing.

Notepad++ + Package XML Tools - Notepad++ does not support XML-Completion and Real-Time Validation.

Oxygen XML Editor - At 50 MByte Oxygen XML Editor switches to large file mode and no longer provides real-time validation. At 500 MByte Oxygen XML Editor switches to huge file mode and loads the file in pages (chunks) to conserve memory.

Stylus Studio XML Home Edition - Stylus Studio does not support real-time validation, not even real-time well-formedness check. Stylus Studio was the only xml editor we tested where XML-Completion was slow when editing at the end of large files.

Sublime Text + Package LSP and Package LSP-lemminx - At 25 MByte Sublime Text no longer provides XML-editor functionality and falls back to plain text editing. Changing to View>Syntax>XML changes only syntax coloring to XML.

Visual Studio Community + Workload .NET desktop development - At 500 MByte Visual Studio Community no longer provides XML-editor functionality and falls back to plain text editing.

Visual Studio Code + Extension: XML Language Support by Red Hat - At 100 MByte Visual Studio Code no longer provides XML-editor functionality and falls back to plain text editing.

XMLBlueprint - XMLBlueprint provides XML-editor functionality for all the file sizes we tested. However, the real-time validation response time started lagging at 250-500 MByte.

XMLSpy - At 50 MByte XMLSpy no longer provides XML-editor functionality and falls back to plain text editing.

ADDITIONAL TESTS

SPEED TEST

During our testing we noticed that some editors felt slower than other editors.

To test this, in each editor we opened the 10 MByte file, jumped to the end of the file and pressed and held the backspace key to delete the file character by character.

We stopped deleting at the last "<gpx:trkseg>" in the file.

Almost all editors took 27 sec to do this. The time it takes to delete all characters depends on the keyboard repeat rate, which was set to fast.

There were three exceptions:

• Sublime Text took 63 sec.
• Liquid Studio took 83 sec.
• Notepad++ took 98 sec.

Holding down Backspace triggers re-parsing/re-rendering on every single character deletion; editors that freeze or stutter are blocking the main UI thread with synchronous parsing or undo-stack overhead.

ENTERPRISE SCHEMA BENCHMARK (FpML)

To evaluate how these editors handle complex, real-world data architectures, we tested them against the Financial products Markup Language (FpML) 5.13 Confirmation View. FpML relies on massive, deeply nested, and highly modular XSD schemas that often break basic parsers. We tested the editors for strict contextual auto-completion (resolving specific choice groups), real-time sequence error detection, and cross-file schema navigation.

• The Top Performers: Oxygen XML Editor, Visual Studio Code (with Red Hat XML), XMLBlueprint, and XMLSpy successfully passed all structural validation tests. They instantly resolved the modular schemas, enforced strict sequence ordering in real-time, and accurately restricted auto-completion choices based on the exact document context.
• Navigation UX: While XMLSpy provided flawless structural validation, its code-navigation options are buried under the top-level menu (DTD/Schema > Go to Definition) rather than utilizing modern context-menu or inline code shortcuts (like Ctrl+Click). This makes tracing complex schema references more tedious compared to Oxygen XML Editor, Visual Studio Code, and XMLBlueprint.
• The Enumeration Limit: None of the editors flagged invalid FpML data codes (e.g., typing "INVALID_CURR" instead of "USD"). This is not an editor failure, but an architectural limitation of standard XSD validation. FpML uses external URIs (Coding Schemes) rather than hardcoded XMLSchema enumerations, requiring secondary rule-based validation (like Schematron) to enforce.

CONCLUSION

Ten XML editors were tested on test GPX files of increasing sizes on a Windows 11 machine to observe when they dropped core XML functionalities:

The 25 MB Threshold: While this benchmark scales up to 1000 MB, the most critical finding for standard developers is how quickly popular tools fail on moderately sized data. Half of the tested editors including Sublime Text, Liquid Studio, Oxygen XML Editor, and XMLSpy - lost core XML functionalities, disabled real-time validation, or reverted completely to plain text between just 25 MByte and 50 MByte.

• XMLBlueprint: Was the only editor tested that retained full XML functionality (syntax coloring, completion, and real-time validation) for files up to 1000 MB. The real-time validation response time started lagging between 250 MB and 500 MB.
• Visual Studio Community: Retained full XML functionality up to 250 MB, but reverted to plain text editing at 500 MB.
• Visual Studio Code: Reverted to plain text editing once files reached 100 MB.
• Oxygen XML Editor & XMLSpy: Oxygen XML Editor disabled real-time validation (Large File Mode) at 50 MB, while XMLSpy reverted entirely to plain text editing at 50 MB.
• Liquid Studio & Sublime Text: Both editors reverted to plain text editing when handling files of 25 MB.
• Editix, Notepad++, & Stylus Studio: These editors failed to provide real-time validation across any of the tested file sizes. Furthermore, Editix hung completely on files 100 MB or larger.

APPENDIX

VIDEOS

Notepad++ - Backspace in 20 MByte.

Oxygen XML Editor - Real-time Validation in 10 MByte, No Real-time Validation in 20 MByte.

XMLBlueprint - Backspace in 20 MByte.

XMLBlueprint - Real-time Validation in 500 MByte.

XMLBlueprint - Real-time Validation in 1000 MByte.

Stylus Studio - Hangs in 20 MByte.

XML EDITOR VERSIONS

We tested these XML Editors:

TEST FILES

This is an example of a typical GPX test files we used. The actual test files were much larger than this one:

<?xml version="1.0" encoding="UTF-8"?>
<gpx:gpx creator="creator" version="1.0" xmlns:gpx="http://www.topografix.com/GPX/1/0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.topografix.com/GPX/1/0 gpx.xsd">
 <gpx:name>name</gpx:name>
 <gpx:desc>desc</gpx:desc>
 <gpx:author>author</gpx:author>
 <gpx:email>G.G@v.X</gpx:email>
 <gpx:url>https://www.example.com/gpx/</gpx:url>
 <gpx:urlname>urlname</gpx:urlname>
 <gpx:time>2006-05-31T04:51:00</gpx:time>
 <gpx:keywords>keywords</gpx:keywords>
 <gpx:bounds maxlat="-90.0" maxlon="180.0" minlat="-90.0" minlon="180.0"/>
 <gpx:trk>
  <gpx:name>name</gpx:name>
  <gpx:cmt>cmt</gpx:cmt>
  <gpx:desc>desc</gpx:desc>
  <gpx:src>src</gpx:src>
  <gpx:url>https://www.example.com/gpx/</gpx:url>
  <gpx:urlname>urlname</gpx:urlname>
  <gpx:number>+99</gpx:number>
  <gpx:trkseg>
   <gpx:trkpt lat="-90.0" lon="180.0">
    <gpx:ele>3.1415926535</gpx:ele>
    <gpx:time>2006-05-31T04:51:00</gpx:time>
    <gpx:course>0.0</gpx:course>
    <gpx:speed>3.1415926535</gpx:speed>
    <gpx:magvar>360.0</gpx:magvar>
    <gpx:geoidheight>3.1415926535</gpx:geoidheight>
    <gpx:name>name</gpx:name>
    <gpx:cmt>cmt</gpx:cmt>
    <gpx:desc>desc</gpx:desc>
    <gpx:src>src</gpx:src>
    <gpx:url>https://www.example.com/gpx/</gpx:url>
    <gpx:urlname>urlname</gpx:urlname>
    <gpx:sym>sym</gpx:sym>
    <gpx:type>type</gpx:type>
    <gpx:fix>2d</gpx:fix>
    <gpx:sat>+99</gpx:sat>
    <gpx:hdop>3.1415926535</gpx:hdop>
    <gpx:vdop>3.1415926535</gpx:vdop>
    <gpx:pdop>3.1415926535</gpx:pdop>
    <gpx:ageofdgpsdata>3.1415926535</gpx:ageofdgpsdata>
    <gpx:dgpsid>1023</gpx:dgpsid>
   </gpx:trkpt>
  </gpx:trkseg>
 </gpx:trk>
</gpx:gpx>