# SharpCompress: a pure C# archive library for streaming and random access > SharpCompress reads and writes a long list of archive formats from managed code, with non-seekable stream support as its main selling point. Here is what the README documents, what it leaves out, and where a different tool fits better. **adamhathcock/sharpcompress** — SharpCompress is a fully managed C# library to deal with many compression types and formats. - Repository: https://github.com/adamhathcock/sharpcompress - Stars: 2,587 · Forks: 520 - Language: C# - License: MIT - Published: 2026-09-28 · Updated: 2026-09-28 · Language: en - Canonical page: https://hysenlabs.com/projects/adamhathcock-sharpcompress ## What SharpCompress solves, and who it is written for The README states the problem plainly: SharpCompress is a compression library in pure C# that can unrar, un7zip, unzip, untar, unbzip2, ungzip, unlzip, unxz, unzstd, unarc, unarj, unace, and unlzw. That list is the product. If your application has to open whatever archive a user uploads, you either take a dependency that covers many formats or you wire up several libraries and dispatch between them yourself. SharpCompress is the first option. It targets .NET Framework 4.8, .NET Standard 2.0/2.1, .NET 6.0, .NET 8.0, and .NET 10.0. Because it is fully managed, there is no native binary to ship per platform and no P/Invoke boundary to reason about. That matters for the audience it suits: server-side .NET services, desktop tools, and build or deployment scripts that already run on the .NET runtime. The README does not describe a command line tool, so this is a library for developers, not an end-user utility. The README also notes that all I/O operations now support async/await, pointing at docs/USAGE.md for examples. For a web service that streams an archive out of object storage, that is the part worth reading first. ## Forward-only reading and non-seekable streams as the core mechanism The README calls non-seekable stream support the major feature, with the stated use case being large files processed on the fly, such as a download stream. This is an architectural constraint, not a marketing line. A seekable stream lets a reader jump to the central directory at the end of a zip file and enumerate entries before reading any of them. A forward-only stream does not. SharpCompress therefore exposes two API styles: forward-only reading, and file random access. Choosing between them decides how much of the archive you must buffer or how many entries you can inspect up front. The repository layout supports the split. There is a src/ directory, a docs/ directory containing FORMATS.md, API.md and USAGE.md, a tests/ directory, and a reference/ directory. The README links those three documents directly and says to post issues on GitHub rather than email the maintainer, who explicitly asks not to be contacted directly for help. Write support is narrower than read support, and the README is explicit about it: zip, tar, bzip2, gzip, lzip, zstandard compression streams, and 7zip archives. Everything else in the long un-prefixed list is read-only. That asymmetry is the single most important thing to check before you design around this library. ## Getting SharpCompress from NuGet and a first tar.gz The README does not contain an install section, and the repository does not ship a command line tool. The package is published on NuGet under the project name, and the README's own pointers for getting started are the three documents it links: docs/FORMATS.md for supported formats, docs/API.md for the API reference, and docs/USAGE.md for basic usage, async examples and the custom compression provider examples. Because the README prints no install command and no code sample of its own, the exact package reference and the exact reader signatures belong to those documents rather than to this page; anything else would be a guess. What the README does state about a first real use is the format advice. It recommends GZip (Deflate), BZip2 (BZip) and LZip (LZMA) for simplicity, long term archival and streamability, and says tar is often used in conjunction with them for multiple files in a single archive, giving .tar.gz as the example. So the shortest path to a working setup is to open docs/USAGE.md, follow the basic usage example there, and start with a .tar.gz input rather than a zip or 7zip one. Two API details are named in the README itself and are worth knowing before you write code. The first is the split between forward-only reading and file random access, which decides whether you can enumerate entries before reading them. The second is the Providers property and the WithProviders(...) extensions on ReaderOptions and WriterOptions, which accept a CompressionProviderRegistry. The README says the default registry is already wired up, so customization is only necessary when you want to plug in alternatives such as SystemGZipCompressionProvider or a third-party CompressionProvider, and that the selected registry is used by Reader/Writer APIs, Archive APIs and async extraction paths, so the same provider choice applies consistently across open, read and write flows. ## Where SharpCompress is the wrong tool The README is unusually candid about format quality, and its own recommendations cut against using the library for everything it can read. It recommends GZip (Deflate), BZip2 (BZip) and LZip (LZMA) for long term archival and streamability. It calls zip "okay" but a "very hap-hazard format" whose header and implementation variation makes correctness hard, and it says RAR is not recommended because it is proprietary with closed source compression, suggesting Tar/LZip for LZMA instead. It calls 7Zip and XZ overly complicated, notes that 7Zip does not support streamable formats, and links to an external argument about XZ. ZStandard is described as efficient and good for streaming with a flexible compression level. Read that as a boundary. If your pipeline is built on reading 7zip archives from a non-seekable stream, the README itself says that format does not support streaming, so the forward-only path is not the one to reach for. If you need to write RAR, you cannot: write support does not include it, and the maintainer advises against the format anyway. If you only ever produce zstd and want a minimal dependency, pulling in a library that also carries unarc, unarj and unace is more surface area than the job requires. The README does not document rollback behaviour, version compatibility guarantees between releases, or a support window. The release note titles for 0.50.1 through 0.50.3 are terse ("more fixes!", a GZipStream/Seekable stream fix, a RAR fix), which tells you fixes are landing but not what a version bump might change under you. ## SharpCompress compared with SharpZipLib and ZstdSharp The difference between SharpCompress and SharpZipLib is scope. SharpZipLib is a zip and gzip family library; SharpCompress covers the long format list above, including tar, lzip, xz, zstandard, 7zip and the legacy arc, arj, ace and lzw formats. If your world is zip and gzip only, SharpZipLib is the smaller commitment. If you accept arbitrary archives from users, the breadth is the reason to pick SharpCompress, and the README's own warning about zip header variation applies to both. ZstdSharp is a narrower comparison and a more interesting one, because SharpCompress does not implement zstandard itself. The README states the Zstandard implementation comes from https://github.com/oleg-st/ZstdSharp. So the choice is not SharpCompress versus ZstdSharp on codec quality; it is whether you want the codec alone or the codec inside an archive library. Taking SharpCompress for a zstd-only workload means carrying the archive layer you will not call. The README also records that the XZ implementation is based on https://github.com/sambott/XZ.NET and the 7Zip implementation on https://code.google.com/p/managed-lzma/, with XZ BCJ filter support contributed in 2022. Those attributions are worth knowing when you audit what you are shipping. ## Maintenance, upgrade cost and the MIT licence The last push to the repository was on 2026-09-24, and the most recent release listed is 0.50.3 from 2026-08-01. The repository is not archived. The maintainer's note in the README asks for feedback on usability, welcomes feature suggestions, and says code submissions are accepted, while stating plainly that there is no overall plan of what needs to be done, so "I'd like to help" messages alone are not actionable. Upgrade cost is the practical risk here. The 0.50.x releases landed within days of each other in July and August 2026 with short titles, and the README does not document a compatibility policy or a changelog beyond the release names. Pin the version in your project file and read the release notes before moving, rather than floating on the latest. The licence is MIT. The LICENSE.txt in the repository carries the Bouncy Castle copyright line from 2000 to 2011 alongside the MIT permission text. MIT permits use, copy, modification, merge, publish, distribution, sublicensing and sale provided the copyright notice and permission notice travel with the software, and it disclaims warranty. Because the README credits XZ.NET, managed-lzma and ZstdSharp as implementation sources, verify the licence terms of those upstream projects for your own distribution; this is not legal advice, and the README does not restate their terms. ## Conclusion Adopt SharpCompress if you are on .NET Framework 4.8 through .NET 10.0 and need to read archives from a non-seekable stream such as an HTTP response, or if you want one managed dependency covering zip, tar, gzip, bzip2, lzip, xz, zstandard, 7zip and the older formats the README lists. Do not adopt it if your only requirement is zstd and you want the smallest possible dependency, or if you need to write a format the README lists as read-only. Before committing, verify two things against your own inputs: that the write support list covers every format you intend to produce, and that your target framework appears in the supported list, since the README names .NET Framework 4.8, .NET Standard 2.0/2.1, .NET 6.0, .NET 8.0 and .NET 10.0 and nothing else. ## FAQ ### What is the best compression method for zip files? The README does not rank zip compression methods. It says zip uses Deflate by default but supports a lot of compression methods, calls zip a "very hap-hazard format" whose header and implementation variation makes correctness hard, and recommends GZip (Deflate), BZip2 (BZip) and LZip (LZMA) for long term archival and streamability. ### What is the purpose of file compression? The README does not discuss compression in general terms. It focuses on format support: reading rar, 7zip, zip, tar, bzip2, gzip, lzip, xz, zstandard, arc, arj, ace and lzw, and writing zip, tar, bzip2, gzip, lzip, zstandard compression streams and 7zip archives. ### Are zip and gzip the same? The README treats them as separate formats with separate entries in the read and write lists. It recommends GZip (Deflate) for long term archival and streamability, while describing zip as a format with wide header variation that is harder to get correct. ### What is the store compression method in WinRAR? The README does not describe WinRAR's store method. It does cover RAR reading, and states that RAR is not recommended because it is a proprietary format with closed source compression, suggesting Tar/LZip for LZMA instead. ### What is a SharpCompress alternative? SharpZipLib covers the zip and gzip family with a narrower scope. For zstandard alone, the README states the Zstandard implementation comes from ZstdSharp, so that project is the codec without the archive layer. The difference is breadth: SharpCompress covers many more formats, which is also more dependency surface. ## Sources - [adamhathcock/sharpcompress on GitHub](https://github.com/adamhathcock/sharpcompress) - [Issues](https://github.com/adamhathcock/sharpcompress/issues) - [License: MIT](https://github.com/adamhathcock/sharpcompress/blob/master/LICENSE) - [README](https://github.com/adamhathcock/sharpcompress/blob/master/README.md) - [Releases](https://github.com/adamhathcock/sharpcompress/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/adamhathcock-sharpcompress