Online .ZST File Extractor
(No Size Limits)

A .zst file holds one file compressed with Zstandard, and nothing else. There are no folders and no second entry, so dump.sql.zst decompresses to exactly one dump.sql. If you expected a folder full of files, what you have is probably a .tar.zst, where TAR does the bundling before Zstandard compresses the result.

Where .zst files come from

Zstandard turns up wherever something large is written often and read fast: database dumps, log archives, container layers, game assets, and increasingly filesystem-level compression in btrfs and ZFS. It is the format you meet when a developer or a server produced the file, rather than a person zipping a folder.

Yann Collet released it at Facebook in 2016 and it became RFC 8878 in 2021, which is recent enough that desktop tooling has not caught up. Windows 11 gained support in the 23H2 update. Windows 10, macOS and ChromeOS have none, so a .zst normally means installing the zstd command line tool first.

The 10 MB ceiling that breaks large .zst files elsewhere

This is worth documenting, because it silently affects other browser-based extractors. A widely used WebAssembly Zstandard decoder contains this check:

if (e > 10000000) throw new err('win 2 large');

The wording suggests a window-size limit, but the value being tested is Frame_Content_Size, the declared size of the decompressed output. The effect is a hard 10 MB cap on Zstandard output regardless of how the file was compressed. A 33 MB SQL dump fails on it, which is a very ordinary thing for a .zst file to be.

unpk.app decodes .zst with libzstd, the reference implementation, driven through libarchive. There are two caps to get past here, and neither is in the file: that 10 MB output check, and the 128 MB window limit almost every build of libzstd ships with by default, which is why zstd -d itself tells you to pass --memory=2048MB on some archives. Ours is set to the largest window the format defines, so a .zst compressed with --long or --ultra decodes here without being asked to justify itself. If a .zst has failed for you elsewhere with a vague error, one of those two caps is the likely cause.

How large a .zst can be

There is no ceiling here. The file is decompressed as a stream and written out as it decodes, so memory use stays flat no matter how large the result is. A multi-gigabyte database dump decompresses the same way a small one does.

Doing it from a terminal instead

With the zstd tool installed, keeping the compressed original:

zstd -d -k dump.sql.zst

On macOS that needs brew install zstd first. That install step is the reason this page exists: on a managed laptop or a school Chromebook you often cannot run it.

What does not work

Multi-volume archives split across several files, such as .zst.001, are not supported. Zstandard has no encryption layer of its own, so a password-protected .zst is really an encrypted container holding one, and that outer layer has to come off first.