Why JMAP?

JMAP is simpler than IMAP

JMAP’s layered design delegates complexity to existing components:

• HTTP handles transport security, compression, multiplexing, and authorisation via standard headers
• JSON handles encoding, eliminating the need for a custom parser (IMAP and SMTP both require complex bespoke parsers, CardDAV and CalDAV require this and also wrap it in XML…)
• Core JMAP defines a small standard set of methods — /get, /set, /query, /changes — that work consistently across all data types
• Application specs (e.g., JMAP for Mail) define only the data types and semantics

The JMAP core and mail specifications together total just 51,000 words — less than one fifth the size of the IMAP specification set. A simpler protocol that uses existing infrastructure means software development is easier and cheaper, and more attention can be spent on performance, security, and bug fixing.

During testing, a large number of bugs were encountered in every major IMAP client. Many of these bugs would likely have been prevented with a simpler protocol.

Easier to deploy and manage

Because JMAP is based on HTTP, deploying, securing, and scaling JMAP is much simpler than traditional email service endpoints. JMAP deployments can use all existing HTTP infrastructure:

• TLS termination via NGINX, Caddy, or any reverse proxy — no special IMAP-aware configuration
• Load balancing at the HTTP request level (impossible with IMAP’s stateful TCP connections)
• DDoS protection via Cloudflare and similar services
• Monitoring and logging using the same tools as the rest of your HTTP infrastructure
• Compression via your HTTP proxy — no mail server code changes needed. IMAP requires explicit RFC 4978 support in the server, and doesn’t support modern, more performant compression algorithms.

Many organisations also deploy corporate proxies and firewalls that block outgoing TCP connections on unexpected ports. HTTP is almost always allowed. JMAP works anywhere HTTP works.

More features, built in

JMAP adds support for many features that are either missing or require fragile extension support in IMAP. Every conformant JMAP server must support all of these:

With IMAP, clients must support many different code paths depending on which extensions a server happens to support. With JMAP, all users get the same complete feature set.

Better performance

JMAP is more efficient than IMAP, sometimes drastically so, particularly in common scenarios where IMAP clients and servers don’t implement the necessary IMAP extensions.

Resync after restart

When a mail client is closed and reopened, it must synchronise with the server. This test measured bandwidth consumed when restarting the mail client with 28,234 messages in the account:

Without CONDSTORE and QRESYNC support, IMAP clients must query the read/unread flags on every message in the user’s entire mailbox at startup. This scales linearly with inbox size. Thunderbird repeats this query every time the selected mailbox changes.

Attachment handling

IMAP and SMTP have a significant write amplification problem when sending email with attachments. In testing, composing and sending a 20 MB attachment in Outlook required 155 MB of total bandwidth — the attachment was uploaded to the server 5 separate times (draft auto-save, subject line edit, send, copy to Sent, SMTP delivery). If the draft had been edited for longer, with more auto-saves, it would have been even worse.

With JMAP, attachments are uploaded once. Forwarding an email with an attachment requires no download at all — the blob ID is simply copied into the new message.

Improved battery life

Battery testing showed a 2–3× reduction in battery usage when switching to JMAP. The dominant factor is push notifications: IMAP without proper push support requires the device radio to wake periodically to poll the server, which is a significant battery drain.

Webmail support

IMAP cannot be used for webmail — it runs on raw TCP sockets not available to browsers. Every webmail provider (e.g., Gmail, iCloud Mail, Outlook.com) maintains a bespoke HTTP API service alongside their IMAP infrastructure. This is expensive to design, build, and maintain.

Because JMAP runs over HTTP, JMAP can be used directly by webmail clients. The Fastmail web client is built directly on Fastmail’s public JMAP API — including full offline support, keeping the local database up to date via JMAP’s standard /changes feed.

In an experiment, Claude Code (Opus 4.6) was prompted to write a generic standalone JMAP webmail client — able to work with any JMAP server — with access only to the JMAP Core and Mail specifications. In about 30 minutes of prompting, it generated a working JMAP client in 2,100 lines of Rust with inbox, thread view, multiple mailboxes, compose, and send.

Simpler setup

One protocol for sending and receiving mail (not to mention syncing contacts and calendars) is a huge win for usability. Email providers see a lot of support tickets where users can receive but not send, or vice versa, because one of these is misconfigured. This is always very confusing for regular users.