Why is yEnc more efficient than uuencode?

UUEncode always expands data by about 35% because it re-encodes every byte. yEnc instead adds 42 to each byte and leaves it as a single character, escaping only the handful of bytes that would break a Usenet article. Most bytes stay one byte, so overhead is typically only 1 to 2%.

What does the byte shift do?

Each source byte is mapped to (byte + 42) mod 256. This moves common values away from the control characters that newsreaders interpret. Decoding simply subtracts 42 (mod 256) from each character to recover the original byte.

Which characters are escaped?

After the shift, null, line feed, carriage return and the equals sign are escaped because they would terminate or corrupt a line. An escaped byte is written as an equals sign followed by the byte plus 64 (mod 256). A leading dot is also escaped to survive SMTP dot-stuffing.

What is the crc32 in the =yend line?

It is a CRC32 checksum of the original unencoded bytes. After decoding, a reader recomputes the CRC32 and compares it to the trailer value. A mismatch means the article was truncated or corrupted in transit. This tool performs that check for you.

No. The byte shift, escaping and CRC32 all run locally in your browser. Nothing leaves your device.

What is the yEnc Encoder/Decoder?

Free yEnc encoder and decoder implementing the offset-42 byte shift, critical-character escaping and CRC32 integrity check used for Usenet binaries. Encode text to a =ybegin/=yend block or decode one and verify its CRC, client-side. It runs free in your browser on Gera Tools, with nothing uploaded.

yEnc Encoder/Decoder

Name: yEnc Encoder/Decoder
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

yEnc is the encoding that made binary Usenet practical: it ships large attachments with almost no size penalty and a built-in integrity check. This tool encodes text into a single-part yEnc block and decodes yEnc articles back to their bytes, verifying the CRC, all in your browser.

How it works

yEnc maps each source byte with a simple offset: E = (byte + 42) mod 256, then writes E as a single character. Because the shift moves typical data away from control codes, almost every byte survives as-is. Only the critical bytes would break a newsgroup article: after the shift, null, line feed, carriage return and = are escaped by writing = followed by (E + 64) mod 256. A dot at the start of a line is also escaped to defeat SMTP dot-stuffing. The body is wrapped in a =ybegin line=... size=... name=... header and a =yend size=... crc32=... footer.

The trailer’s CRC32 is computed over the original bytes using the standard reflected polynomial 0xEDB88320. On decode, this tool reverses the offset and escaping, then recomputes the CRC32 and reports whether it matches, so you immediately know if the data arrived intact.

Why yEnc instead of UUEncode or Base64?

The fundamental problem yEnc solved is overhead. UUEncode and Base64 both work by taking groups of input bytes and representing them using a subset of safe ASCII characters. That subset covers only 64 or so characters out of 256, so 3 input bytes expand to 4 output characters — a 33% size inflation. On Usenet, where newsgroup servers store and propagate every byte, a 33% overhead on binary content (images, archives, software) added up to enormous bandwidth and storage costs.

yEnc instead bets that most bytes in a random binary file, after adding 42, will not happen to land on any of the four critical control bytes. In practice, roughly 98 of every 100 bytes stay as a single character. The result is 1–2% overhead rather than 33%, which roughly halved the size of binary attachments on Usenet when yEnc was introduced in 2002.

The CRC integrity check in practice

The CRC-32 in the =yend trailer is the heart of yEnc’s reliability story. Usenet articles are transmitted across many servers, and truncation, bit flips, and dropped lines are real failure modes. Without a checksum, a newsreader would happily reassemble a corrupted binary and hand you a silently broken file.

With yEnc’s CRC, a mismatch tells you immediately that the article is incomplete. The common response was to re-request only the missing part — Usenet clients handled this automatically. This tool replicates that check: after decoding, the CRC32 of the recovered bytes is compared to the value in =yend crc32=. If they match, the data is intact. If they don’t, something was lost in transit.

Article structure

A complete single-part yEnc article looks like this:

=ybegin line=128 size=12345 name=example.zip
[encoded bytes]
=yend size=12345 crc32=d5828fae

The line= field records how many encoded characters appear per line (historically 128 or 256). The size= is the original unencoded byte count. The name= is the original filename.

Tips and notes

Real multi-part yEnc posts add =ypart begin=... end=... lines and a pcrc32 per part; this tool handles single-part bodies and ignores =ypart lines if present. When decoding, paste from =ybegin through =yend so the CRC can be read. A CRC mismatch almost always means the article was truncated, so re-fetch the missing part before trusting the output.