Gmail Takeout gives you an archive, not an inbox interface
Google Takeout can export Gmail message content, headers, attachments, labels, settings, and other mailbox information. Google also documents that Gmail labels are preserved in a special X-Gmail-Labels header in downloaded mail. That makes an MBOX export portable, but it is still a transfer/archive format rather than a convenient browser inbox.
- Extract the Takeout ZIP or TGZ first, then open the resulting mail MBOX file.
- Encrypted messages remain encrypted in Google's downloaded data.
- Keep the original Takeout archive separately when long-term preservation matters.
MBOX is a family of formats, so separator detection must be conservative
RFC 4155 describes the common MBOX model as a linear sequence of Internet messages, each preceded by a From separator line, while also warning that many implementation variations exist. A viewer should therefore recognize plausible separator lines rather than splitting on every message-body line that happens to begin with the word From.
- The source message bytes after each separator are ordinary Internet email records.
- Body text can legally contain lines that resemble ordinary prose beginning with From.
- A malformed or unfamiliar MBOX variant should be reported instead of silently producing incorrect message boundaries.
MIME explains why one email can contain several encodings and parts
RFC 2045 defines MIME content types and Content-Transfer-Encoding values such as Base64 and quoted-printable. A single message can contain multipart alternatives, HTML, plain text, inline images, attached documents, nested multiparts, or encrypted payloads. Reading an email archive therefore requires more than splitting headers from body text.
- Prefer text/plain for a readable body when it exists; HTML can be converted to readable text for review.
- Decode transfer encoding according to the MIME header instead of recursively guessing arbitrary Base64 layers.
- Keep attachment names, content types, disposition, content IDs, and estimated/actual bytes visible for audit.
Decode subjects, names, thread references, and Gmail labels without hiding the raw evidence
Older and international email commonly uses RFC 2047 encoded words in Subject, From, or other headers. MIME filename parameters can also carry percent-encoded character sets. A useful archive viewer decodes these for reading while still preserving the original source message separately.
- Message-ID is useful for duplicate detection and thread relationships, but it is not a signature.
- In-Reply-To and References can provide thread linkage when senders generated them correctly.
- X-Gmail-Labels is Google-specific metadata and should be treated as mailbox organization evidence, not message-authentication evidence.
Search huge mailboxes without keeping every decoded body in memory
Headers, labels, dates, attachment counts, and short body snippets can be indexed during the first pass. Full body text for a large MBOX should not be retained indefinitely just to support search. A bounded deep body scan can re-read each source message sequentially only when the user requests it.
- Instant search should cover subject, sender, recipients, labels, Message-ID, and indexed snippets.
- Deep body search can decode one message at a time and discard it after testing the query.
- Render a bounded number of message rows so a 100,000-message archive does not mount 100,000 DOM nodes.
Extract attachments only when the user asks for them
Attachment inventory can often be calculated from MIME structure without retaining every binary attachment in browser memory. When the user opens or exports a selected attachment, the viewer can re-read that one source message, decode the appropriate transfer encoding, and download or package the resulting bytes.
- Use the Content-Disposition filename or MIME name parameter conservatively.
- Inline Content-ID parts are separate from ordinary attachment files but still deserve inventory visibility.
- Bound cumulative decoded attachment ZIP size before generating a download.
Choose PDF, HTML, CSV, JSON, EML, or a record ZIP for different needs
PDF and HTML are convenient reading copies, CSV is useful for message metadata review, JSON keeps structured fields, source EML ZIP preserves selected raw message records, and a record ZIP can combine source messages, derived exports, attachments, README notes, and a SHA-256 manifest.
- Redaction belongs only in derived copies; raw source EML bytes should remain unchanged.
- CSV fields that begin like spreadsheet formulas should be neutralized before download.
- A checksum tells you whether packaged bytes changed later; it does not prove who sent a message.
Know what an email archive cannot prove by itself
MBOX and EML are valuable record formats, but their fields are not cryptographic proof. An exported file can be copied or edited after export, a mailbox can be incomplete, and normal headers such as From or Message-ID can be forged. OpenFileTools therefore treats its outputs as review and recordkeeping artifacts, not forensic certification.
- Preserve the original archive and surrounding account/device records when authenticity matters.
- Encrypted content requires the actual cryptographic keys and supported software; the viewer should not guess or bypass encryption.
- Legal discovery, retention, compliance, and admissibility requirements depend on the relevant organization and jurisdiction.
References and source documentation
Platform guidance and operating-system behavior can change. Review the linked source when a current requirement matters.
Google Account Help — How to download your Google data ↗Gmail Help — Export your data from Gmail ↗RFC 4155 — The application/mbox Media Type ↗RFC 2045 — MIME Part One ↗RFC 2047 — Message Header Extensions for Non-ASCII Text ↗