MBOX Viewer

An mbox is not a container. It is the messages themselves, written into one file one after another, and the only thing marking where one ends and the next begins is a line that starts with the word From and a space — no colon, which is what tells it apart from the From: header inside a message. There is no index at the front and no lengths recorded anywhere. Gmail Takeout gives you one of these per label, Thunderbird stores every folder as one, and Apple Mail and Mutt both read and write them.

Which is why reading one is mostly a matter of judgement. A body can contain any text at all, and English sentences begin with the word From. Cut the file wherever /^From / matches and you eventually cut somebody’s message in half and show the second half as a new message with no sender — silently, because nothing about it looks like an error. The rule used here is narrower, and all four parts of it have to hold: the line starts a line, a blank line comes before it or it is the first line of the file, what follows From looks like a sender and a date, and the very next line is a header field. The last one does most of the work, since a message begins with headers and prose rarely puts Name: value directly under a sentence. Lines that pass the first three tests and fail the fourth are counted and reported on screen, because a count of near misses is the only honest way to say that a judgement was made.

The blank line is the one of the four that an archive occasionally breaks: it is part of the format, and a few programs that write these files leave it out anyway. Insisting on it there would report a whole export as one message of 900 MB — technically defensible and useless — so when that is what the strict reading gives, the file is read a second time without that test, and the line under the list says which reading you are looking at.

The mail stores that write these files try to help by putting a > in front of a body line that begins with From. They do it in at least two incompatible ways — one convention escapes From only, the other escapes an already-escaped line too — and no archive records which was used. So one > is taken back off a line that has it, which is exact for archives written the second way and removes one character a person typed in the rare case of the first. Where an archive escaped nothing, nothing changes.

The size is the other half of the problem. A Takeout export runs to gigabytes, and a page that reads one into memory as text is a page that crashes the tab. The file is read here in four-megabyte pieces, and what survives each piece is a set of byte offsets and four header fields per message — never the bodies. When you click a message, that one message is fetched back out of the file by its byte range. It is also why the counter moves while a large archive is being read instead of the page appearing to hang, which on this site would be the one thing that looks like an upload.

Nothing in a message is fetched while you read it. A message full of remote images is shown as its text, and the images stay unrequested — so opening a message here does not fire the tracking pixel, and the sender is not told you read it. Every converter that asks you to upload the archive first renders those images on your behalf.

Attachments are listed by name, type and size, and are never decoded — the size is calculated from the encoding rather than by unpacking a 30 MB file to find out how big it is. To actually save one, use the attachment extractor on a single message, and for the Received chain and the SPF and DKIM results underneath it, use the header analyser.

Press Load a sample. It is a three-message archive of 1,466 bytes, and the line under the list reads 3 messages in 1.5 KB followed by Lines inside the messages that begin with the word From: 1.

That one line is the whole point of the sample. Inside the second message is the sentence From 2019 to 2024 the rate held at the same figure. It starts a line, it has a blank line above it, and it has a four-digit year in it — so it passes every test a typical splitter applies, and a typical splitter cuts the message in two there. Here the line under it is total looks familiar., which is not a header field, so the message stays whole and the near miss is counted instead.

Open the third message. Its subject is stored in the file as =?UTF-8?Q?Caf=C3=A9_closes_at_four?= and reads as Café closes at four; its body was sent as quoted-printable and reads as ordinary text. Underneath it, one attachment: rates.csv, 28 B. That size was worked out from the length of the base64 rather than by decoding it, and the file itself was not touched.

Open the second message and look at its last line. In the archive it is stored as >From here on the new rate applies. and it is shown as From here on the new rate applies. — the > was put there by the mail store to stop that line looking like a separator, and taking it off is what gives the sentence back.

On a real export the numbers are larger and nothing else changes: a 4 GB Takeout mbox lists in the same way, one message at a time is fetched when you click it, and the search box filters on sender, recipient and subject without going back to the file. If what you want out of it is a spreadsheet rather than a reader, send it to MBOX to CSV; if you want the messages as separate files, split it into .eml files.