TL;DR

MHTML is basically a webpage stuffed into a single file — HTML, images, CSS, and fonts all bundled together. To convert it to PDF, the cleanest path is: open the .mhtml file directly in Chrome (double-click, or drag it into a tab), then File → Print → Save as PDF. Everything embedded in the archive renders correctly. For batches of 10, 50, or 500 files, use Convert: Anything to PDF, which processes them locally in the browser without uploading anything.

What MHTML is (and why Chrome handles it natively)

MHTML — sometimes written as .mht — stands for MIME HTML. It's a single-file archive format that stores an HTML document along with every resource it references: images, stylesheets, fonts, sometimes even embedded video. The whole thing is encoded as a MIME multipart message, the same format email uses to bundle attachments.

The point of MHTML is portability. A regular saved webpage is either a bare .html file (which breaks the moment images are missing) or an .html file plus a folder full of assets that has to travel with it. MHTML collapses both into one file you can email, upload, or archive without anything going missing.

Chrome, Edge, and Opera all handle MHTML natively — no extension required. This is because they share the Chromium engine, which has a built-in MHTML parser used by the browser's own "Save page as → Webpage, single file" export. When you open a .mhtml file, the browser decodes the MIME parts, reconstitutes the DOM, and renders it exactly as it appeared when saved.

Firefox and Safari do not open MHTML natively. Firefox needs an extension like UnMHT (which has been unmaintained for years and doesn't work reliably on modern versions). Safari has no built-in support at all. This is one reason MHTML never became universal despite being useful — the format is essentially Microsoft's, standardized as RFC 2557 in 1999, and the non-Chromium browsers never fully adopted it.

For PDF conversion, this matters because the fidelity of your PDF depends on which engine renders the MHTML. Chromium's parser is the reference implementation. Anything else — third-party libraries, online converters running on servers — may drop embedded fonts, mis-parse encoded images, or lose the original CSS. If your MHTML file matters, keep it inside a Chromium-based browser for the conversion.

The other thing to know: MHTML files are usually large. A single archived article can be 2–5 MB because every image is Base64-encoded inline. A saved product page from Amazon or eBay routinely runs 10 MB or more. This is fine for local conversion but a real problem for online converters that impose upload size limits.

Method 1: open in Chrome + Save as PDF

The simplest way. Works on macOS, Windows, and Linux. No extensions, no CLI, no uploads.

Steps:

  1. Right-click the .mhtml file and choose Open with → Google Chrome (or drag the file into a Chrome window).
  2. Wait for the page to fully render. Large archives with many images may take a few seconds.
  3. Press Cmd+P (macOS) or Ctrl+P (Windows/Linux).
  4. In the Destination dropdown, choose Save as PDF.
  5. Set the layout — Portrait is usually right for articles, Landscape for wide dashboards or spreadsheet-style content.
  6. Under More settings, decide whether to include Background graphics. Turn this ON if the original page had colored backgrounds, banners, or dark-mode styling you want preserved. It's off by default.
  7. Click Save, pick a location, done.

The PDF you get is a faithful rendering of the archived page. Text is selectable (not rasterized), links are preserved as clickable annotations, and any hover-triggered elements that were captured at save time appear inline.

Common gotchas:

  • Page breaks split content awkwardly. Set Scale to 85–90% in Print → More settings to shift breaks. Or switch to Landscape for wide content.
  • Fonts look wrong. MHTML usually embeds fonts as Base64, but some savers strip them. If the PDF uses a fallback, the fonts are already gone from the archive.
  • Interactive elements are dead. JavaScript accordions, tabs, and "load more" buttons were captured in whatever state they were in. The PDF is a static snapshot.
  • The file won't open. Older Outlook/IE exports sometimes use non-standard MIME boundaries Chrome refuses to parse. See troubleshooting below.

Method 2: Convert: Anything to PDF (batch)

Chrome's built-in Print flow handles one file at a time. If you have 50 archived pages from a research project, or your team just handed you a folder of .mht files from an old SharePoint export, clicking Print → Save 50 times is not the answer.

Convert: Anything to PDF handles MHTML batches locally. Drop the files into the extension, it converts them one by one, and you get PDFs back — no upload, no server, no size limits beyond your machine's memory.

Why this matters for MHTML specifically: the extension uses the same Chromium rendering engine as the browser's Print dialog. Fidelity is identical to Method 1. You just don't have to sit through 50 individual print flows.

Batch workflow:

  1. Install the extension from the Chrome Web Store.
  2. Click the extension icon, choose Convert files → MHTML.
  3. Drag your .mhtml files into the drop zone. It accepts folders too, so you can hand it an entire directory.
  4. Confirm the output settings (layout, background graphics, margins) once — they apply to every file in the batch.
  5. Click Convert all. The extension processes files sequentially in the browser.
  6. PDFs land in your Downloads folder with matching filenames.

For anything bigger than a few files, this is the only method in the list that doesn't waste an hour. See Batch convert files to PDF: the complete workflow guide for more on batch-conversion patterns beyond MHTML.

If you need to handle a mixed folder — MHTML plus HTML plus DOCX plus images — the Anything to PDF: complete format guide walks through which formats convert cleanly and which need special handling.

Method 3: command line (wkhtmltopdf, Puppeteer)

For automation — nightly conversion jobs, CI pipelines, or piping MHTML through a data workflow — the command line is the right layer.

wkhtmltopdf is the oldest option. It uses an embedded WebKit renderer to turn HTML into PDF. It handles MHTML if you first unpack the archive.

# Extract MHTML to plain HTML + assets
munpack archive.mhtml -C ./extracted/
# Render the extracted HTML
wkhtmltopdf ./extracted/index.html output.pdf

wkhtmltopdf is fast and lightweight but the WebKit build it ships with is old — modern CSS features (grid, container queries, some flexbox edge cases) render poorly. Fine for plain articles. Bad for anything using recent CSS.

Puppeteer (Node.js, headless Chrome) is the modern answer. It runs actual Chromium, so the fidelity matches Method 1 exactly.

const puppeteer = require('puppeteer');

(async () => {
  const browser = await puppeteer.launch();
  const page = await browser.newPage();
  await page.goto(`file:///absolute/path/to/archive.mhtml`);
  await page.pdf({
    path: 'output.pdf',
    format: 'A4',
    printBackground: true,
  });
  await browser.close();
})();

Puppeteer works because headless Chrome parses MHTML the same way the regular browser does. printBackground: true is the equivalent of ticking "Background graphics" in the Print dialog — you almost always want it on.

For batches, wrap it in a loop over a directory. For very large batches, use puppeteer-cluster to run several conversions in parallel without opening a new browser instance for each file.

Playwright works the same way if you prefer it over Puppeteer. The API is nearly identical for this use case.

Method 4: online converters

There are dozens of "MHTML to PDF" web tools. Most of them work. The tradeoff is upload.

You upload your file to a server, it converts, you download the PDF. For a single non-sensitive file — a saved recipe, a public article — this is fine. For anything else, think about what's in the archive before you upload it.

MHTML files often preserve exactly what was on screen: form fields with data still in them, session cookies encoded in image URLs, private URLs from internal tools. Uploading that to a converter you've never heard of hands all of it to whoever runs the server. See Are online PDF converters safe? A honest breakdown for the specifics of what these services keep and for how long.

When online is fine:

  • Public content only (news articles, blog posts, public documentation).
  • The file is small (under 20 MB — many converters cap here).
  • You accept that a copy of your file sits on someone else's server for some period.

When online is a bad idea:

  • Anything from a work intranet, admin panel, or authenticated web app.
  • Anything with personal data — someone else's or your own.
  • Corporate environments where uploading company data to external tools breaches policy.

For sensitive material, use Method 1 or Method 2. Everything stays on your machine.

Troubleshooting: MHTML won't open

Some MHTML files refuse to render even in Chrome. A few common causes and fixes:

"Waiting for cache..." then a blank page. The file may be very large or contain broken internal references. Try renaming the extension to .mht and reopening — Chrome's MHTML handler sometimes routes the file differently based on extension.

Chrome shows the raw MIME source instead of the page. This means Chrome is treating it as plain text. Right-click the file → Open With → Chrome (not "always open with"). If the OS is forcing another app to claim the file, change the default file association.

Blank page, no error. Open Chrome DevTools (Cmd+Opt+I / Ctrl+Shift+I) and check the Console. Common culprits: an old MHTML from IE 6/7 with malformed boundaries, or an archive from a Chinese-language site with a charset declaration Chrome can't reconcile. Try opening the file in a text editor and confirming the top of the file starts with From: or MIME-Version: — if it doesn't, it's not valid MHTML.

File is corrupt or truncated. MHTML transferred via email or old FTP sometimes loses its trailing MIME boundary. Confirm there's a closing marker at the bottom (something like ------=_NextPart_...--). If missing, the file is truncated and no converter will fix it.

As a last resort: the mhonarc or munpack command-line tools can extract the internal HTML and assets from an MHTML file, which you can then open directly in a browser and print to PDF. This bypasses the browser's MHTML parser entirely.

Frequently asked questions

What is MHTML?

MHTML (MIME HTML) is a single-file archive format for saved web pages. It bundles the HTML document with every image, stylesheet, font, and script referenced by the page — all encoded as MIME parts inside one file. It was originally an IE/Outlook format standardized as RFC 2557 in 1999 and is still natively supported by Chrome, Edge, and Opera. The point of the format is portability: a saved webpage that travels as one file, without a separate assets folder to lose or corrupt.

How do I open an MHTML file in Chrome?

Drag the .mhtml file into any Chrome window, or right-click it and choose Open With → Google Chrome. If Chrome opens it as plain text instead of rendering it, the OS is treating the file as text — set the default file association for .mhtml and .mht to Chrome. Edge and Opera work the same way. Firefox and Safari do not open MHTML natively; you'd need a third-party extension (Firefox) or a conversion step (Safari).

How do I convert MHTML to PDF in bulk?

The Chrome Print flow only handles one file at a time. For batches, use Convert: Anything to PDF — drop a folder of .mhtml files, it converts them locally in the browser using the same Chromium engine as the manual Print dialog. For automated pipelines, Puppeteer with page.pdf() gives you the same fidelity from a Node.js script. Both approaches process files without uploading anything.

Does Firefox open MHTML files?

Not natively. Firefox has never included an MHTML parser. The old UnMHT extension used to add support but has been unmaintained for years and doesn't work reliably on current Firefox builds. If you have MHTML files and only use Firefox, the practical options are: install Chrome or Edge specifically to open them, use an online MHTML viewer (mind the privacy tradeoff), or unpack the archive with munpack or mhonarc to get the HTML and assets separately.

MHTML vs PDF — which is better for archiving?

Different jobs. MHTML preserves the page as a live web document — you can copy text, follow embedded links, view source, extract images. It's editable and searchable but only opens in a subset of browsers. PDF is a fixed, universally readable format — every device on earth can open it, but it's harder to edit, and dynamic elements are frozen. For long-term archiving where readability across time matters most, PDF is safer. For research work where you want to keep the original webpage structure, MHTML is more useful. Many workflows save as MHTML for the working copy and export to PDF for the final archive.

Bottom line

MHTML to PDF is one of the easier conversions because Chrome handles both formats natively. For one file, open it in Chrome and use Print → Save as PDF. For a batch, use Convert: Anything to PDF — same Chromium engine, no upload, no size cap beyond your machine. For automation, Puppeteer gives you scriptable browser-quality output. Avoid online converters for anything sensitive; MHTML archives often contain more than you remember putting in them. The whole point of a good conversion workflow is that the tool disappears — the PDF just looks like the page did when you saved it.