Free developer tools · Guides

EMAIL TROUBLESHOOTING

Estimate MIME attachment size and base64 overhead

The size of a file on disk is only one part of an email message. MIME headers, boundaries, transfer encoding and line breaks also consume bytes. Inspect a representative message before extrapolating a monthly data estimate.

Inspect a MIME message locally

The base64 size calculation

Base64 represents three input bytes with four encoded characters, with padding for an incomplete final group. The basic size formula is 4 × ceil(raw bytes ÷ 3), before line wrapping and MIME headers. For very small files, padding makes the percentage overhead larger than the familiar one-third approximation.

Raw bytesBase64 charactersBefore MIME overhead
14300% larger
24100% larger
3433.3% larger
1,0241,36833.6% larger
1,000,0001,333,336About 33.3% larger

Use a representative MIME message

Open a saved .eml file or paste the raw headers and body into the inspector. Start with its built-in sample to see a two-part message. Use the source message rather than a screenshot or rendered email: visible text does not expose all boundaries or encoding. The tool recognizes a bounded subset of MIME and rejects malformed structures rather than promising universal mail-client compatibility.

Read the byte totals carefully

Normalized wire bytes describe the message after line endings have been normalized for inspection. Decoded base64 bytes estimate the original bytes in those encoded parts. Base64 payload wire bytes cover those parts' encoded data, not every byte in the whole message. These measurements answer different questions. Compression, provider transformations and transport details can change an actual bill.

Scale the data without leaking content

Set the number of copies to model aggregate transfer for the same payload. Sending one million copies is an arithmetic scenario, not evidence of your future volume. The exported report omits addresses, filenames, body text and raw headers. Still inspect any artifact before sharing it. The local workspace never fetches attachments or sends a test message.

Connect size to the email budget

If message-data charges apply to your provider, carry a representative encoded-size assumption into the email budget planner. Confirm the chargeable unit and current rate first. A payload estimate does not establish maximum accepted message size, spam placement or delivery success. Use the provider's applicable message limits and a separate sending test for those questions.

Read the measurement cards before the JSON

Normalized message size counts the whole serialized message with CRLF line endings. Decoded base64 content describes the content before base64 encoding; encoded base64 wire size includes its encoded text and line breaks. The overhead card compares these two values, which is why a tiny three-byte example can show 33.3% while a wrapped real payload differs. Base64 measurements may include inline images as well as attachments. The monthly card multiplies the measured encoded base64 bytes by recipient copies and the displayed data-rate assumption. A sub-cent result is shown as less than $0.01 rather than rounded to zero.

Troubleshoot source and parser errors

Paste the original message source rather than the visible message body. The parser needs recognizable headers, a blank line, and the MIME body. A multipart message also needs a boundary parameter and its closing marker. The built-in synthetic example provides a known working structure. If a local file fails UTF-8/ASCII decoding, export a compatible original message; renaming an arbitrary binary file to .eml does not convert it. Messages larger than 2 MB are outside this local tool’s scope. Inspecting an excerpt cannot establish the complete message size.

Why a 10 MB attachment becomes about 13.7 MB

For a 10,000,000-byte file, 4 × ceil(bytes / 3) gives 13,333,336 Base64 characters. Wrapping at 76 characters with CRLF after each line adds 350,878 bytes, giving 13,684,214 bytes, about 13.68 decimal MB. Omitting the final CRLF changes this example by two bytes. The complete email also includes MIME headers, boundaries, text and other parts. This arithmetic example exceeds the inspector’s 2 MB input limit: use it for planning, not as a file the tool promises to open.

C = 4 * ceil(raw_bytes / 3)
wrapped_bytes = C + 2 * ceil(C / 76)
Assumption: every Base64 line ends with CRLF.

Check MB, MiB and the object a provider limits

A decimal MB is 1,000,000 bytes, while a MiB is 1,048,576 bytes. A 10 MiB attachment therefore starts at 10,485,760 bytes and becomes 13,981,016 Base64 characters before wrapping. Check whether a documented limit applies to an original attachment, an API request or the entire MIME message. A sender accepting a request does not establish that the recipient will accept delivery. Measure the generated message and inspect the actual error when a message is rejected.

Avoid double encoding and misleading cost claims

Follow the sending library’s contract: some APIs take Base64 attachment data, while libraries that assemble MIME may expect raw bytes. Encoding an already encoded value again increases size and can corrupt the recipient’s expected attachment unless decoded correspondingly. A roughly one-third increase in payload does not imply a one-third increase in the invoice; some plans charge per message and others include separate data charges. Compare the provider’s current billable units with the complete message.

Test the 57-to-58-byte Base64 line boundary

With Base64 wrapped at 76 characters and a CRLF after every nonempty encoded line, 57 raw bytes become 76 encoded characters and 78 payload bytes. At 58 raw bytes, 80 characters occupy two lines and produce 84 payload bytes: six more for one additional input byte. This convention includes the final CRLF but excludes MIME headers, boundaries, message text and SMTP details. Empty input produces no encoded line. Match the same convention when comparing an inspector result.

import base64
for n in (57,58):
    encoded = base64.b64encode(bytes(n))
    wire = b"".join(encoded[i:i+76] + b"\r\n" for i in range(0,len(encoded),76))
    print(n,len(encoded),len(wire))
# 57 76 78
# 58 80 84
Raw bytesBase64 charactersWrapped payload bytes
000
146
246
346
567678
577678
588084
114152156
115156162

Reproduce this example

The attachment decodes to ABC: three bytes represented by four base64 characters. Whole-message bytes also include MIME headers, boundaries and line endings.

Load Three-byte synthetic MIME attachment

Download three-byte-attachment.eml — synthetic data you can save or reference. The diagnostic samples contain no real addresses, credentials or hosted streams. Scenario CSVs document inputs; the calculators do not import CSV.

Download a reproducible reference

Reproduce the raw-byte, Base64 and CRLF calculations. Values above 2 MB are planning examples and exceed this inspector’s input limit. MIME boundaries, headers and message text are additional.

Download the MIME Base64 reference table

Common questions

Why is my attachment bigger after encoding?

Base64 expands groups of three bytes into four characters and may add padding. MIME framing and line wrapping add more bytes.

Will this send the email or upload the .eml file?

No. File reading and parsing occur in the browser workspace. The tool has no send-email operation.

Can I share the report without exposing recipients?

The report deliberately omits raw content and identifying headers. Review the resulting file before sharing; do not share your original message by mistake.

Try it with your own scenario

Inspect a MIME message locally

The tool is free to use. Product inputs stay in the local browser workspace. Provider links, where present, are separate from the calculation.

References and scope

Updated 2026-10-24. Examples are illustrative calculations, not measured customer outcomes. Provider prices and terms must be checked at purchase time.