Check email attachment size and limit

Why the attachment and the message differ in size

When you send an email, it is mainly the message containing your PDF that grows larger. Email was originally built for text. That's why your email program packages file attachments in MIME format and usually translates the binary data into plain text characters using Base64. In the process, every 3 bytes of the file become 4 characters, and these characters are spread across lines with line endings. The Base64 encoding itself is reversible: decoding produces exactly the original bytes again. The finished message also includes headers, the message body and the boundaries between the individual parts.

As a result, a message can be considerably larger than the attachment you selected. In a German-language forum, someone asked why a 20.1 MB PDF had turned into a sent email of 27.5 MB. If you recalculate 20,100,000 bytes with this calculator, with line breaks and without extra bytes, you get 26,800,000 bytes of Base64 data and 705,264 bytes of line endings. Together that's 27,505,264 bytes, or about 27.51 MB. The calculation shows how this order of magnitude comes about. It is a model calculation and not an analysis of that specific email.

How the estimate is made up

Each file goes on its own row, because each attachment is encoded separately. You can enter sizes in B, KB, MB, GB, MiB or GiB, among others. The calculator treats MB as decimal with 1,000,000 bytes and MiB as binary with 1,048,576 bytes. After conversion, the result must be a whole number of bytes. When typing, be aware of one quirk: a period is read as a decimal point, so 1.000 means 1. For thousands, write 1,000 or 1,000.00. Spaces are not accepted as thousands separators, so 1 000 is rejected.

1. Original size: the total of your attachments in bytes. It is the starting value and is used for comparison with an attachment limit.
2. Base64 data: An attachment of n bytes becomes 4 × roundup(n ÷ 3) characters. If the remainder at the end is not enough for a full group of three, padding fills up the last group of four.
3. Line endings: With line breaks switched on, which is the default setting, the calculator splits the characters of each attachment into lines of at most 76 characters. For each line, it counts 2 bytes for the CRLF line ending, including the last line.
4. Extra bytes: your own value for the body text, headers and other parts of the message. The default is 0.
5. Estimate: the Base64 data and line endings of all attachments plus the extra bytes.

Is Base64 always exactly one third larger?

Only approximately. For large files, the ratio of 3 bytes to 4 characters approaches an increase of 33⅓ %. Without line breaks, 10,000,000 bytes become exactly 13,333,336 bytes, about 33.33 % more. The tiny deviation from an exact third comes from the padding. With line endings, it's 13,684,214 bytes, about 36.8 % more. Rules of thumb of around 37 % therefore describe encoded data with line breaks. They depend on the line length and line ending and take neither headers nor body text into account.

For small files, a fixed factor doesn't work at all. An attachment of 1 byte becomes 4 Base64 characters plus 2 bytes of line ending, so 6 bytes in total. That's why the calculator calculates each attachment exactly instead of multiplying everything by a flat value.

Multiple attachments: each file separately

Attachments are not merged into one large block but encoded individually. Each file therefore brings its own padding and its own final line ending. An edge case with two files of 1 byte each shows this most clearly.

With a single large PDF, these few bytes hardly matter. With many small files, however, they add up.

The line length of 76 characters is the maximum length the MIME standard specifies for Base64 lines. Counting a CRLF after the last line as well is a convention of this calculator. Email programs that use shorter lines or end the data differently will arrive at slightly different values. One more common misconception: Base64 does not encrypt anything. It is purely an encoding that can be reversed without a key, and it does not protect the content of your attachment.

Comparing against the right size limit

A size limit gives you a number, but it doesn't always tell you what that number refers to. Some rules limit the total of the original attachments, i.e. the file sizes your email program shows. Others limit the complete message including encoded attachments, body text and headers. That's why in the calculator you choose what the limit is compared with. The prefilled value of 25 MB is only a starting value and not the requirement of any particular provider. A result that lands exactly on the limit counts as within the limit.

The same file can therefore meet one rule and fail the other without any contradiction.

Two real rules with different references

• Gmail: According to the German-language Gmail help page on attachments (accessed on 13 October 2026), attachments on personal accounts may total up to 25 MB. This refers to the total of the attachments, so the comparison with the original attachments is the right one. For Google Workspace accounts, the administrator sets the limits. If the total is larger, the attachment is replaced by a Google Drive link.
• RRZE at the University of Erlangen-Nürnberg: The guide on size restrictions for email attachments (accessed on 13 October 2026) states a maximum of 20 MB for the entire email for incoming and outgoing mail on the RRZE servers. In this case, you compare with the estimated message, and it makes sense to enter extra bytes as well.

Both rules apply only within their own scope and may change. For your email, what counts is the rule for your account, whether it is personal or managed by an employer, school or university. The rule for the recipient's mailbox counts just as much. If you know the recipient's requirement, include it in the comparison with its exact reference. If a provider automatically sends large files as a link, the file is no longer an attachment in the message. Whether the recipient can and is allowed to open that link is then a separate question.

What is still missing for a complete message

An encoded attachment on its own is not yet an email. The finished message includes headers with the sender, recipients, subject and technical information. Added to that are the message body, often as both plain text and HTML, the boundary lines between the MIME parts, and embedded images such as a logo in the signature. How much this amounts to depends on your email program, your text and your recipients.

Which extra bytes you can enter

There is no generally correct value. With 0 extra bytes, the calculator shows only the encoded attachments including line endings, i.e. a model figure without body text or headers. So enter your own assumption that fits your email. A short text without images needs little, while an HTML email with embedded graphics needs considerably more. Values from examples of other emails apply only to those exact emails. If your result is just under the limit, recalculate with a more generous value as a test. If the comparison is still within the limit, you have some leeway. If it tips over, things are tight.

If the email bounces despite passing the comparison

• The message contained more than you assumed in extra bytes, or your email program encodes with different line lengths.
• The recipient's server allows less than your own account.
• The limit applied to the whole message, but you compared it with the original attachments. Or a different rule applies to your account than you assumed.
• The recipient doesn't let certain file types through, such as documents with macros or executable programs, and holds them back regardless of their size.

The calculator only compares the number you selected. It doesn't send anything, doesn't test delivery and checks neither file formats nor security rules. Newsletters are also subject to display limits: some mailboxes show long HTML emails only in truncated form. That is a separate issue from attachment size and is likewise not calculated here.

Too large: continuing with the finished PDF

If the estimate is over the limit, you have two options: reduce the bytes of the file itself, or choose a route other than an attachment. If the recipient explicitly expects an attachment, proceed as follows:

1. Compress the PDF before sending or, if you know a fixed limit, reduce the PDF to fit a size limit. How much a file shrinks depends on its content. A target size cannot be reached in every case.
2. Open the result and check whether the document is still easy to read.
3. Enter the size of the downloaded file here again. What counts is the finished file, not a hoped-for saving.
4. If the estimate fits the limit, send the email. If it doesn't, talk to the recipient about another route.

A sharing link via a cloud or file service can be an alternative if the recipient accepts links and the access rights and data protection are appropriate for your document. You choose the service yourself. This calculator only works with the numbers you enter and does not store or send any files. A ZIP archive, on the other hand, is not a reliable substitute for a smaller PDF: it doesn't necessarily make a PDF smaller, and anyone who explicitly requires PDF files may not accept an archive.

If the file is to be uploaded to a portal rather than sent by email, you can check PDF upload limits and estimate the file's upload time in advance.