Mailpit vs MailHog: Which Should You Use in 2026?
A head-to-head comparison of Mailpit and MailHog for local email testing. Features, performance, Docker setup, API compatibility, and migration guide.
MailHog was the default local email testing tool for years. Mailpit is its modern replacement. If you're deciding between the two — or planning a migration — here's everything you need to know.
Use Mailpit. It's faster, actively maintained, and a drop-in replacement for MailHog (same ports, compatible API). MailHog hasn't been updated since 2020.
If you want zero-install local testing with a path to production, consider SendPigeon CLI instead.
Side-by-side comparison
| MailHog | Mailpit | |
|---|---|---|
| Last update | 2020 | Active (weekly releases) |
| Language | Go | Go |
| SMTP port | 1025 | 1025 |
| Web UI port | 8025 | 8025 |
| Search | Basic (regex on some fields) | Full-text search |
| Email tagging | No | Yes |
| Link checking | No | Yes |
| HTML/text/source view | Yes | Yes + syntax highlighting |
| API | Custom | MailHog-compatible + extended |
| TLS support | No | Yes (STARTTLS + SMTPS) |
| Message size limit | Hardcoded | Configurable |
| Storage | In-memory or MongoDB | In-memory or SQLite |
| Docker image size | ~40 MB | ~20 MB |
| Open issues | 100+ (unresponsive) | Actively triaged |
Installation
MailHog
# Docker
docker run -p 1025:1025 -p 8025:8025 mailhog/mailhog
# Go install (requires Go)
go install github.com/mailhog/MailHog@latest
Mailpit
# macOS
brew install mailpit
# Docker
docker run -p 1025:1025 -p 8025:8025 axllent/mailpit
# Or download a binary from GitHub releases
Both use the same ports by default, so you can literally swap one for the other in your docker-compose.yml.
Docker Compose comparison
MailHog
services:
mailhog:
image: mailhog/mailhog
ports:
- "1025:1025"
- "8025:8025"
Mailpit
services:
mailpit:
image: axllent/mailpit
ports:
- "1025:1025"
- "8025:8025"
The migration is a one-line image name change.
Features MailHog is missing
Since MailHog stopped development in 2020, it lacks:
- Full-text search — MailHog can only filter by basic regex on limited fields. Mailpit searches across subject, body, recipients, and headers.
- Email tagging — Mailpit lets you tag and organize captured emails, useful when testing multiple flows.
- Link checking — Mailpit validates links in captured emails, catching broken URLs before they reach users.
- TLS/STARTTLS — MailHog has no TLS support. Mailpit supports STARTTLS and SMTPS for apps that require encrypted SMTP.
- Configurable limits — MailHog has hardcoded message size limits. Mailpit lets you configure max message size, retention, and storage backend.
- Security patches — Six years of unpatched dependencies.
API compatibility
Mailpit includes a MailHog-compatible API at the same endpoints, so scripts that call the MailHog API generally work without changes:
# Works with both MailHog and Mailpit
curl http://localhost:8025/api/v2/messages
Mailpit also has an extended API with additional endpoints for search, tags, and message management.
Performance
Mailpit is significantly faster than MailHog:
- SMTP throughput — Mailpit can ingest 100–200 emails per second over SMTP, well beyond what MailHog handles
- Web UI — Noticeably faster rendering, especially with hundreds of messages
- Memory usage — Lower baseline, plus SQLite storage option prevents memory from growing unbounded
- Docker image — Roughly half the size of MailHog's image
For most local dev work the performance difference doesn't matter. But if you're running email tests in CI or capturing high volumes, Mailpit handles it better.
When to use neither
Both Mailpit and MailHog are local-only dev tools. They catch emails, but they don't send them. When you go to production, you'll need a separate email service — and separate code to integrate it.
SendPigeon CLI gives you local email capture (like Mailpit) plus a production sending path through the same SDK:
# Local dev — catches emails at localhost:4100
npx @sendpigeon-sdk/cli dev
import { SendPigeon } from "sendpigeon";
const pigeon = new SendPigeon("sp_test_xxx");
// Dev mode → caught locally
// Production → sent via SendPigeon API
await pigeon.send({
from: "hello@yourdomain.com",
to: "user@example.com",
subject: "Welcome!",
html: "<h1>Welcome!</h1>",
});
No code changes between dev and production. Set SENDPIGEON_DEV=true for local capture, remove it to send real emails.
Get started with SendPigeon CLI
Migration checklist: MailHog → Mailpit
- Swap the Docker image —
mailhog/mailhog→axllent/mailpit(ports stay the same) - Test your SMTP config — Should work without changes (same default ports)
- Test API scripts — Mailpit's MailHog-compatible API covers most use cases
- Update CI configs — Same image swap as step 1
- Remove MailHog-specific workarounds — If you had hacks for missing search or TLS, Mailpit handles these natively
FAQ
Is Mailpit a fork of MailHog?
No. Mailpit is a separate project written from scratch in Go. It uses the same default ports and offers a MailHog-compatible API, making it a drop-in replacement — but it's not based on MailHog's code.
Can I switch from MailHog to Mailpit without changing my config?
In most cases, yes. Mailpit uses the same default SMTP port (1025) and web UI port (8025). It also has a MailHog-compatible API endpoint, so most automation scripts work without changes.
Is MailHog still safe to use?
MailHog still functions for basic SMTP capture, but it hasn't received security patches since 2020. For local-only development this is low risk, but it's not recommended for shared or CI environments.
Which is faster, Mailpit or MailHog?
Mailpit. It can ingest 100–200 emails per second over SMTP, and the web UI is noticeably faster with large mailboxes.
Related
- 7 Best MailHog Alternatives for 2026 — Full comparison of all alternatives
- Best Mailpit Alternatives for 2026 — If Mailpit doesn't fit your needs
- Local Email Testing Without Docker — Zero-install approach with SendPigeon CLI
- Email Sandbox Testing — Compare sandbox approaches for dev, CI, and staging