Email reported size inconsistencies

I recently made the leap from MS Outlook to eM Client. In many respects, it was a backwards step since Outlook is widely held as the market leader in terms of email client functionality and stability, but its lack of customisation and in particular, a unified Inbox, finally frustrated me into trying something else and the UI of eM Client appealed. I have already noted a number of eM characteristics that strike me as odd or which could be improved. Rather than listing everything here, which would make it difficult for others to respond to or put me right if I have misunderstood something, I will separate them into individual points over the next few days. I should emphasize that my motivation for posting is (i) to learn how to use the existing product better, and (ii) to provide some pointers for the further development of the product. I have already purchased 2 eM Client Pro licenses, for my desktop and laptop PC, so I have no desire to unfairly criticise the product; I just want to use it better and make it better.

I have imported about 30,000 emails from Outlook and my first observation is a big difference in the reported email size;

  • Imported Emails without attachments are generally smaller in eM Client than in Outlook
  • Imported Emails with attachments are reported as much larger in eM Client than in Outlook
  • If I drag and drop individual or groups of Emails from Outlook local folders to eM Client local folders ( a neat trick that I didn’t realise was possible until I tried it!) the size of the dragged and dropped files in eM Client is different again.

Original emails in Outlook:

The same emails imported into eM Client

Dragged and dropped Outlook emails in bold, next to the same emails imported into eM Client.

Q1 Is there a logical reason for the discrepancy in the reported email size?
Q2 Which size should we believe for sending emails to external addresses with attachment size constraints?

I should add that for the emails with attachments, the email+attachment size in Outlook is much closer to the size of the separate attachment than in eM Client. e.g. for the email reported as 11Mb in Outlook, and 15.6Mb in eM Client (when imported) and 11.5Mb in eM Client (when dragged and dropped to eM), the actual size of the attachments was 11.4Mb. When opening an email, regardless of whether it is in Outlook, imported into eM Client or dragged and dropped into eM Client, the attachments all show as the same size, so the discrepancy is only in the overall email+attachment size reported.

I suspect it’s probably just something to do with going / dragging from one mailer to another mailer the attachment size changes slightly.

As long as when you extract the attachments in eM Client they are the same files and size inside when you open them, then shouldn’t matter the file size difference when attached in eM Client.

Do the files extract the same ?

If they don’t extract the same, try saving the attachments in outlook to your eg: Desktop first and then drag them Into eM Client.

The emails copied from Outlook to eM Client by dragging and dropping report a similar size in eM Client to the original emails in Outlook. The largest discrepancy is with the emails imported from Outlook to eM Client, the 15.6Mb imported email is a good example which is 11.5Mb when dragged and dropped and 11Mb in Outlook. (Outlook doesn’t report the first decimal place).

If I copy the respective emails to my desktop and check the file size in Explorer, the sizes are as follows:

  • imported in to eM Client (*.eml): 15.5Mb
  • dragged and dropped into eM Client (*.eml): 15.5Mb
  • original Outlook email (*.msg): 11.5Mb

Dragging and dropping these 3 emails from my desktop back into eM Client, the sizes now report as:

  • originally imported in to eM Client (*.eml): 15.6Mb
  • originally dragged and dropped into eM Client (*.eml): 15.6Mb
  • original Outlook email (*.msg): 11.5Mb

When forwarding the same email and receiving it on Outlook and eM Client, Outlook reports it as 11Mb and eM Client as 15.6Mb when received.


  1. Some emails with attachments converted from .msg to .eml formats end up with a serious amount of padding (4Mb extra in the above example).

  2. Emails imported from Outlook to eM Client correctly report their size in eM Client (including padding).

  3. For emails dragged and dropped into eM Client from Outlook, the reported size of the .eml file is not correctly reported.

martes 28 junio 2022 :: 1142hrs (UTC +01:00)

Hey @RobinW

Perhaps I do not completely understand what you are saying in English.
ÂżI have to say does size matter?
ÂżIs the content of the messages the same after import?
ÂżDoes the content of the imported attachments match?

ÂżIf all match what is the problem?

¡Buena suerte!

¡Saludos desde Sevilla la soleada en España!


Hablo español, luego portugués e inglés, con conocimiento de varios otros idiomas.

Hi @skybat,

Does size matter? - Yes it does. When sending emails to accounts with size limits I need to understand whether an email is going to get through or not, rather than just sending it and hoping it doesn’t bounce. It is also useful when checking for duplicates (the deduplicate function on eM Client doesn’t always get it right).

I haven’t noticed any difference in the content of the emails or attachments but just wanted to understand why the same email is reported as having different sizes under different circumstances. So for example, when dragging a dropping an email from Outlook to eM Client, if this turns out to be a duplicate of another email perhaps stored in a different folder., it is useful to know that the emails, although duplicates will not show the same size. Comparing the size field may otherwise lead one to conclude that these emails are not the same.

I would also like to understand why the file size of emails with attachments is so much larger in eM Client than in Outlook. Is this a natural consequence of the .eml format compared to .msg or is it a consequence of the conversion process? Does this mean that the storage space required for .eml emails will be much higher than for the same emails stored in PST files?

The purpose of the post is to ask questions to understand better what is happening, rather than to report a problem. The only problem I have noticed is the inconsistency in the reported size when dragging and dropping emails instead of importing them.

martes 28 junio 2022 :: 1309hrs (UTC +01:00)

Hey @RobinW

OK so you say size is important.
I am confused by your reasoning as you are not sending messages you are importing by whatever method you use.
I believe it would need to be a massive size message not to be accepted unless of course the intended recipient mailbox was full.
Also it is my experience that if a message bounces my systems inform me.

ÂżIf it is so important to you, have you made a direct size comparison between identical content messages composed in both Outlook & eMC and then sent to a common recipient in both Outlook & eMC?
ÂżIf so how do the sizes compare?

¡Buena suerte!

¡Saludos desde Sevilla la soleada en España!


Hablo español, luego portugués e inglés, con conocimiento de varios otros idiomas.

@skybat the same applies regardless of whether messages are imported or sent/received, I just discovered it when importing. I already mentioned above:

I have also tried forwarding the original message from Outlook and receiving it on both Outlook and eM Client and the same applies; - the 11Mb Outlook message sent from Outlook is received as an 11Mb incoming email on Outlook and as a 15.6Mb incoming email on eM Client.

If I save the attachments to my hard drive, send a completely new message from eM Client with the same attachments (11.4Mb in size), it is received on eM Client as a 15.5Mb message and on Outlook as an 11Mb message, so it doesn’t matter whether the messages are imported or received from whichever email client they originate, the size discrepancy remains.

I don’t understand why the eml formatted email with attachments is so bloated, - 40% larger in this case. This would imply that the storage space for local folders containing eml format emails - many of which have attachments, should be noticeably larger than the equivalent PST files. Yet weirdly, they are about the same! I would be interested to know if anyone has experience of this from other email clients that use the eml format and whether the same applies or whether this is specific to eM Client.

martes 28 junio 2022 :: 1614hrs (UTC +01:00)

Hey @RobinW

Perhaps I do not understand exactly what you say.
I suggest to create a new identical message and send, you say forward that I think is not the same as send because to me it means a message you have now, not new composed test message.
As you say you have purchased 2 Pro licenses you are able to use VIP support and I think maybe this is best for you as you need professional advice to be able to resolve the issue you have with your size.

¡Buena suerte!

¡Saludos desde Sevilla la soleada en España!


Hablo español, luego portugués e inglés, con conocimiento de varios otros idiomas.


  • imported in to eM Client (*.eml): 15.5Mb
  • dragged and dropped into eM Client (*.eml): 15.5Mb
  • original Outlook email (*.msg): 11.5Mb

The above eM Client “attachment extra size example” you wrote “is normal” in my opinion after my own testing in the last few days of all different modern mail clients with many different file attachments.

I don’t have Outlook to test atm, but I’m sure many other peeps on this free forum do and can test this too with Outlook ,and give their own feedback and opinion on this too.

I have a friend though who has Outlook 2019 business ver and will test that too when I’m there next. They also have eM Client V9 to check.

So the difference I found is that when you attach any attachments like you have above from Outlook, “when it attaches” to many different mailers on PC and Mac “including eM Client”, there is allways “extra bytes or extra data” added to the file size in the mail client other than the original attachment. So the file size will be larger but that’s ok.

So that’s why you are seeing larger file sizes in your Outlook to eM Client example above and nothing wrong at all in my opinion with it.

As I said previously too, when you extract it even though it’s a larger file size which is really only a slight difference in your example, as long as its “exactly the same data & folders etc inside” the attachment, then there is nothing to worry about.

So there is no problem in my opinion when you see the file size bigger or slightly larger than your original file size when attached to eM Client.

Note:- If there is any other reason why it’s larger, other than what I found when testing, then I am sure one of the moderators or staff or other forum peeps like @skybat etc will update this thread".

But from my own testing as far as I can see, that is the reason why it’s a larger file size in eM Client.

For testing purposes I saved my various attachments “to a folder” on my PC and Mac desktop first from other different (Non Outlook) mail clients, before attaching to eM Client again.

Ps I also do the same thing when I drag pictures eg: .jpg .gif .pdf etc files from browsers such as Chrome or any Chromium browser to eM Client.

1 Like

Thanks @skybat
I had the same testing idea about starting from a brand new email and attaching the same attachments to see what happened. This is what I was trying to describe in the second paragraph of my post above. The result was exactly the same as for the previous tests which confirmed that the additional padding was not something specific to the original email. I don’t think I ever said that it was a problem, I just wanted to understand what was happening as I was surprised by the significant difference in the size of .eml emails with attachments, compared to .msg format emails and wondered if this was normal. This forum seemed the best place to share my experience and see how it compared to other peoples’ experiences.

By the way, for anyone who has picked-up on the drag and drop capability between Outlook and eM Client local folders, be sure to set your Outlook calendar to UTC before starting, otherwise the timestamp on the dropped emails will be shifted by whichever time zone you have configured.

@cyberzork thanks for sharing your thoughts. The significant overhead added by eM Client when adding attachments could well be normal, - this is essentially what I am trying to determine. i.e. is everyone experiencing the same or is there something I have done or something peculiar to my installation that is causing this?

Based on your testing, if you attach (say) a 10Mb file to an eM Client email, what is the size reported in eM Client for the combined email+attachment? For me, two attachments with a combined file size of 11.4Mb resulted in a 15.4Mb email size. A 4Mb (40% increase) seems enormously inefficient for transporting a 11.4Mb file, particularly when .eml emails without attachments are actually smaller than their .msg counterparts.

I will do some more research. I just thought someone on the forum may have already encountered the same thing and figured out the answer.


For me, two attachments with a combined file size of 11.4Mb resulted in a 15.4Mb email size

Where do you see the 15.4MB combined total ?

Based on your testing, if you attach (say) a
10Mb file to an eM Client email, what is the size reported in eM Client for the combined
email+attachment ?

Ok will test that later today and update this thread.

martes 28 junio 2022 :: 2109hrs (UTC +01:00)

Hey @RobinW

I have read your latest post and have to say that in my opinion there
is no point in continuing here about your issue with size and as it is a
personal problem it has been said to be not important to others and
I also agree that as I do not have a size problem it does not make
any difference to satisfactory performance.

To repeat what I say above because you have Pro license you will
be better to make a ticket with VIP Support and ask if they can
give any help with your size issue.

I can not help more with your personal size issue and if you think
your performance is affected ask VIP support for assistance.

¡Buena suerte!

¡Saludos desde Sevilla la soleada en España!


Hablo español, luego portugués e inglés, con conocimiento de varios otros idiomas.

After further research…

This article confirms a ~37% overhead when sending attachments in .eml format as opposed to .msg. The 37% overhead in this example (similar to my experience) occurs when the binary .msg format is converted to Base64 for SMTP transmission.

Since the .msg and its attachment is in binary format, they must be converted to Base64 encoding to be suitable for SMTP or email transmission. This encoding may add about 37% to the original file size, this means that an original 20 MB file could exceed a 25 MB file attachment limit.

So, if I have understood correctly, an email with a 20Mb attachment would be stored in .msg format as a 20.x Mb file and in .eml (MIME encoded) format as a 25Mb file, but in both cases a total message size of 25Mb would be transmitted since the .msg format would need to be converted first. From a bandwidth perspective, the common SMTP protocol ensures that the numbers of bytes transmitted would be very similar regardless of whether the email is sent from Outlook or eM Client, but Outlook .msg is a more efficient storage format.

This article explains that the conversion process is uuencoded and encodes 6-bits from each ASCII character into a 8-bits resulting in a 33% overhead.

I don’t know enough about it to determine if the two articles are saying the same thing, but the takeaway is that both confirm that .eml adds a 30-40% overhead when encoding and storing attachments in .eml format compared to Outlook .msg format, which is consistent with my experience. I think this finally answers the question!

I hope this is useful for others who may have encountered the same thing and wondered why such a significant difference exists.

Email was designed to be text only 7-bit characters. That means that to include attachments, messages need to be encoded to text through base64, which ensures that the whole message can pass through the SMTP infrastructure at all points (lowest common denominator of the supported features).

Because of how attachments are encoded, base64 consumes roughly 25% more than the original size. So firstly there is a differences in the size of the overall message compared to the sum of its parts. Secondly, some applications are more efficient in doing this, so the same message sent from one application may be different to it being sent from another.