We Measured Six Disposable Email Services Instead of Listing Their Features

Every comparison of disposable email services looks the same: a grid of ticks and crosses for features anyone can claim. Attachments supported — yes. No signup — yes. Privacy-focused — yes. None of it is verifiable, and the site publishing the grid always wins its own comparison.

So we did something different. On 24 September 2026 we measured six services from the outside — one ordinary request each, the same request your browser makes — and wrote down numbers. Ours are in the table too, including the one that does not flatter us.

What we measured, and what we did not

Everything here comes from a single GET request to each homepage, plus the response headers. Nothing intrusive, nothing that involved creating accounts or sending mail through anyone else's service.

That constrains what we can honestly report. We measured what is delivered to a browser: how much HTML, how many scripts, how many outside hosts the page pulls from, and which security headers the server sets. We did not measure inbox delivery speed, uptime, or what happens after you generate an address — those require testing each service in ways that would be both intrusive and unfair to run at scale.

Page weight and third parties

* The asterisk on our own row matters. Our homepage HTML references zero third-party hosts, but that number is flattering by accident. Ghostmails loads the Google AdSense script after the page renders, so it does not appear as an attribute in the delivered HTML the way another site's ad tags do. Measured the same way as the others, we look cleaner than we are. A reader deserves to know that before drawing conclusions from the column.

What the other columns show is more solid. Mailinator delivers roughly six times our HTML and nearly three times our script count. And of the six services, only one sets a Content-Security-Policy header — a policy that tells the browser which scripts are allowed to run at all, and the main defence against a third-party script misbehaving on a page where people read their mail.

GuerrillaMail sets no X-Frame-Options header, which means nothing prevents another site from embedding its pages in a frame.

Blocklist presence

We published the full blocklist measurement separately: four public lists, 64,609 unique domains, checked against ten services. The short version for the five here:

The honest reading, which we also gave in that article: we are absent from every list mainly because the domain is young and small, not because we are cleverer. It will change as the service grows. Until it does, an address from an established service is far more likely to be refused at signup than one of ours.

The difference that is structural, not incidental

One distinction in this field does not come from age or budget, and it is worth stating plainly because it changes what a temporary address is safe for.

On several established services, inboxes are public by design. Mailinator and GuerrillaMail both document this openly: any inbox can be opened by anyone who types the address, with no credential involved. That is a deliberate product decision — it is what makes them useful for shared testing, and they are upfront about it.

Ghostmails works the other way. Each address is bound to a signed session cookie held only by your browser, and the server refuses any request for an inbox that does not carry the matching session. Knowing the address is not enough to read what it received.

Neither choice is wrong. They serve different purposes. But if a message arriving at that address might contain a password reset link, a verification code, or an order confirmation with your name on it, a public inbox and a private one are not interchangeable — and a feature grid with "privacy-focused: yes" in every column will never tell you which is which.

What none of this measures

Stating the gaps, because a comparison that only lists its strengths is the thing we set out to avoid.

• Delivery speed is missing. How fast a message actually lands is arguably the most important property of these services, and it is the one we have not measured. We are running that test next, against our own service, and we will publish the numbers whatever they are.
• Homepage weight is not the whole site. We measured one page per service. Inbox pages may behave differently.
• A snapshot, not a trend. All figures are from 24 September 2026. Sites change.
• Security headers are a floor, not a verdict. A CSP is good practice, not proof of a well-run service, and its absence is not proof of a bad one.
• We are not a neutral party. We built one of the six. That is exactly why every number here comes with its method attached.

Reproducing this

One request per site, then count. No special tooling:

# HTML weight and script count
curl -sSL https://example.com/ | wc -c
curl -sSL https://example.com/ | grep -c "<script"

# Security headers
curl -sSLI https://example.com/ | grep -iE "strict-transport|content-security|x-frame"

Run it yourself. If our numbers are wrong, we would rather hear it from you than keep publishing them.

Where this leaves you

If you need an inbox other people can open — shared QA testing, a team checking the same signup flow — a public service like Mailinator is built for that and we are not.

If you need an address that only you can read, check whether your inbox is private before trusting any service with a password reset link. It is the one property in this whole field that is hard to reverse once you have got it wrong.

Measured 24 September 2026 from a single request per service. Method above; corrections welcome.