# fast-xml-parser: three exported classes, two of which the readme tells you to import from elsewhere

> NaturalIntelligence's fast-xml-parser validates, parses, and builds XML in pure JavaScript, and its documentation spans three version generations at once. The unusual part is the readme itself: it opens with four recommended alternatives, tells you not to use the built-in validator, and points you at a separate package for the builder it used to ship.

**NaturalIntelligence/fast-xml-parser** — Validate XML, Parse XML and Build XML rapidly without C/C++ based libraries and no callback.

- Repository: https://github.com/NaturalIntelligence/fast-xml-parser
- Website: https://naturalintelligence.github.io/fast-xml-parser/
- Stars: 3,140 · Forks: 396
- Language: JavaScript
- License: MIT
- Published: 2026-09-24 · Updated: 2026-09-24 · Language: en
- Canonical page: https://hysenlabs.com/projects/naturalintelligence-fast-xml-parser

## The readme opens by recommending four other projects

Before describing how to use anything, the document lists what to use instead.

Flexible-XML-Parser is described as 1.25 times faster than this library when the order of tags is not preserved, taking less memory on big files and supporting incomplete XML or HTML. A second entry, @nodable/sax, is a SAX parser built on top of that one and is said to be three to four times faster than sax. The remaining two are separated out of this package itself: fast-xml-validator, which is described as faster and able to exclude a particular tag from validation, and fast-xml-builder, which was the XML to JavaScript object builder used in this package in the past and is now recommended for direct use.

There is a fifth recommendation above them, marked important: use fast-xml-validator rather than the inbuilt validator. Two of the package's three exported pieces have therefore been spun out and pointed at from inside the package's own documentation.

## Three classes are exported, and the example uses all three

The public surface is three classes in one import:

```
const { XMLParser, XMLBuilder, XMLValidator} = require("fast-xml-parser");

const parser = new XMLParser();
let jObj = parser.parse(XMLdata);

const builder = new XMLBuilder();
const xmlContent = builder.build(jObj);
```

The parser and the builder are the two halves of the round trip, and the validator is a third export sitting beside them. So the import a user writes still pulls in all three, including the one the documentation tells them not to use.

The feature list underneath is what the parser covers rather than how to call it: syntactic validation, parsing to objects and back, common JS, ESM and browser compatibility, XML entities, HTML entities, and DOCTYPE entities, unpaired tags such as `<br>` in HTML, stop nodes such as `<script>`, big files with the claim of having been tested up to 100mb, and the option to preserve the order of tags inside the resulting object.

## Three document generations sit in one table, and v6 has an empty entry

The documentation index is a three column table for v3, v4 and v5, and v6.

The v3 column has a single link labelled documents. The v4 and v5 column has eight pages, covering getting started, the parser, the builder, the validator, entities, HTML parsing, processing instruction tags, and path expressions. The v6 column contains an ordered list whose first item is empty and whose only populated item is a Getting Started link.

The notes underneath explain the arrangement in two sentences. Version 6 is released with version 4 for experimental use, and based on its demand it will be developed, with features that can differ in the final release. Version 5 has the same functionalities as version 4.

So the manifest currently reads 5.11.2 while the published major is functionally identical to 4, and a sixth generation exists in the tree as an experiment running alongside 4 rather than after 5.

## Two entry points ship, one in source and one built, with two declaration files

The manifest is careful about module formats, and the package publishes both halves.

The type field is module and side effects are declared false. The main field points at ./lib/fxp.cjs, the module field at ./src/fxp.js, and the types field at ./src/fxp.d.ts. The exports map then splits the two worlds: an import condition resolving to src/fxp.js with types from src/fxp.d.ts, and a require condition resolving to lib/fxp.cjs with types from src/fxp.d.cts.

So the CommonJS build in lib and the ESM source in src both ship, and the type declarations are split across a .d.ts for the import side and a .d.cts for the require side. The published files are those two directories plus the changelog, which leaves docs, spec, benchmark, static, index.html and the user list as development-only material.

The browser bundles are a separate matter: the readme names four of them by size, and the package declares one webpack configuration. Nothing here maps a config entry to a bundle name.

## The performance section names its axes and prints no numbers

There is a Performance section with a note that negative means error, and two subsections. For the XML parser it names a Y axis of requests per second and an X axis of file size. For the XML builder it names a Y axis of requests per second and stops there.

No figures appear in the text, while the opening claim is that this library is faster than any other pure JavaScript implementation. So the comparative numbers in this document are all about other projects: the 1.25 times figure for Flexible-XML-Parser, and the three to four times figure for @nodable/sax against sax.

The local measurement path does exist. A perf script runs node on benchmark/perfTest3.js, and a usage trend link points at an npm comparison page over a three year range. What the readme does not do is put this package's own numbers in a form you can read without the charts.

## The CLI runs from source, and the test suite has a typings check

There is one binary, named fxparser, mapped to src/cli/cli.js, and the whole command is one argument:

```
$ fxparser some.xml
```

The bin path points into src, which is one of the published directories, so the installed command runs the shipped ESM source rather than the built bundle in lib.

The scripts cover the four things a contributor would run. Tests are jasmine under c8 with both an lcov and a text reporter over spec files, with a separate unit script that is plain jasmine and a separate typings check that runs the TypeScript compiler in no-emit mode against a typings test file. Performance runs the benchmark script, lint covers src, spec and benchmark, and there are bundle and prettier scripts plus a preversion hook that runs the full test suite.

The devDependencies mix eras on purpose or by accident: the Babel packages sit at 7.13 with babel-loader at 8.2.2, eslint at 8.3, and prettier at 3.5 with jasmine at 5.6. There is also a package called @byspec/xml at version 0.1.0, which looks like a conformance suite rather than a helper.

## Two lockfiles, two todo files, and four config files for outside services

The root of the repository carries more files than a package of this size usually keeps.

There are two lockfiles, package-lock.json and yarn.lock, so dependency resolution is reproducible under two different clients. There are also two to-do files, TODO.md and nexttodo.md, rather than one.

Four configuration files point at things outside the repository: .bithoundrc, .codeclimate.yml, .publishrc, and .sensitivedata. Alongside them sit the ordinary ones, .babelrc, .eslintrc, .prettierrc, .gitattributes, and .npmignore, plus a .vscode directory and an index.html with a static directory that together form a page which is not published.

The user list is kept in its own file, USERs.md, linked as more from a list that names nineteen projects and organisations from renovate to Baidu, with a line under it offering correction if any entry is wrong. The financial section asks for sponsorship through GitHub Sponsors and OpenCollective and carries a donation notice stating that no goods or services are expected in return.

## Conclusion

Use it if you want XML and JavaScript objects in both directions without a native module and without a callback, and pin a major version deliberately, because the documentation for v3, v4, v5 and v6 sits in the same table and the notes say v5 has the same functionality as v4. Read the alternatives section before choosing: the project itself recommends a different parser when tag order is not preserved, a different validator, and a different builder. And run the perf script yourself rather than trusting the headline speed claim, since the readme gives figures for other projects and leaves this one's measurements as charts.

## FAQ

### how to use fast xml parser

Install it with npm install fast-xml-parser or yarn add fast-xml-parser, then import the three exported classes and use parser.parse and builder.build. For a command line check there is a binary named fxparser that takes a file argument, and for a page you can include fxp.min.js from a CDN and construct a parser from the fxparser namespace.

### install fast xml parser

Three documented routes. As a dependency, npm install fast-xml-parser or yarn add fast-xml-parser. As a system command, npm install fast-xml-parser -g. In a browser, include it from a CDN, where the readme points at the cdnjs listing for fast-xml-parser, using fxp.min.js and the fxparser namespace.

### What is fast xml parser used for?

Three jobs: validating XML syntactically, parsing XML into JavaScript objects, and building XML back from a JavaScript object. It also handles XML entities, HTML entities and DOCTYPE entities, unpaired tags such as <br>, stop nodes such as <script>, can preserve tag order inside the object, and is described as tested on files up to 100mb.

### Is fast xml parser faster than other xml parsers?

The readme claims it is faster than any other pure JavaScript implementation, but presents this package's own numbers as charts with axis labels rather than figures. It does give relative figures for the alternatives it recommends, including one said to be 1.25 times faster when tag order is not preserved. A perf script running benchmark/perfTest3.js is what performs the local comparison.

### Should I use the built-in validator in fast xml parser?

Not according to the readme, which marks a note as important and recommends the separate fast-xml-validator package over the inbuilt validator, and separately points at detailed-xml-validator for checking business rules. The XMLValidator class is still exported from the main entry point alongside XMLParser and XMLBuilder.

### Which major version of fast xml parser should I use?

The manifest is at 5.11.2 and the documentation covers three generations in one table: v3, v4 and v5, and v6. The notes say version 5 has the same functionalities as version 4, and that version 6 is released alongside version 4 for experimental use, with features that can differ in the final release.

## Sources

- [License: MIT](https://github.com/NaturalIntelligence/fast-xml-parser/blob/master/LICENSE)
- [NaturalIntelligence/fast-xml-parser on GitHub](https://github.com/NaturalIntelligence/fast-xml-parser)
- [Project website](https://naturalintelligence.github.io/fast-xml-parser/)
- [README](https://github.com/NaturalIntelligence/fast-xml-parser/blob/master/README.md)
- [Releases](https://github.com/NaturalIntelligence/fast-xml-parser/releases)

---

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