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.

yEnc Encoder/Decoder

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.

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.