UUEncoder / Decoder

Encode and decode text using Unix-to-Unix (UU) encoding.

Filename in header

Text to encode

About UUencoding

UUencoding (Unix-to-Unix encoding) was the original mechanism for transferring binary files over early Unix mail and newsgroup systems. It maps every 3 bytes of input to 4 printable ASCII characters (characters 32–95) and wraps lines at 60 characters. The format begins with a begin 644 filename header (644 is the Unix file-permission octet) and ends with end.

For modern binary-to-text encoding, prefer Base64 or Base85.

Built and maintained by Meet Shah · Last updated 25 July 2026

What this tool is used for

Reading an attachment out of an archived Usenet post or a very old mail spool.
Recovering a file from a system whose only export path predates MIME entirely.
Understanding a legacy format when maintaining code that still has to parse it.
Checking whether a truncated posting can still be partially decoded.
Comparing the encoding overhead against Base64 for a historical write-up.

Frequently Asked Questions

What is uuencoding for?: Unix-to-Unix encoding, from 1980: it packs binary into printable ASCII so files could travel over UUCP and Usenet, which were 7-bit text-only. It is the direct ancestor of the problem MIME and Base64 later solved properly.
How does the format work?: Three bytes become four characters by adding 32 to each 6-bit group, mapping into the printable range starting at space. Each line is prefixed by a length character, and the stream is wrapped in begin/end lines carrying the filename and Unix permissions.
Why was it replaced by Base64?: Because its alphabet starts at the space character, and mail systems that trimmed trailing whitespace silently corrupted the data. Base64's alphabet avoids space entirely, which is the main reason MIME adopted it.
What is xxencode?: A variant using an alphanumeric alphabet specifically to survive EBCDIC gateways, which mangled uuencode's punctuation. It solved the same problem differently and lost to Base64 for the same reasons.
Will I ever encounter it today?: Rarely — in Usenet binary archives, some legacy mainframe interchange, and old email archives. It survives mostly as something you need to DECODE rather than produce.
How is the length byte on each line computed?: It is the number of decoded bytes on that line, offset by 32 to make it printable — so a full 45-byte line begins with `M`. A decoder that ignores it and simply decodes to the end of the line mis-handles the final short line.
Why do some uuencoded files use backtick instead of space?: Because a zero-length line encodes as a space, and mail systems strip trailing whitespace — silently destroying it. Substituting a backtick for the space is the long-standing workaround, and decoders accept both.
What are the begin and end lines for?: `begin` carries the file's permission mode and name, `end` closes the stream. That header is why uuencode preserves a filename and Base64 does not — MIME moved that job to headers instead.

Common errors and gotchas

Losing the `begin` and `end` lines, which carry the filename and permission bits and mark where the data actually starts.
Assuming trailing spaces are insignificant. They are data, and any mail system that trims them corrupts the file silently.
Overlooking the backtick variant, where a backtick replaces a space for exactly the reason above.
Ignoring the length byte starting each line, which is how a decoder knows a short final line is not truncated.
Expecting it to interchange with xxencode. The alphabets differ, and one will not decode the other.