What is an MHT File And Why Email Tools Produce Them

An MHT is a web page with everything it needed packed in beside it. The container doing the packing is the one email has used for decades. The file says so outright by declaring itself as message slash rfc822. That single line explains why these keep turning up in mail folders.

People meet the format from two directions. One person saved a page in Internet Explorer or Edge and got a file. Another saved a message and got a file that looks the same. Neither can quite tell which they are holding. The file will not tell them either, because both answers are written the same way underneath. Where that leaves MHT against the formats built to hold messages is a question of what the headers are describing rather than how the file is built.

The Same Container As Email, Doing a Different Job

MIME was designed so that one message could carry several parts at once. Text here, an image there, a spreadsheet after it. RFC 2557, published by the IETF in March 1999, took that arrangement and pointed it at a web page instead of a message.

Nothing about the container changed. What changed is what the parts are and how they refer to each other.

Why the File Declares Itself an Email

Open one in a text editor and the top looks like mail. Headers, a boundary marker, then encoded blocks. The media type recorded inside is the one mail messages use, which no other document format claims.

From: <Saved by Blink>
Subject: Quarterly figures
Date: Tue, 4 Aug 2026 09:14:22 +0100
MIME-Version: 1.0
Content-Type: multipart/related;
    type="text/html";
    boundary="----MultipartBoundary--Kq81"

------MultipartBoundary--Kq81
Content-Type: text/html
Content-Location: https://example.net/reports/q2

A Subject line on a web page is not a mistake. The container expects those headers, so browsers fill them in with whatever they have. The page title becomes the subject and the saving engine names itself as the sender. None of it means the file was ever sent anywhere.

That shared declaration is the whole reason mail tools handle these files. An MHT dropped into a mail client opens, because as far as the client is concerned it received something in a format it already understands.

Where the Two Extensions Came From

The same format ships under two names and the difference is nothing but length.

Internet Explorer arrived when three character extensions were still the convention, so it took the short form. Chromium took the longer one later. Opera went further than either for a while, making MHTML its default way of saving a page from version 9.50 until the Presto line ended in 2013, while Vivaldi and Yandex can write the format today but keep it behind a flag. Renaming one to the other changes which program offers to open it and changes nothing inside the file.

Which Programs Will Actually Open One

Support for the format has always been uneven. It has been getting narrower rather than wider.

Microsoft Edge
Google Chrome
Microsoft Word
Internet Explorer   retired 2022

Mozilla Firefox     never did
Safari              uses .webarchive
most mail clients   render as text

What the Format Captures And What It Misses

An MHT records what the browser had fetched at the moment of saving. That is a narrower thing than what you were looking at.

That last row is why archivists use something else. WARC records the exchange rather than the result, so it keeps the request, the response headers and every redirect on the way. National libraries and the large web archives run on it. MHT keeps a picture of the outcome and throws away how it was reached.

Why It Shows Up in Mail Work So Often

Three habits push these files into mailboxes. None of them involve anybody choosing the format on purpose.

1. Somebody saved a page and sent it. One file, no folder of loose images, which made it the obvious thing to attach before cloud links were normal.
2. Somebody saved a message as a web page. Outlook offers this. The result is an MHT holding a rendering of the message rather than the message itself.
3. Somebody renamed an EML to see it in a browser. This works because both are MIME, which is a useful trick and leaves a file whose name now disagrees with its history.

The second habit costs the most. Saving a message this way keeps how it looked and discards the headers that say where it came from. For casual reading that is fine. For anything that has to be shown to be genuine, an EML keeps what an MHT drops.

Reading One Without Guessing

1. Open it in a text editor first. Content-Location headers pointing at web addresses mean a saved page. Received headers and a real sender mean somebody renamed a message.
2. Try Edge or Chrome before anything else. Both render the format natively, which answers what is in there faster than any conversion.
3. Expect the interactive parts to be missing. The static content is what survives. Anything that needed the network is not coming back.
4. Use something else for anything you save today. Extensions such as SingleFile write a page into one ordinary HTML file with everything inlined, which any browser opens without special handling. That is where the single file idea went once native support stopped growing.
5. Convert to PDF if it has to be kept. Support is narrowing rather than widening. A PDF will still open in twenty years without an argument.

Where a folder of these turns out to be renamed mail rather than saved pages, our EML viewer reads them as what they actually are. Turning them into a format another mail program will accept, such as PST or MBOX, is a job for the converters.