Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I remember reading somewhere that any binary files sent attached to an email must be first UUENCODEd, which makes the file sizes considerably larger, hence why it's better to send files via some other direct-transfer means such FTP, Skype, etc.

How much larger will UUENCODE make my binary files?

share|improve this question
up vote 4 down vote accepted

Short answer:

The size of the uuencoded file will be about 35% bigger than the original file.

Long answer:

Uuencode files look like this:

begin 600 filename
  • That is 7 bytes for begin, three for the permissions, two for the separating spaces.
  • X bytes for the filename (depending on the name)
  • Then the actual encoded data. Every 6 bits get mapped to a 8 bits (with the result all printable ASCII chars). This increases the size to 8/6, or 1⅓ times the original size.
  • The result is then broken into lines of 65 chars so the result would on an 80 char. wide screen. This adds an extra newline per 65 chars. Thus increasing file size by 1/65th
  • Finally 3 bytes for end

Thus we get: 13 bytes, plus filename length, plus 1 68/195th of the original file size.

(The 68/195th is 1⅓ plus 1/65, or 1 65/195 plus 3/195. This is very close to 35%, which is why the rule of thumb is that 'size increases by a good third).

share|improve this answer
You forgot to account for the SOL/length character (an M for a "full" line) that starts each line of encoded data. Line termination can be either CR+LF or just LF. – sawdust Mar 20 '13 at 2:18
Good point. Each extra char per line would add 1.5% to the final size. – Hennes Mar 20 '13 at 12:56

Common modern email clients will use base64, which will make the file about 35% larger, but only within the email.

These days, base64 is normally used instead. Each byte of the original binary contains 8 bits. Base64 can store the equivalent of 6 bits of original data within each encoded byte. So encoded size is 8/6ths that of the original:

8 / 6 = 1.33... = 133% = 33% more

And then line breaks are added which adds another couple of percent.

Of course, once the file is decoded to be saved to the recipient's file system, the decoded file will be identical to the original.

share|improve this answer

Though the actual answer (as given by @Per Salmi and @depquid) is just a bit more than 33% (3 bytes become 4, plus line endings, plus some housekeeping) you'll not have to worry about uuencode.

uuencode dates from the really old days of UNIX, before MIME mailers were around. back in those days, to schlepp bytes around in text only environments (e.g, Mail, netnews/usenet) you'd have to manually encode the file to be 7-bit character safe. Then the receiver would have to manually save the file someplace, possibly concatenate and order multipe mails/postings, run uudecode (which was smart enough to ignore anything outside of BEGIN/END blocks) and get the binary file. But we don't need to do that anymore, at least not for mail.

If you use any modern mailer, this cross encoding already happens automagicaly. Binary MIME elements are usually base64 encoded (like @depquid states).

So, you already do MIME Base64 encoding, which blows up the file a bit more than 33% if you're curious about the hit to your bandwidth allocation. To do uuencode/uudecode would just add even more work on both yours and the receiver's side.

share|improve this answer

I don't think you can tell exactly how large the uuencoded content will be as it depends on the actual content but it is stated to be at least 40% larger than the original in the disadvantages section on Wikipedia.

share|improve this answer
The disadvantages section you mention states that this is a fixed-size 3-byte/4-byte encoding. – Isaac Rabinovitch Mar 19 '13 at 19:50
Yes, you are correct, do you know if the zero-padding, headers, filename info and delimiters adds up to something significant like the push from 33% increase up to "at least 40%" stated in the article. Maybe it would be correct to say it is at least 33% instead. – Per Salmi Mar 19 '13 at 20:19
The article should claim it increases by at least 34.87% (and that for very large files where the size of the header is negligible). The beauty of Wikipedia is that you can create an account and improve the article. (Having said that, yes, so could I). ;-) – Hennes Mar 19 '13 at 23:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .