VPKEdit: an editor for the pack files of Source, Quake and Godot
A CLI/GUI tool to create, read, and write several pack file formats.
At a glance
- What is it?
- VPKEdit is a C++ tool that creates, reads, writes, and previews more than twenty pack file formats, from Valve's VPK to Quake's PAK to Godot's PCK, with a graphical interface and a dependency-free command line tool built on the sourcepp parsers. Its scope is deliberately limited to GoldSrc and Source 1, and the README says so directly.
- Who is it for?
- VPKEdit fits a modder or tool developer who works with the archives of the older Source and Quake engines, who wants one program that both previews and rewrites a pack rather than a different utility per format, and who is comfortable with a tool that is specific to the older engines.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 38 days ago.
- What is it written in?
- Mainly C++, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 22, 2026, and from our analysis. They are not legal advice.
Editorial analysis
Twenty pack formats, one program
VPKEdit is an open source, MIT licensed tool that can create, extract from, preview the contents of, and write to several pack file formats. The project description is a CLI and GUI tool for that purpose, and the language is C++.
The reason such a tool exists is worth stating, because it explains the shape of the thing. The pack file is the container format that the Source and Quake family uses to ship game assets, and every engine generation invented a slightly different one. A developer who wants to look inside a VPK needs one tool, a developer who wants to look inside a Quake PAK needs another, and a developer who wants to look inside a Godot PCK needs a third. VPKEdit is the attempt to have one.
The screenshot list in the README shows the range: a VPK with an MDL preview in wireframe mode, the same in shaded textured mode, a BSP with a VTF preview, and the command line version.
The licensing and the distribution are simple. The licence is MIT, the homepage points at the Valve developer wiki page for the tool, and there is a Discord server and a donation link alongside the badges. The project is not archived, the last push was on 2026-09-15, and the release history is a set of 5.0.0 betas, with the most recent being a 5.0.0 beta 4 from 2025-12-08 and earlier ones from October 2025.
The versions are interesting in themselves. The releases are named as 5.0.0.4 and 5.0.0.3 in the tag list, and the release notes themselves refer to them as 5.0.0-beta.4 and 5.0.0-beta.3, so the tool has been in beta across several patch numbers, which suggests a large amount of change since the 4.x line rather than a series of small fixes.
The format table, and what create and write actually mean
The supported formats table is the centre of the README, and it has four columns: the format, a description, and then whether the tool can create, read, or write it.
Reading the create and write columns against each other is the useful part, because the two are not the same thing. A format can be read and written without being creatable, which means the tool can add and remove files inside an existing archive but cannot produce an empty one from scratch.
The formats that are fully creatable, readable, and writable are the majority. They are the Axiom pack file, the BEE 2.4 package, the Bonus Map Zip for Source Engine, the FGP file group, the FPX VPK modification, the PAK file used by Quake I and II, the original Half-Life, and HROT, the Godot pack file standalone or embedded, the PK3 pack used by Quake III, Return to Castle Wolfenstein, and Wolfenstein: Enemy Territory, the PK4 pack used by Quake IV and Doom 3, the PKZ pack used by Quake II RTX, the Valve VPK, the Vampire VPK for V:TMB, the WAD file from the GoldSrc engine, and the plain ZIP file.
The read only ones are a different story. The 007 asset pack from Nightfire, the Game Cache File used by the pre-SteamPipe Steam games, the HOG file from Descent, the Worldcraft Object Library, the ORE file from Narbacular Drop, the Volition pack used by Red Faction and Saints Row, the Xbox ZIP for the original Half-Life 2, and the SiN pack file.
Two of those read only entries have a specific reason, and the reason is a nicety worth noting. The Garry's Mod addon format and the SiN pack file can both be read and written, but neither can be created from scratch. The 007 format is read only as well, and the Worldcraft Object Library, which is the file format that shipped with the Half-Life level editor, is the other one in that group.
The Source 1 Map, the BSP, is marked as not applicable for create, which is correct, since a BSP is compiled rather than packed.
Previewing a file without extracting it
The preview feature is the one that makes the tool more than a zip utility, and the list of what it can preview is the most useful part of the feature list.
Audio is previewed. Text files in any encoding are previewed. KeyValues files, which are the text files with syntax highlighting that the engine uses for configuration, are previewed with that syntax highlighting applied. Images are previewed.
Then the engine specific formats. Source 1 textures are previewed, and the sub-list names the variants: prop lightmaps, Troika textures, and Valve textures for both PC and console. Source 1 models are previewed, and the DMX files that cover particles and Source Filmmaker sessions are previewed too.
That last set is the reason a dedicated tool exists at all. A VTF is a texture format with several distinct kinds of content depending on how it was authored, and a DMX is a scene description, and neither is a thing a general archive viewer can show. Previewing them without extracting means you can find the asset you want in a multi thousand file archive and then extract only that one.
The editing side is equally practical. You can create pack files of any version from scratch or from an existing folder, add and remove files and folders from writable pack files, and directly edit text files within writable pack files, which is the capability that turns it from an archive browser into an editor.
There is also a version switcher, described as switching the version of existing VPKs. The Valve VPK format has gone through several revisions, and being able to move a pack from one version to another is a chore that has been automated away.
A graphical interface and a dependency free command line tool
VPKEdit comes in two forms, and the split is deliberate rather than a build artefact.
There is the desktop application with the preview panels, the wireframe and shaded textured modes for models, and the translated interface. And there is a separate application with no external dependencies, called vpkeditcli, which provides the command line interface.
The dependency-free CLI is the more interesting of the two for a build engineer, and the reason it matters is that it can be dropped into a pipeline without dragging a GUI toolkit along with it. A continuous integration job that needs to list the contents of a VPK, or extract one file out of it, or repack a directory, can call a single binary that needs nothing else on the machine.
The keyboard shortcuts are documented separately, in a controls file at the root of the repository, and the planned features are tracked as GitHub issues labelled as an enhancement, which is a low ceremony way to run a roadmap for a project with a single maintainer.
The engine behind all of this is stated in a short section at the end of the README. The tool is powered by a collection of open source C++20 Source engine parsers called sourcepp, and the repository carries it as a git submodule under an ext directory, with the build driven by CMake and a create_sln.bat script for generating a Visual Studio solution.
That dependency is worth understanding, because it explains both the quality and the scope. The parsers are the hard part of reading a VTF, a MDL, a BSP, or a DMX, and reusing a dedicated C++20 implementation of them means VPKEdit inherits their correctness instead of writing its own. It also means the tool tracks the parsers, and the parsers track the engines.
Translations, packaging, and how the project takes contributions
Two things about the project's shape are worth noting, because they say something about who it is for.
The first is the translation coverage. The user interface is translated into fifteen languages, and the README links a translation platform where anyone can contribute. The list includes Bosnian, Chinese, Croatian, Dutch, German, Italian, Japanese, Korean, Polish, Brazilian Portuguese, Russian, Slovenian, Spanish, Swedish, and Vietnamese.
The second is the contribution model, and it is unusually open for a tool of this kind. The project accepts a wide range of contributions, mostly code and translations. Code goes through the GitHub repository, and translations are open to everyone and need only a free account on the translation platform. Contributors are credited in a text file shipped with the command line application and in a popup in the graphical application, which is a nice touch, since the credits travel with the binary rather than living only on a website.
On packaging, the README says VPKEdit is available for Windows 7 and later and for macOS on arm64, and has been packaged for multiple Linux distributions. The native Linux builds are packaged for Arch, Debian, Fedora, and NixOS, with standalone builds available as well. The Windows 7 floor and the macOS arm64 target both tell you something about who the platform list was chosen for.
Installation itself is delegated to a separate install document at the root of the repository, which is where the step by step instructions live, and the repository also has a controls file, a code of conduct, a credits file, and a licence.
The last piece of the project identity is the shared history. The star history graphic at the end of the README and the list of formats that span Quake, Half-Life, Doom, Saints Row, Garry's Mod, Narbacular Drop, and Godot all point at the same thing: this is a tool for the long tail of engines built on the id tech lineage and its descendants, which is a community that is large, knowledgeable, and accustomed to patching its own assets.
The Source 2 boundary, stated plainly
The README carries a note that decides who should use this tool, and it is worth reading before anything else.
It says that if you need to edit files for a Source 2 game, you should consider using a different application instead, because this application targets GoldSrc and Source 1, and will not parse any Source 2 file types. The link points to Source 2 Viewer.
That is a clean boundary rather than a vague one, and a clean boundary is more useful than a partial support claim. The VPK format exists in both the Source 1 and Source 2 engines, and the versions differ enough that a tool built for the older one produces wrong results on the newer one rather than an error, so the responsible thing is to refuse the work outright.
The practical consequence is that VPKEdit serves a specific and still substantial community. The GoldSrc engine, which is the Half-Life 1 branch, and the Source 1 branch, which is the Half-Life 2 and the games built on it, are both alive with mods, and both use the pack formats the tool reads and writes. The Quake lineage formats are in the same position, with the WAD, the PAK, and the PK3 and PK4 all still in use by the communities that grew up around them.
So the boundary is not a sign of a project that has fallen behind. It is a sign of a project that knows exactly which half of the ecosystem it serves, and has decided to serve that half properly, with a preview for the texture and model formats of that era, a version switcher for the VPK revisions of that era, and a format list that includes the obscure ones, from the Worldcraft Object Library to the Xbox ZIP, precisely because somebody still needs them.
For a user outside that world, the honest summary is that this is a well made, actively developed, MIT licensed tool for a specific and well understood set of file formats, and that the formats it does not support are a decision rather than an omission.
Editorial conclusion
VPKEdit fits a modder or tool developer who works with the archives of the older Source and Quake engines, who wants one program that both previews and rewrites a pack rather than a different utility per format, and who is comfortable with a tool that is specific to the older engines. It does not fit anyone whose work involves Source 2 assets, since the tool states that it targets GoldSrc and Source 1 and will not parse any Source 2 file types, and the README points those users at a different application. Verify first that the format you need appears in the supported table with the create and write columns marked, because several formats are read only, that the Source 2 boundary is not in your way, and that you know the tool is MIT licensed and accepts contributions, with translations handled through a separate service.
Frequently asked questions
What file formats does VPKEdit support?
More than twenty, including the Valve VPK, Quake PAK, PK3, PK4 and PKZ, the Godot PCK, the WAD, the Bonus Map Zip, the FGP file group, the BEE 2.4 package, the Axiom pack, the FPX VPK modification, the plain ZIP, and the Vampire VPK, each with its own create, read, and write support.
Can VPKEdit edit Source 2 game assets?
No. The README says the application targets GoldSrc and Source 1 and will not parse any Source 2 file types, and it points people who need Source 2 editing at a different application. The boundary is deliberate, because the VPK format differs between the two engine generations.
What can VPKEdit preview without extracting the files?
Audio, text files in any encoding, KeyValues files with syntax highlighting, images, Source 1 textures including prop lightmaps, Troika textures and Valve textures for PC and console, Source 1 models, and the DMX files used for particles and Source Filmmaker sessions.
Does VPKEdit have a command line version?
Yes. A separate application with no external dependencies, called vpkeditcli, provides the command line interface, while the desktop application provides the previews and the translated interface. Keyboard shortcuts for the application are documented in the controls file in the repository.
How is VPKEdit built and what does it depend on?
The build is driven by CMake, with a script to generate a Visual Studio solution, and the tool is powered by a collection of open source C++20 Source engine parsers called sourcepp, which is carried as a git submodule. The project is MIT licensed and accepts code and translation contributions.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/craftablescience-vpkedit)Was this useful?