HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
meta
zstd
C2016–2026
meta / zstd

zstd

Zstandard - Fast real-time compression algorithm

112Distinct people
165Mentions
2Explicit recommenders
28.3KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Zstandard - Fast real-time compression algorithm

GitHub

Where it is used

  • Chromium — Chromium ships this library to decode "Content-Encoding: zstd" responses. Source

What people are saying

First off, I love zstd and thanks for your work - I've used it multiple times with great success. My question is...what's up with zstd compression levels? It seems to be…

aidanhs used a recommendation phrase. 2 indexed comments match. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 12:03:30 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year165 dated mentions

Observed mentions: 2016-08-31 17:28:01 UTC to 2026-09-07 15:41:05 UTC.

01020302016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 8 mentions; 2 submissions, 6 comments20162017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 20 mentions; 4 submissions, 16 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 27 mentions; 5 submissions, 22 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 7 mentions; 3 submissions, 4 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 14 mentions; 3 submissions, 11 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 12 mentions; 3 submissions, 9 comments20212022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 27 mentions; 2 submissions, 25 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 7 mentions; 2 submissions, 5 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 19 mentions; 1 submissions, 18 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 17 mentions; 3 submissions, 14 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 7 mentions; 0 submissions, 7 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC826
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC20416
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC27522
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC734
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC14311
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC1239
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC27225
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC725
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC19118
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC17314
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC707

What Hacker News says

17 sources
This is because Zstd's long-distance matcher looks for matching sequences of 64 bytes [0]. Because long matching sequences of the data will likely have the newlines inserted in different offsets in the run, this totally breaks Zstd's ability to find the long-distance match. Ultimately, Zstd is a byte-oriented compressor that doesn't understand the semantics of the data it compresses. Improvements are certainly possible if you can recognize and separate that framing to recover a contiguous view of the underlying data. [0] https://github.com/facebook/zstd/blob/v1.5.7/lib/compress/zs... (I am one of the maintainers of Zstd.)
In Removing newlines in FASTA file increases ZSTD compression ratio by 10x
I'm almost positive that he didn't use thinking mode, because I've asked GPT-5 thinking his question verbatim in 10 parallel threads and it said "you can't" and thoroughly explained why every time. Below is the first response I got back. --- Short answer: you can’t. iOS doesn’t ship a Zstandard encoder/decoder. Apple’s built-in `Compression` framework only exposes LZFSE, LZ4(/RAW), zlib/DEFLATE, and LZMA—no ZSTD knob to turn. ([Microsoft Learn][1], [Apple Developer][2]) If you’re okay with a built-in alternative that’s “zstd-ish” in speed/ratio, use LZFSE via `Compression`’s streaming API. Here’s a minimal streaming compressor you can drop in; it takes chunks of `Data` and yields compressed chunks (no third-party code): ```swift import Compression final class StreamCompressor { private var stream = compression_stream() private let
Read the rest
algo: compression_algorithm private var isInitialized = false init(algorithm: compression_algorithm = COMPRESSION_LZFSE) { self.algo = algorithm } func append(_ input: Data, isFinal: Bool, outChunkSize: Int = 64 * 1024) -> [Data] { if !isInitialized { let status = compression_stream_init(&stream, COMPRESSION_STREAM_ENCODE, algo) precondition(status != COMPRESSION_STATUS_ERROR, "compression_stream_init failed") isInitialized = true } var outputs: [Data] = [] input.withUnsafeBytes { (srcBuf: UnsafeRawBufferPointer) in var flags: Int32 = isFinal ? Int32(COMPRESSION_STREAM_FINALIZE.rawValue) : 0 stream.src_ptr = srcBuf.bindMemory(to: UInt8.self).baseAddress stream.src_size = srcBuf.count var out = Data(count: outChunkSize) out.withUnsafeMutableBytes { dstBuf in while true { stream.dst_ptr = dstBuf.bindMemory(to: UInt8.self).baseAddress stream.dst_size = dstBuf.count let status = compression_stream_process(&stream, flags) let produced = dstBuf.count - stream.dst_size if produced > 0 { outputs.append(Data(bytes: dstBuf.baseAddress!, count: produced)) } if status == COMPRESSION_STATUS_OK && stream.src_size == 0 && stream.dst_size > 0 { break // need more input to continue } else if status == COMPRESSION_STATUS_OK && stream.dst_size == 0 { // output buffer filled; loop to drain more continue } else if status == COMPRESSION_STATUS_END { break } else if status == COMPRESSION_STATUS_ERROR { preconditionFailure("compression_stream_process failed") } else { // Shouldn’t happen break } } } } return outputs } deinit { if isInitialized { compression_stream_destroy(&stream) } } } ``` Usage: ```swift let compressor = StreamCompressor(algorithm: COMPRESSION_LZFSE) var compressed: [Data] = [] for (i, chunk) in chunks.enumerated() { let final = i == chunks.count - 1 compressed.append(contentsOf: compressor.append(chunk, isFinal: final)) } // `compressed` now contains the zstd-adjacent (LZFSE) stream ``` If you truly need the ZSTD format (interop requirement), you’ll have to ship the reference C library (`libzstd`) in your app (static link it and call through a tiny Swift wrapper). That’s still “third-party,” even if you vendor the sources instead of using SPM/CocoaPods. There is no system-provided ZSTD on iOS today. ([GitHub][3]) tl;dr: iOS doesn’t expose ZSTD. Use `Compression` with LZFSE for built-in streaming, or vendor `libzstd` and bridge to it if you must emit/ingest ZSTD. ([Microsoft Learn][1], [Apple Developer][2], [GitHub][3]) [1]: https://learn.microsoft.com/en-us/dotnet/api/compression.com... "CompressionAlgorithm Enum (Compression)" [2]: https://developer.apple.com/documentation/compression/compre... "COMPRESSION_LZFSE | Apple Developer Documentation" [3]: https://github.com/facebook/zstd?utm_source=chatgpt.com "facebook/zstd: Zstandard - Fast real-time compression ..."
In Yet Another LLM Rant
ZSTD is a great compression algorithm but an important PNG (v1.2) advantage is that implementations are available in almost all actively used operating systems and in most popular languages. The same cannot be said about ZSTD with very few implementations except https://github.com/facebook/zstd I'm not even sure there is a good pure Java (no JNI) and Go (without Cgo) implementations for ZSTD. And it definitely would require more powerful hardware - some micro-controllers which can use PNG are too small for ZSTD.
In Consider using Zstandard and/or LZ4 instead of Deflate
The Zstd spec allows a stream to consist of multiple frames, but that alone isn't enough for efficient seeking. You would still need to read every frame header to determine which compressed frame corresponds to a particular byte offset in the uncompressed stream. "Seekable Zstd" is basically just a multi-frame Zstd stream, with the addition of a "seek table" at the end of the file which contains the compressed and uncompressed sizes of every other frame. The seek table itself is marked as a skippable frame, so that seekable Zstd is backward-compatible with normal Zstd decompressors (the seek table is just treated as metadata and ignored). https://github.com/facebook/zstd/blob/dev/contrib/seekable_f...
In Show HN: Zeekstd – Rust Implementation of the ZSTD Seekable Format
Looking at the spec (https://github.com/facebook/zstd/blob/dev/contrib/seekable_f...), I don't see any mention of custom dictionaries like you describe. The spec does mention: > While only Checksum_Flag currently exists, there are 7 other bits in this field that can be used for future changes to the format, for example the addition of inline dictionaries. so I don't think seekable zstd supports these dictionaries just yet. With multiple inline dictionaries, one could detect when new chunks compress badly with the previous dictionary and train new ones on the fly. Could be useful for compressing formats with headers and mixed data (i.e. game files, which can contain a mix of text + audio + video, or just regular old .tar files I suppose).
In Show HN: Zeekstd – Rust Implementation of the ZSTD Seekable Format
rorosen·Jun 15, 2025Submission

Show HN: Zeekstd – Rust Implementation of the ZSTD Seekable Format

Hello, I would like to share a Rust implementation of the Zstandard seekable format I've been working on. Regular zstd compressed files consist of a single frame, meaning you have to start decompression at the beginning. The seekable format splits compressed data into a series of independent frames, each compressed individually, so that decompression of a section in the middle of an archive only requires zstd to decompress at most a frame's worth of extra data, instead of the entire archive. I started working with the seekable format because I wanted to resume downloads of big zstd compressed files that are decompressed and written to disk on the fly. At first I created and used bindings to the C functions that are available upstream[1], however, I stumbled over the first segfault rather quickly (it's now fixed) and found out that the fun
Read the rest
ctions only allow basic things. After looking closer at the upstream implementation, I noticed that is uses functions of the core API that are now deprecated and it doesn't allow access to low-level (de)compression contexts. To me it looks like a PoC/demo implementation that isn't maintained the same way as the zstd core API, probably that's also the reason it's in the contrib directory. My use-case seemed to require a complete rewrite of the seekable format, so I decided to implement it from scratch in Rust using bindings to the advanced zstd compression API, available from zstd 1.4.0. The result is a single dependency library crate[2], and a CLI crate[3] for the seekable format that feels similar to the regular zstd tool. Any feedback is highly appreciated! [1]: https://github.com/facebook/zstd/tree/dev/contrib/seekable_f... [2]: https://crates.io/crates/zeekstd [3]: https://github.com/rorosen/zeekstd/tree/main/cli
214 points · Open discussion

Showing the 15 most recent of 17 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.