Although base64 [--decode] works well when encoding and decoding files locally, I can't decode a base64-encoded inline attachment in an eml file saved from Thunderbird or Gmail.

I observed that base64-encoded blocks in all eml files are similar to what base64 generates, but lines are of different length: the lines in base64-encoded blocks of text in eml files consist of 72 characters, while the locally generated base64-encoded files consist of 76-character-long lines. I suspect this discrepancy is why I cannot successfully use base64 --decode on snippets of eml files.

Is my hypothesis true? How can I decode these attachments?

  • They should be 76 characters long, according to RFC 4648. Anyway, it really doesn't matter: you should remove the line breaks before decoding them, anyways. Commented Nov 15, 2023 at 19:25
  • @MarcusMüller Strangely, the lines are 72 characters long in eml files, and I can get the inline attachment by removing all line breaks first, and then using the command fold -w 76 to fix this. I'm now trying to write a shell script for this, if I can get the correct command to remove all line breaks - neither tr -d '\n' or sed ':a;N;$!ba;s/\n//g' worked. :-(
    – Sadi
    Commented Nov 16, 2023 at 12:33
  • @KamilMaciorowski I understand that the option --wrap=COLS is used while encoding (default=76), and apparently Thunderbird and Gmail eml files use column width 72 instead of 76. However, this option apparently is not meant to be used when decoding (it has no effect).
    – Sadi
    Commented Nov 16, 2023 at 12:41
  • @KamilMaciorowski Sorry for the confusion. My problem is I can't decode eml files generated by Thunderbird or Gmail which come with 72 characters long lines. I was able to decode them only if I manually got rid of newlines, and created 76 characters long lines.
    – Sadi
    Commented Nov 16, 2023 at 12:55
  • @KamilMaciorowski Yes! Finally got it! All I need was the command dos2unix before decoding apparently. It's unbelievable that both Thunderbird and my web browser saved those eml files with CRLF. Thank you very much.
    – Sadi
    Commented Nov 16, 2023 at 13:05

1 Answer 1


The command base64 performs encoding by wrapping text at default column width of 76 characters, unless another value is specified with the option --wrap=COLS.

The command base64 --decode is expected to work regardless of column width, e.g. the text block might consist of a single line (it doesn't matter how long), or multiple lines wrapped at any fixed column width.

The problem with "Internet Message Format" (*.eml) files saved from Thunderbird or a web mail like GMail actually is that they use DOS/Windows ("CRLF" / "\r\n") - and not Unix/Linux ("LF" / "\n") - line endings, while both base64 and base64 --decode use the latter.

This means, "Internet Message Format" (*.eml) files (or base64-encoded text blocks retrieved from them) should first be converted using the dos2unix command before executing the base64 --decode command.

You must log in to answer this question.

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