How to verify
we're not lying.

MailToPDF is a static website. That sounds technical; it's not. It means the entire site — every page, every script, every stylesheet — is a small handful of files that sit on a content-delivery network and get sent to your browser when you load the page. Once those files arrive, the connection to our infrastructure is over. Your browser does the work.

There is no application server. There is no database. There is no API endpoint that receives your file. We could not log your conversions even if we wanted to — there is nowhere on our infrastructure where the conversion takes place. Your .eml file is read by JavaScript that runs in your browser tab, on your machine, using your CPU. The PDF is built the same way and saved through the standard browser download dialog.

The CDN — Cloudflare Pages, in our case — sees one thing: that your browser asked for the page. It does not see your files because the files are never sent to the CDN. They go from your file system directly into the JavaScript that's already running in your tab.

You don't have to take this on faith. Five minutes with the browser's developer tools is all it takes.

1. Open the developer tools. Right-click anywhere on this page and choose Inspect, or press Cmd+Option+I (Mac) or Ctrl+Shift+I (Windows / Linux). Switch to the Network tab.
2. Reload the page. Watch the requests fly. You'll see the HTML, the CSS, the JavaScript, the fonts, and a couple of images — all served from the CDN. That's the first-load traffic. Note that none of these requests carry any of your data.
3. Open the converter and drop a file. Watch the network panel. Nothing should happen. No new requests. No upload. No silent fetch. The file goes from your filesystem into JavaScript memory; the conversion runs; the PDF downloads. The network panel stays quiet the whole time.
4. If you want to be sure — disconnect from the internet entirely. Toggle airplane mode. Pull the ethernet cable. Then drop a file and convert it. The page still works because nothing on it depends on a network connection past initial load.
5. If you want to be very sure — read the source. The JavaScript file that does the conversion is right there, in your browser, served from the same CDN. View source on this page; click any of the .js files; you can see exactly what runs. The whole site is also published on GitHub for line-by-line audit.

The shortest privacy policy is the one where the company doesn't have your data to begin with. Here is everything we do not have:

• No accounts. The free tier is fully usable without signing up. No emails to leak, no passwords to protect, no profile data to lose.
• No analytics on your file uploads. Because there are no file uploads. The Cloudflare Web Analytics we use measures page views, not user actions inside the converter — there is no event hook on the drop zone, no telemetry on the conversion, nothing.
• No server logs of file contents. There is no server to log them on. Cloudflare's CDN logs request URLs and metadata as part of operating the network, but no MailToPDF-controlled log captures email content. There isn't one to capture.
• No third-party scripts that could be exfiltration vectors. The site loads from a strict allowlist: our own assets, Google Fonts (CSS only, no script), and — on the converter page — JavaScript libraries from cdn.jsdelivr.net (pdf-lib, jszip) and esm.sh (postal-mime for .eml parsing, msgreader for .msg). We document this allowlist in a Content Security Policy header (script-src 'self' cdn.jsdelivr.net esm.sh) so a tampered or malicious script from any other origin would be blocked by the browser.
• No marketing trackers. No Facebook pixel. No Google Tag Manager. No HubSpot, no Segment, no Mixpanel, no Hotjar. The page weight reflects this — the entire homepage including styles and JavaScript is well under a hundred kilobytes.

Honesty cuts both ways. Here is the full inventory.

• Page views. Cloudflare Web Analytics records that pages were viewed, what referrer brought the visitor, and what browser type made the request. This is aggregate, IP-free, and not joined to anything else. We use it to know if anyone reads the export guide.
• Pro tier — your email and a payment processor's customer ID. If you subscribe to Pro, our payment processor (Stripe at launch) sees your email and creates a customer record. We see those two fields and a license token. We do not see your credit-card number; that goes to the processor and never touches our infrastructure. The license token is used for entitlement verification only.
• Support emails. If you write to [email protected], we have a copy of your message in our mailbox. We treat it like any other correspondence — read it, reply, archive. We do not feed it into a CRM or marketing system.

That's the list. There is no fine print.

The entire MailToPDF project is published on GitHub. The repository contains the full source of every page, every script, and every PDF-generation pathway. Anyone can audit. Anyone can self-host on their own infrastructure. Anyone can fork the project and run a private copy that never touches our servers at all.

We commit to keeping the repository up to date with the deployed site. The version of the converter you ran today is the version that's in the repository today. If you want to be paranoid about this, you can compute the hash of the deployed JavaScript and compare it against the hash of the corresponding commit — we publish build hashes alongside each release.

Repository on GitHub  ·  Self-hosting guide  ·  Build verification

No tool protects against everything. The architecture above protects against a specific set of threats and is silent about others. Here is the full picture.

What we do protect against

• Data exfiltration to our servers. We have none. There is nowhere for your file to be exfiltrated to through the converter.
• Data exposure to third parties through us. We share with none. There is no analytics partner with file-level access. There is no advertising network. There is no AI training pipeline.
• Loss of your file. Your file never leaves your device, so we cannot lose it. You can lose it through your own backup choices, but that is between you and your operating system.
• Subpoena of your file contents. We cannot be subpoenaed for what we do not possess. We can be subpoenaed for the fact that someone visited the page from a specific IP, which our CDN does record at the network level — but that record contains no information about which file you converted.

What we don't protect against

• A compromised browser. If your browser has malware extensions, or has been replaced with a tampered build, our JavaScript runs inside that compromised environment. There is no architecture-level mitigation we can offer; the browser is the trust boundary.
• A compromised operating system. Same logic. If the OS is keylogged or screen-recorded, we can't do anything about it.
• Screen-recording on your device. If software on your device is taking screenshots, the rendered email body in the converter preview is visible to that software. The mitigation is on your end (close other apps, run on a clean machine).
• A third-party CDN compromise. Cloudflare Pages serves the site; cdn.jsdelivr.net serves the parsing and PDF libraries. If either CDN were compromised and modified to serve a malicious version of the JavaScript, your files would still not leave your device through the converter — the malicious script would have to upload them somewhere, and our CSP would block requests to any unknown origin. But a sophisticated attacker who could rewrite the CSP itself could open such a hole. We mitigate this with sub-resource integrity hashes on every CDN-loaded library: if the bytes don't match the published hash, the browser refuses to execute. Sub-resource integrity is documented on each library script tag.
• An attacker with physical access to your device. Out of scope. If they have the laptop, they have the email files anyway.

The architecture is the strongest privacy protection a web tool can offer. It is not a perfect protection, and we won't pretend it is. The threats it doesn't address are out of any web app's reach — they require a clean device and disciplined operational hygiene from you. We assume you bring those.