How to Split Large Thunderbird Mailbox Files Without Losing Emails

A Thunderbird folder is not a folder. It is one file, holding every message you ever received, one after another, in the order they arrived. That design has aged remarkably well — it is why a mailbox written in 2004 still opens today — but it has one consequence people discover late: after fifteen years, your Inbox is a single 14 GB object, and everything you might want to do with part of it involves moving all of it.

Sooner or later there is a reason to cut it up. A lawyer asks for one year of correspondence. You are leaving a company and only the project mail is yours to take. You want the 2008–2015 half on an external drive and the rest in daily use. Or the folder has simply become unwieldy and you want it in slices you can back up separately.

The advice you will find in forums is to cut the file with split, or with a text editor, or with csplit on /^From /. Please do not. Here is why, and here is what to do instead.

Why cutting an mbox by hand goes wrong

An mbox file is a plain concatenation: each message begins with a line starting From — the envelope line, not the From: header — and runs until the next one. That is the whole format.

Cut that file at an arbitrary byte or line offset and you will land in the middle of a message roughly every time. The first part ends with half a set of headers; the second begins with a body that has no headers at all and is not a message any more, just text. Both files still look fine — they open, they are the right size — and the damage is only visible when you go looking for one specific email years later.

Cutting on the From pattern is smarter and still not safe. The mbox family escapes a body line that begins with From by writing it as >From , but not every program that ever wrote your mailbox did so, and a quoted reply can easily contain a line that starts with “From ”. Split on the pattern and that message tears in two — one email becomes two half-emails, and nothing tells you it happened.

Which is the real problem with all the by-hand routes: they give you no count. You do not know how many messages went in, how many came out, or whether the numbers match. The safe way to split a mailbox is to treat it as mail rather than as text — parse it, select whole messages, write them back out — and then check the arithmetic.

Before you cut: three things about Thunderbird’s files

Each mailbox lives as one extension-less file inside your profile:

• Windows: %APPDATA%\Thunderbird\Profiles\<profile>\Mail\Local Folders\
• macOS: ~/Library/Thunderbird/Profiles/<profile>/Mail/Local Folders/
• Linux: ~/.thunderbird/<profile>/Mail/Local Folders/

Inside you will find INBOX, Sent, Archives and your own folder names, each next to an .msf file of the same name. The .msf is Thunderbird’s index and can be ignored — it is rebuilt on demand. The extension-less file is the mail itself, in standard mbox format. (There is a fuller tour in our guides for macOS and Windows.)

Three rules before you touch anything:

Quit Thunderbird. It keeps the file open and writes to it; splitting a mailbox that is being appended to is how you get a half-message at the end.

Work on a copy. Copy the mailbox file somewhere else — the Desktop is fine — and split the copy. Never move the original out of the profile: Thunderbird will decide the folder is gone.

Compact first, or know what you are keeping. When you delete a message, Thunderbird marks it and leaves it in the file; the bytes go away only when the folder is compacted. That is why a folder showing 4,000 messages can be 9 GB. If you split without compacting, those deleted messages come along into your pieces — they are still perfectly readable mail. Right-click the folder → Compact first if you do not want them, and skip it deliberately if you do.

Step 1 — measure before you cut

Before deciding where the cuts go, look at what is actually in the file. mboxShell, our open-source (MIT) terminal tool, reads Thunderbird’s extension-less files directly, has no size limit, and never writes to the file it opens:

$ mboxshell stats INBOX

  File                 INBOX
  File size            9.41 GiB
  Messages             128,455
  Date range           2004-02-11 — 2026-08-19
  Index size           14.2 MiB
  Indexing time        48.31s
  With attachments     19,880 (15.5%)
  Duplicates           312 (128,143 Unique IDs)

Write those two numbers down — message count and date range. They are what you will check against at the end.

Now plan the cuts without producing anything. search counts a slice for you, so you can try boundaries until the pieces are the size you want:

$ mboxshell search INBOX "after:2004-01-01 before:2010-01-01" --json | head -3
{
  "result_count": 31204,

after: includes its own day and before: excludes it, so consecutive ranges written this way meet exactly — no gaps, no overlaps. That property is what makes the final check work. The full search syntax also lets you slice by sender, by size or by attachment instead of by date, if that is what your split is really about.

Step 2 — cut the mailbox

With Mbox Viewer, on Mac or Windows, the split is the export you already know:

1. Open the copied mailbox file — the extension-less one, no renaming needed.
2. Search for the slice: after:2004-01-01 before:2010-01-01.
3. Select the messages: click the first row, then Shift-click the last one to take the whole range.
4. File → Export (⌘E) → MBOX. On Windows it is Export → To MBOX…, and there you can skip step 3 entirely: with nothing selected it exports everything the search left on screen.

You get one new mailbox file, offered as INBOX-selection.mbox, holding exactly those messages. They are copied byte for byte, so the result is a valid mailbox that any client opens, and the file you opened is never touched — the app is strictly read-only. Repeat for each slice. Exporting to MBOX is part of the free tier; what the free tier limits is the size of the mailbox you open, which is 1 GB.

With mboxShell only, the route is different, and it is worth being straight about the limitation: mboxShell exports to EML, CSV, text and HTML — it does not write a partial mbox. So the terminal-only path is to export each slice as a folder of EML files and let Thunderbird rebuild the mailbox on import:

$ mboxshell export INBOX --format eml --query "after:2004-01-01 before:2010-01-01" --output ./2004-2009/
  Exporting 31204 message(s) as eml to ./2004-2009/
  Exported 31204 .eml files

It is a longer way round, but it is free, it has no size limit, and it scripts. The other half of the job — putting mailboxes together — is the one mboxShell does write mbox for: mboxshell merge a.mbox b.mbox -o merged.mbox.

Step 3 — prove that nothing was lost

This is the step that separates a split from a gamble, and almost nobody does it.

Count each piece. Run stats on every slice and add up the message counts. The total has to equal what the original reported. If it is short, a boundary is wrong; if it is over, two slices overlap.

Check the date ranges. Each piece’s range should sit inside the boundary you asked for, and the pieces should line up end to end with no hole between them.

Rebuild the original and compare. This is the decisive one. Merge the pieces back together — deduplication by Message-ID is on by default — and read the summary:

$ mboxshell merge 2004-2009.mbox 2010-2017.mbox 2018-2026.mbox -o rebuilt.mbox

  Merge complete:
  Input files               3
  Total messages            128,455
  Duplicates removed        0
  Output size               9.41 GiB
  Output file               rebuilt.mbox

Total messages matching the original count and Duplicates removed at zero together say that your slices were complete and disjoint: every message is in exactly one of them. If duplicates appear, your ranges overlap. If the total is low, something fell between two cuts. Either way you know before you delete anything — which is the whole point.

Only now is it reasonable to archive the original away. And even then: keep it. Disks are cheaper than the email you cannot get back.

Step 4 — put the pieces back into Thunderbird

If the slices are meant to stay in Thunderbird as separate folders, the free ImportExportTools NG add-on imports an mbox file straight into Local Folders as a new folder — and can also import a directory of EML files, which is what closes the mboxShell route. Do it with Thunderbird running, through the add-on, rather than by dropping files into the profile by hand; that way Thunderbird builds its own .msf index and knows what it has.

And if the pieces are not meant to go back — the year that goes to the lawyer, the archive that goes on the external drive — they do not need to. They are standard mbox files. Mbox Viewer opens them, mboxShell opens them, and so will whatever reads mail in twenty years, which is more than can be said for most of the formats that came after.

What not to do

• Do not delete the original until the arithmetic in Step 3 checks out.
• Do not split by bytes or lines with split, dd or a text editor, and do not open a multi-gigabyte mailbox in an editor at all.
• Do not rename or move the original inside the profile. Thunderbird tracks folders by file name.
• Do not trust a piece you have not counted. A file that opens is not the same as a file that is complete.