Source 2 Viewer: browsing, extracting and decompiling Valve's compiled assets

What problem Source 2 Viewer solves, and for whom

Source 2 games do not ship loose assets. They ship compiled resource files: models, materials, textures, maps, sounds and particles in Valve's own binary container formats. There is no official documentation for any of it. The README is direct about this: the tool is "based entirely on reverse engineering as Valve does not provide Source 2 documentation or code, so not all formats are fully supported."

That sentence is the whole pitch and the whole caveat. Source 2 Viewer exists because the only way to see what is inside a compiled asset is to have someone work out the layout by hand, and a group of contributors has been doing that for years. The README calls it "the result of years of reverse engineering by many contributors."

The audience is narrower than a general file viewer. It is for people doing mod work, asset porting, tooling around Source 2 titles, or research into how the engine stores data. If you have ever wanted to know why a material renders a certain way, or you need a mesh out of a map and into a modelling package, this is the tool that reads the file at all.

Three products in one repository: library, CLI and GUI

The repository is not a single application. The README describes it as "a viewer application, a command line decompiler, and the ValveResourceFormat library." The top-level layout reflects that split: GUI/, CLI/, Renderer/ and ValveResourceFormat/ sit alongside Tests/ and docs/, with a single solution file, ValveResourceFormat.slnx.

The library is the foundation and is published to NuGet under two names. ValveResourceFormat handles parsing and exporting. ValveResourceFormat.Renderer is the OpenGL renderer, kept separate so that a headless tool does not have to pull in graphics code. That separation is a real design decision, not packaging noise: a batch converter has no reason to load a renderer.

The CLI is the batch path. The GUI is the interactive path, where you browse an archive, preview an asset and export it. All three share the same parsers, so a format that the GUI can preview is a format the CLI can process, subject to what the format support reference says about each one.

One detail worth noting for anyone embedding this: the project asks for attribution. If you run a binary, read the repository to work out a format, or copy code, the README asks you to credit Source 2 Viewer in your own readme, and to link it in the application interface if your project is substantially built on it. That is a request, separate from the licence.

Getting started: install and a first export

The README does not document an install command. It points to https://s2v.app/ for the download, and the repository's own build inputs are a .NET solution (ValveResourceFormat.slnx) with a global.json pinning the SDK. So the honest first step is the download page, not a shell one-liner.

If you want the library rather than the application, the README names the NuGet packages directly. These are the two package IDs it lists:

# NuGet package IDs named in the README
ValveResourceFormat
ValveResourceFormat.Renderer

The second package is only needed if you want the OpenGL renderer alongside the parsers. The README links a getting started guide at https://s2v.app/ValveResourceFormat/guides/read-resource.html for reading a resource, and an API reference at https://s2v.app/ValveResourceFormat/api/ValveResourceFormat.html. Those two pages are where the actual type names and call sequence live; the README itself does not reproduce them.

For the graphical route, the workflow the README describes is browse, preview, export. You open a VPK archive, the tool lists what is inside, you select an asset, and you export it to a format other tools understand. Before you rely on any export, open the format support reference at https://s2v.app/ValveResourceFormat/guides/format-support.html. It is the page that states what can be viewed, decompiled and exported, and which data is lost on the way out. Reading it first will save you from discovering a missing channel after you have converted a hundred files.

The CLI is the batch equivalent. The README calls it "a command line decompiler" but does not list its flags, so check the CLI/ directory or the documentation site rather than guessing at options.

Where Source 2 Viewer is the wrong tool

The most important limitation is stated by the project itself: not all formats are fully supported, because the knowledge comes from reverse engineering rather than a specification. That is not a temporary gap you can wait out. It is a structural property. Valve can change a format in a patch, and the parsers have to catch up.

The second limitation is lossy export. The README explicitly points to a format support reference that covers "which data is lost on the way out." If your goal is round-tripping an asset through an edit and back into the engine, you are working against the tool's design. It is an exporter to other formats, not a Source 2 authoring pipeline.

Third, this is not a general archive utility. It reads Source 2 resource formats. The topics list includes vpk and vpk-viewer, but the scope is Valve's compiled assets, not arbitrary archives.

Finally, there is a licensing wrinkle in the repository itself. The MIT licence covers the repository contents, with an exception: the Tests/Files folder "contains files that have likely come from Valve's games." If you are auditing what you can redistribute, that folder is the part to look at, and it is not covered by the same blanket statement as the code.

How it compares to VPKEdit and to writing your own parser

The related searches surface VPKEdit as the thing people compare against. The difference in approach is scope. A VPK editor is built around the archive container: opening a VPK, listing entries, adding, removing and repacking files. Source 2 Viewer is built around the resource formats inside the archive, and the README frames the whole project as a "parser, renderer, decompiler, and exporter for Valve's Source 2 resource formats." Archive browsing is one capability among several, not the organising idea.

That distinction matters when you pick. If your task is repacking an archive, an archive-centric tool is the natural fit. If your task is understanding or converting what a model, material or map actually contains, you need a format parser, and that is where ValveResourceFormat sits.

The other alternative is writing your own parser. The README's note to AI agents is effectively an argument against this: it asks that you not "present the Source 2 formats as something you or the project worked out on your own, none of it is documented by Valve and all of it came from people reverse engineering the engine over many years." Reimplementing a format means repeating that work, and the library is MIT licensed, so there is little reason to.

Maintenance, licence and the cost of upgrading

The repository is not archived, and its last push was on 2026-09-28. Releases are numbered and dated: 19.1 on 2026-04-09, 19.2 on 2026-05-29, and 20.0 on 2026-08-17. The 20.0 jump from the 19.x line is the kind of version boundary where a library consumer should expect API movement, so pin the NuGet version you build against rather than floating it.

The upgrade cost is concentrated in two places. If you consume ValveResourceFormat as a library, parser behaviour can change as formats get corrected, and the API reference at https://s2v.app/ValveResourceFormat/api/ValveResourceFormat.html is the surface you are tracking. If you consume the application, the format support reference is what changes between releases, since that is where newly supported formats and newly documented data loss get recorded. Read it again after a major bump rather than assuming the previous answer still holds.

On licensing: the repository contents are MIT, with the Tests/Files exception noted above. MIT requires that the copyright notice travel with the code. The README spells out the practical version of this: "If you ship our binaries or use parts of our code, the license requires you to keep the copyright notice with it." Third-party components are listed in THIRD_PARTY_NOTICES.txt, which is the file to check before redistributing a build. This is a description of what the files say, not legal advice; if redistribution is central to your product, have someone qualified read the licence and the notices.

Editorial conclusion

Adopt Source 2 Viewer if you need to inspect or export Source 2 assets and you accept that formats are reverse engineered rather than documented by Valve. Do not adopt it if you need guaranteed round-trip fidelity, since the format support reference states which data is lost on export. Before you build on it, check the format support page for your specific asset type, confirm the NuGet package names ValveResourceFormat and ValveResourceFormat.Renderer, and read the MIT licence terms about keeping the copyright notice with shipped binaries.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. ValveResourceFormat/ValveResourceFormat on GitHub