wow.export reads the game client you already have, and the CDN when you do not

A desktop extractor for a game client, not a data library

wow.export is described in the repository as the number one export toolkit for World of Warcraft, providing tools for extracting and converting files from the game client or from public CDN servers. The primary language of the repository is listed as JavaScript, and the licence is MIT.

The first thing to understand is what kind of project this is. It is a desktop application, not a library, and the primary language is JavaScript because the interface is a web view, not because you are meant to import it. The package.json lists Vue as a dependency alongside adm-zip, rcedit and webp-wasm, and the engines field requires bun at 1.2.0 or newer.

The repository layout says the same thing. There is a src/ directory, an addons/ directory for the Blender add-on, an installer/ directory, an updater/ directory, a node_addons/ directory for native modules, a resources/ directory, and build.js, build.json and publish.js at the top level for the release tooling. There is a trigger_release.js script, a bun.lock file and a tsconfig.json.

So the shape is an application with an installer, an auto updater, native add-ons and a release pipeline, all of which is unusual to see in a repository that is nominally JavaScript. It is an Electron style desktop tool with the packaging work done in Bun.

Two people are credited as contributors in the package metadata, Kruithne and Marlamin, and the installation instructions point to a site rather than to a package registry.

Three ways in: local client, legacy MPQ, or streaming from the CDN

The features that matter are the ones about where the files come from, because that is the actual problem when you want to extract something from World of Warcraft.

The first is local. wow.export supports legacy MPQ-based installations for local browsing, and it can convert local M2 and BLP files by drag-dropping them onto the application. That drag and drop line is a small but revealing design choice, because it means the common case, converting a single model or texture you just pulled out of a directory, does not require you to configure a client path first.

The second is online. There is complete online support allowing streaming of all files without a client, pulling from the public CDN servers. For a user with no game installation at all, that is the difference between the tool being usable and not.

The third is the client itself, and both Retail and Classic game clients are supported.

Together these three cover the realistic situations. You have a modern installation, you have an old MPQ archive from a previous version, or you have nothing and want to browse the live game data remotely.

The 13 language support line fits here too, since locale support for all 13 languages supported by the client means the text and script extraction covers the whole localised game rather than one language.

Models, maps, sound, video and the DB2 database, in one tool

The feature list is long, and the interesting thing is how much game data it touches.

For models there is a full 3D preview of both M2 and WMO, doodads included, and export as OBJ, GLTF and more. For maps there is an overhead map viewer with easy exporting of terrain, textures and objects, plus the ability to view and export all in-game zone maps, and a Blender add-on for advanced map and model importing.

For audio and video, the tool previews and exports all sound files and all video files, the latter described as cinematics, from the game client.

Then the parts that are really for data people. There is a DB2 database viewer for exploring game data, the ability to view all in-game text, interface and scripts, and preview and export of all in-game font files.

The DB2 viewer and the script viewer are the two that go beyond extraction. A DB2 file is the client side database, and being able to browse it turns the tool from a converter into a data exploration environment.

The WMO support deserves a note because it is the newer model format. A toolkit that handles M2 and WMO, with doodads, covers both generations of World of Warcraft models, and a tool that only handled the older format would be much less useful now.

Installing is a download, and updating is a prompt in the app

The installation section is short. To install wow.export, navigate to the site and download the latest version, and that is the whole process. There is no package manager entry, no command line install, and no npm publish of the application itself.

That is consistent with the rest of the project. The package.json is private in spirit, it is the manifest of the application, not a distributable package, and the release pipeline lives in the repository with build.js, publish.js and trigger_release.js plus an installer/ directory and an updater/ directory.

Updates work the same way. When an update to wow.export is available, you are prompted in the application to update, and the README says this process is done entirely automatically once you accept the update.

So the update model is the desktop application one, with an in-app updater rather than a package manager pulling a new version. For a tool that has to track a game client whose files change, that is a reasonable design, since a version of the toolkit that understands this patch's data is the version you want.

For anyone building from the repository, the manifest pins the runtime and the dependencies.

	"engines": {
		"bun": ">=1.2.0"
	},
	"dependencies": {
		"adm-zip": "git+https://github.com/cthackers/adm-zip.git#1c7860ff5005cd30bf5dc6e557c9b312fedc0a66",
		"rcedit": "^2.0.0",
		"vue": "^3.5.21",
		"webp-wasm": "^1.0.6"
	},

The @types/bun package is the only dev dependency, and a bun.lock file at the top level records the resolved tree.

The changelog and the roadmap, and what they tell you to expect

Two sources of project status are documented, and they answer different questions.

The historical record is the CHANGELOG.md file in the repository, which the README describes as a full historical changelog of every major release. It is also available inside the application, by choosing View Recent Changes from the top-right context menu.

The forward-looking record is a public roadmap on the project's GitHub projects page, and the README is careful about what it promises. It says the roadmap is constantly changing with no fixed timeline, and that features are not guaranteed to be implemented until they are marked as complete.

That is the right warning to have, and it is a sentence worth reading before you plan around a feature. A toolkit that follows a live game client is by nature a moving target, and the person maintaining it has to be honest that the ordering of work is not fixed.

The version numbers support that reading too. The recent releases are 0.2.19 and 0.2.18 on the same day in June 2026, and 0.2.17 in May, so the patch level moves often while the minor level has not moved past 0.2.

The repository is not archived and the last push was on 2026-10-19, so work is landing on main. The primary language is JavaScript and the licence is MIT, and the contributors field names Kruithne and Marlamin.

Where wow.export is the wrong tool

There is one hard boundary and two soft ones, and none of them are about the tool's quality.

The hard boundary is a legal one about the data, not the code. wow.export reads files from a game client and from public CDN servers. The tool is MIT licensed, and that licence covers the software. It does not grant any rights over Blizzard's game assets, and redistributing extracted models, textures or sounds is a different question from running the extractor. The repository has a LEGAL directory alongside the LICENSE file, which is where to look for what the author considers the position. Anyone planning to publish extracted assets should read it, and this is a description of where to look rather than advice on the law itself.

The first soft boundary is the interface. This is a desktop application with a specific set of workflows, not a command line tool or a library, so if your requirement is to run extraction in a pipeline or on a server, the repository does not offer that. The npm manifest describes an application, not a consumable package.

The second is the pace. A tool that tracks a live game client has to change when the client changes, and the README is explicit that the roadmap has no fixed timeline. If your work depends on a specific feature existing at a specific time, the honest answer is that the project will not commit to it.

What it is very good for is one person at a desk who wants to look at a model, hear a sound, read a script, check a DB2 table, or pull a map out of a game they play.

Editorial conclusion

Adopt wow.export if you work with World of Warcraft game data, whether as a modder, a texture artist, a data analyst or someone who wants to pull a sound or a map out of a client that is already installed. Do not adopt it expecting a stable public API, since the package is a desktop application with a 0.x version and the README says nothing about a library surface, and note that the client data it reads is not yours to redistribute. Before you start, install the published build rather than trying to build from source, read the CHANGELOG for what changed in the last release, and check the project's public roadmap for what is still planned.

Frequently asked questions

Official sources

1. Issues
2. Kruithne/wow.export on GitHub
3. License: MIT
4. README
5. Releases