Email Size Estimator

Find out how heavy a message really is before you press send.

Runs on your deviceEmailWorkingNo account needed

What this tool does

Email Size Estimator takes a list of attachments — a name and a size on each line — and works out what the finished message weighs on the wire. Attachments do not travel as bytes; they travel as base64 text, four characters for every three bytes with a line break every 76 characters, which adds roughly 37 per cent. The tool applies that inflation, adds 220 bytes of MIME headers and boundary for each part, adds the encoded body and a header block, then sets the total against eight published send limits — seven named services and one generic corporate gateway.

Three settings shape everything that is not an attachment. Body text length is a character count, converted at about 1.08 bytes per character for plain text — UTF-8 plus quoted-printable escapes — and at 3.5 times the character count for HTML, on the assumption that markup roughly triples a body. Body format decides how many parts are counted: HTML with a plain-text alternative counts three, because multipart/alternative needs a container of its own. The header block defaults to 2 KB, a fair allowance for the Received lines, DKIM signatures and trace fields that relays add on the way through.

The limit worth knowing first is that the tool never sees your files. You type the sizes, so nothing is uploaded and nothing is read — and the attachment figures are therefore only as good as the numbers you entered, while the body figure is a multiplier rather than a measurement. A template dense with inline CSS can miss the 3.5× estimate by a wide margin, so paste the finished message into MIME Viewer when you need real part sizes. Sizes are read in 1024-based units throughout, meaning MB is 1,048,576 bytes on both sides of the comparison.

The provider table is a fixed list held in the page rather than a live lookup, and the figures are published defaults: 25 MB for Gmail, Microsoft 365, Yahoo and Proton Mail, 20 MB for Outlook.com, iCloud Mail and Zoho's free plans, and 10 MB for the kind of on-premise gateway nobody has raised in a decade. Administrators move these — Exchange Online can be taken to 150 MB — and the cap that decides delivery is the smallest one anywhere along the path, including the recipient's, which you cannot see from here.

How to use it

  1. List the attachments, one per line. A name and a size, such as report.pdf 2.3 MB. Spaces, commas, colons, semicolons, pipes and tabs all separate the two, round brackets around the size are tolerated, KB, MB and GB are accepted alongside the KiB, MiB and GiB spellings, and a bare number is read as bytes. The number has to be the last thing on the line: put square brackets around the size, or the filename after it, and the line is skipped.
  2. Set the body length and format. Type roughly how many characters the body runs to, then pick plain text, HTML, or HTML with a plain-text alternative. The last of those counts three MIME parts instead of one, and costs the most.
  3. Adjust the header block if you know better. 2048 bytes is the default. Raise it for mail crossing several relays or carrying long DKIM and ARC signatures, or drop it to zero to see the parts on their own.
  4. Read the table, then the limits. Each attachment row gives the file on disk, what it becomes inside the message, and the percentage that adds; the last three rows are the body, the header block and the message total. Underneath, every provider is marked with the headroom left or the amount the message is over by.

Processing & privacy

Runs on your device. Your file is processed directly in this browser.

Common use cases

Deciding whether to attach or share a link

Five photographs straight off a phone clear 25 MB once encoded even though the folder reads 19 MB. The estimate tells you that before the bounce message does.

Sending to a corporate address

Plenty of large organisations still cap incoming mail at 10 MB. That gateway sits in the table beside the consumer services, and it is the row that fails first.

Sizing a newsletter with inline images

Images embedded in an HTML message are base64 parts like any other attachment. List them by size and the total reflects what the send actually costs.

Working out how much you can attach

Whenever a limit is missed, the result works back from 25 MB — always that figure, whichever provider you actually failed — subtracting your body and header block to reach a rough on-disk ceiling. Aim below it: the arithmetic rounds generously and skips the per-part MIME overhead, so sending at exactly that size lands a shade over.

Questions

Are my files uploaded?
There are no files. You type names and sizes, the arithmetic runs in this browser tab, and nothing is transmitted — the page still works with the network disconnected. The trade-off is that it cannot check the sizes you gave it.
Why is the message bigger than the files?
Base64 is the main cause: three bytes become four characters, with a CRLF every 76, so attachments grow by about 37 per cent. On top of that sit the MIME headers and boundary for each part, the encoded body and the header block. Providers measure the encoded message, not the files in your folder.
How accurate is the estimate?
The attachment arithmetic is exact for the sizes you entered. The body is not: plain text is counted at 1.08 bytes per character and HTML at 3.5, which are averages. Heavy inline styling, or a body full of accented or non-Latin text, will run past them.
Is MB read as 1,000,000 or 1,048,576 bytes?
1,048,576 — the binary sense — for the sizes you type and for the provider limits alike. MiB, KiB and GiB are treated as spellings of the same units, so mixing the two notations changes nothing.
Why was one of my lines ignored?
It carried no number, or a unit outside the set it knows — bytes, KB, MB, GB and their binary spellings — or a number that was not the last thing on the line, which is what a square bracket after the size or a filename written after it produces. Ignored lines are listed at the bottom of the result rather than dropped in silence, so a typo cannot quietly shrink the total.
If it fits, will the message arrive?
Not necessarily. Size is one reason mail is refused; authentication, sending reputation and content filtering are others, and the receiving server may enforce a smaller cap than the one you send through. This covers message weight and nothing else.
Can it measure a message I have already written?
Not from the message itself. Export it as .eml and open it in MIME Viewer, which reads the real parts and their encodings. The estimator is for the stage before that, when you are still deciding what to attach.

Related tools