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 — load the converter, then 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 that does the conversion is right there, in your browser, served unminified. View source on this page; click any of the .js files; you can read exactly what runs, line by line.

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 Google Analytics snippet 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 hidden third-party scripts. Everything the site loads is enumerable in the network panel: our own assets, Google Fonts, the Google Analytics snippet, and — on the converter page — JavaScript libraries from cdn.jsdelivr.net (pdf-lib and jszip, both pinned to exact versions and protected with subresource-integrity hashes) and esm.sh (postal-mime for .eml parsing, msgreader for .msg, pinned to exact versions). That's the complete list.
• No marketing trackers. No Facebook pixel. No HubSpot, no Segment, no Mixpanel, no Hotjar, no session recording. Google Analytics, disclosed above, is the only measurement tool on the site.

Honesty cuts both ways. Here is the full inventory.

• Page views. Google Analytics records that pages were viewed, what referrer brought the visitor, and what browser and device class made the request, using its standard cookies. We look at it in aggregate to know if anyone reads the export guide. It has no visibility into the converter's file handling.
• 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 hello@mailtopdf.com, 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.

Everything this site runs is delivered to your browser in readable, unminified form. View source on any page: every script — including the entire PDF-generation pathway in convert.js — can be read line by line, exactly as it executes. Unlike a repository, the served source is by definition the code that actually ran on your machine.

The third-party libraries are pinned to exact published versions, and the two classic-script libraries (pdf-lib, jszip) carry subresource-integrity hashes on their script tags, so you can verify the bytes against the published packages. A public GitHub repository with a self-hosting guide is planned; until it exists, View Source is the audit surface.

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 and esm.sh serve the libraries. The two classic-script libraries (pdf-lib, jszip) carry subresource-integrity hashes on their script tags: if a CDN served tampered bytes, your browser would refuse to execute them. The parser modules from esm.sh are pinned to exact versions, but ES-module imports cannot carry SRI hashes — a compromise of esm.sh is the residual risk in this design. The honest mitigation is self-hosting all libraries, which is on the roadmap.
• 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.