How NZB Files Are Built: The Encoding, Splitting, and Posting Pipeline

An NZB file is the end product of a multi-step pipeline. A file gets encoded, split into pieces, posted as individual articles to Usenet, and then an NZB is generated that maps every article back to the original file. Understanding this pipeline explains why NZBs look the way they do, why some downloads fail, and why details like segment size and Message-ID format matter.

Our NZB overview page covers what NZBs are and how to use them. This page goes deeper into how they are actually constructed.

Usenet was designed for text. The NNTP protocol transmits articles as sequences of printable characters. Binary data (executables, images, video, archives) contains bytes that are not valid in a text stream, so binary files must be encoded into text-safe characters before they can be posted.

The current standard is yEnc (yEncode), which maps each input byte to a single output byte using a simple offset, escaping only the few characters that conflict with NNTP framing (null, newline, carriage return, period, equals sign, and tab). This gives yEnc an overhead of roughly 1-2%, meaning a 1GB file becomes about 1.01-1.02GB after encoding.

The older encoding formats, UUEncode and Base64, had overhead of 33-40% because they mapped every 3 bytes of input to 4 bytes of output using a restricted character set. yEnc replaced them in the early 2000s because the efficiency difference is enormous at Usenet scale. A 10GB upload that would have been 13.3GB in UUEncode is only 10.15GB in yEnc.

Your posting tool handles encoding automatically. When you feed a file to Nyuu, NewsUP, or PowerPost, it yEnc-encodes the data as part of the posting process.

NNTP has practical limits on article size. Most servers accept articles up to about 1MB, but the convention for binary posts is to split encoded data into segments of 700-768KB each. Every segment becomes a separate Usenet article with its own headers and Message-ID.

A 1GB file encoded with yEnc produces roughly 1.01GB of encoded data. At 750KB per segment, that is approximately 1,380 individual articles. A 50GB upload becomes around 69,000 articles. This is why Usenet servers store billions of articles and why spool software has to handle massive I/O loads.

Each segment article has a subject line that follows a naming convention so download clients can reassemble them in order. The standard format looks like:

My_File.mkv yEnc (1/1380) [01/47]

This tells the download client: this is part 1 of 1,380 segments, in file 1 of 47 files in this post. The subject line is how early Usenet users manually found and reassembled multi-part binaries before NZB files existed. They would search a newsgroup for the subject, collect all the parts, and decode them by hand.

Every Usenet article has a unique Message-ID. This is the globally unique identifier that lets any server on the network locate a specific article. Message-IDs look like email addresses but they are not. A typical format:

<[email protected]>

The left side is a unique string (usually random or hash-based), and the right side identifies the posting server. When your download client processes an NZB, it sends these Message-IDs to NewsDemon using the NNTP ARTICLE or BODY command, and the server returns the corresponding data.

Message-IDs are generated by your posting tool at upload time. Good posting tools generate Message-IDs that are genuinely random and do not leak identifying information. Some older tools used patterns that could link multiple posts to the same poster. Our posting guide covers the privacy implications.

Message-IDs are also how peering works. When Server A offers an article to Server B using IHAVE, it sends the Message-ID. Server B checks whether it already has that ID. If not, it accepts the article. This deduplication prevents the same article from being stored multiple times on a single server.

The posting tool opens multiple connections to your provider (NewsDemon supports up to 50) and uploads the segment articles in parallel. Each article consists of headers (From, Subject, Newsgroups, Message-ID, Date) and the yEnc-encoded body data for that segment.

The server accepts each article with an NNTP POST or IHAVE command, assigns it to the specified newsgroup(s), writes it to the spool, and begins propagating it to peer servers. Within minutes, the article is available on Usenet servers worldwide.

For a large upload, this process can take a while. Posting 69,000 articles (a 50GB file) at 50 connections over a 100 Mbps upload connection takes roughly 70 minutes. Faster connections and more connections reduce this proportionally.

After all articles are posted, the posting tool generates an NZB file. This file is a structured XML document that contains:

For each file in the post: the subject line, the posting date, the poster identity (From header), and the newsgroup(s).

For each segment of each file: the Message-ID, the segment number, and the byte count.

The NZB file is small because it only contains metadata, not article data. An NZB for a 50GB post is typically under 1MB. It is a complete map that lets any download client reconstruct the original files by requesting each Message-ID from their provider.

Here is what a real NZB segment entry looks like in the XML:

<file poster="[email protected]" date="1710700000" subject="My_File.mkv yEnc (1/1380)">
  <groups><group>alt.binaries.multimedia</group></groups>
  <segments>
    <segment bytes="768000" number="1">[email protected]</segment>
    <segment bytes="768000" number="2">[email protected]</segment>
    <!-- ... 1,378 more segments ... -->
  </segments>
</file>

Not all NZBs come from the original poster. NZB indexing services generate NZBs by scanning Usenet newsgroups after the fact. Here is how that works:

Header scanning. The indexer connects to a Usenet provider and downloads the headers (not bodies) from binary newsgroups. Headers are small, just the subject line, Message-ID, date, and other metadata for each article. Scanning headers for a busy newsgroup can produce millions of entries per day.

Grouping. The indexer parses the subject lines to group related segments together. Articles with subjects like My_File.mkv yEnc (1/1380) through (1380/1380) all belong to the same file. The indexer groups them by matching the filename portion of the subject.

NZB creation. Once all segments of a file are identified, the indexer generates an NZB containing their Message-IDs. This NZB is identical in function to one the poster could have generated at upload time.

Cataloging. The indexer adds the NZB to its database with metadata: filename, size, category, posting date. Users search the indexer and download the NZB. The NZB then gets handed to SABnzbd or NZBGet for the actual download.

This is why header access matters and why NewsDemon includes free headers on every plan. The entire NZB ecosystem depends on being able to read article headers efficiently.

With this pipeline in mind, here is why downloads sometimes do not work:

Missing segments. If some of the 1,380 articles in a post were lost during propagation, or removed by a takedown, or dropped during a storage migration, the download client cannot get those segments. PAR2 repair can fill small gaps. For larger gaps, a backup provider on a different backbone may have the missing articles.

Expired content. If the articles are older than your provider retention window, they have been deleted from the spool. The NZB still contains valid Message-IDs, but the server no longer has the data.

Corrupt NZB. If the NZB itself is damaged (truncated, malformed XML), the download client cannot parse it. Re-download the NZB from the indexer.

Wrong Message-IDs. Rarely, an NZB points to Message-IDs that never existed. This can happen with auto-generated NZBs from unreliable indexers. The download client reports every segment as missing.