Plain Text vs Rich Text in Apple Mail: When to Switch

Apple Mail lets you write in one of two composition formats: plain text or rich text. Rich text is the default on a new install, which is why most people never think about the setting — until a stranger replies asking why your signature came through as jagged HTML, or a mailing list bounces the message, or a quoted reply doubles up on formatting that neither side wrote.

This is a walkthrough for Apple Mail on macOS, verified in August 2026 on current macOS Sequoia builds. It covers the single-message shortcut, the app-wide default, how to paste text without dragging formatting in with it, and the real question — when plain text is the professional choice rather than a purist habit, and when rich text is the correct one.

The verdict up front#

Use plain text when the message must render the same for every recipient, when you are pasting from a formatted source, or when the mail is going to a list or a stranger who might be reading in a lightweight client. Use rich text for internal mail where a branded signature, a coloured header, or an inline screenshot is part of the message.

For a single message, the fastest switch inside a compose window is Shift-Command-T. That toggles the current draft between rich and plain text without touching the app default. The menu equivalent is Format > Make Plain Text (or Make Rich Text, depending on the current mode).

To make plain text the default for every new message, open Mail > Settings > Composing and set Message Format to Plain Text. New drafts start plain; replies inherit the format of the message you are replying to unless you toggle it. That last detail is the one people miss: even with plain text as the default, replying to a rich-text sender opens a rich-text draft.

At a glance: plain text vs rich text in Apple Mail#

The dimensions below are the ones that actually change the outcome for a recipient. Draft speed and menu layout do not — both formats compose at the same speed in the same window.

Where plain text wins#

If you finish this section and it describes the mail you send most days, plain text is the correct default and Shift-Command-T is the only shortcut you need for the rest.

Rendering fidelity for strangers. A cold email that will be read by someone you have never met, on a mail client you cannot predict, has one job at the render layer: look the same on their screen as it did on yours. Plain text does that automatically. Rich text depends on their client's HTML renderer, their dark mode, their inherited font stack, and whether their filters stripped an inline image. Every HTML dependency is a chance for the mail to land looking slightly off — and slightly off, at the top of a cold recipient's inbox, is enough to bin it.

Mailing lists and technical audiences. Many software mailing lists, patch trackers and open-source project inboxes reject HTML mail outright or silently strip it, leaving the quoted reply mangled. Kernel-adjacent lists, GNU projects, and most Bugzilla-style trackers still recommend plain text explicitly. If you are emailing anyone who lives in a terminal, plain text is the polite default and the one they will read.

Pasted formatting from browsers and docs. Copying a paragraph from Notion, Google Docs, a webpage or Microsoft Word into a rich-text Apple Mail draft drags the source's fonts, sizes and colours in with it. The reader gets Helvetica, then Aptos, then Menlo in the same paragraph, and it reads as sloppy even when the writing is good. In a plain-text draft, everything you paste becomes flat text automatically — no cleanup needed. In a rich-text draft, use Edit > Paste and Match Style (Shift-Option-Command-V) to strip formatting before it lands.

Cold outreach that has to feel personal. A message with a designed HTML signature, coloured headers and image blocks reads as a marketing send whether you meant it to or not. Plain text with a short text signature reads as a person sat down to write. This is not a stylistic preference — recipients pattern-match on HTML weight, and the pattern for cold mail from a stranger that looks like marketing is delete.

Where rich text wins#

Rich text is not a lesser format. It is the correct format when the message contains information that plain text cannot carry, and switching a message that needed rich text to plain flattens content the reader was supposed to see.

Branded signatures and internal identity. If your organisation has a signature block with a logo, brand colours, or a divider line, plain text strips it to bare text and drops the logo entirely. For internal mail, formal external correspondence, or any message where the signature does real work — legal disclaimers, licensed-professional identifiers, contact cards — rich text is what carries it. Switching to plain text here erases the block you were told to include.

Inline screenshots and images. A screenshot pasted into a rich-text draft embeds as an inline image the recipient sees in-line with the text. In plain text, the paste is silently discarded and the reader is left reading around a hole in the argument. Bug reports, design reviews and support replies that reference a screen state genuinely need rich text — the image is the message.

Emphasis that matters. Bold, italic and hyperlinked text render across every modern client, and for internal mail where a single word or a URL is the point, that emphasis lands. Plain text can approximate emphasis with asterisks and inline URLs, and often that is fine, but if the message will be read on mobile alongside twenty branded internal newsletters, plaintext looks like a delivery failure to eyes that expect the org's usual format.

Newsletters and multi-section internal announcements. A weekly team roundup with a header, section dividers and a call-to-action button is a rich-text document. If you sent that same content as plain text — as an unstructured wall of paragraphs — the reader would not know where each section starts, and the structure that made it scannable would be gone.

The cost model — for you, for the recipient, for Apple Mail#

Apple Mail is bundled with macOS at no additional charge, and both composition formats are included with it. There is no upgrade tier that unlocks either one, no per-message cost, and no packaging shape to check on a vendor pricing page. The cost of a format choice sits somewhere else — in the render on the recipient's screen and in your own time cleaning up messages that shipped in the wrong format.

The cost of choosing plain text is a signature that reads as bare text, a screenshot you have to attach separately if the message needed one, and emphasis that has to be phrased instead of styled. That is not zero; if the message genuinely needed a logo or an inline image, plain text loses it.

The cost of choosing rich text is variable render fidelity, larger message sizes, higher chances of tripping spam filters on cold sends, and pasted junk formatting from browsers and docs that you have to strip manually. If the message is going to strangers or a mailing list, that cost lands on their end as ugly rendering, which lands on your end as unread mail.

There is no dominant format. There is a match between the message and the audience, and the setting you want in Apple Mail is the one that makes it easy to switch when the match changes — which is what the Shift-Command-T shortcut is for.

Who each format is genuinely for#

The audience decides this more than the sender does. Feature grids do not.

A third option, honestly#

AI Emaily is a native AI email client, not Apple Mail, and it is not a fix for the plain-text-versus-rich-text question inside Apple Mail. If you use Apple Mail and want format discipline, the shortcuts and settings above are the whole answer — switching clients over one composition setting would be a bad trade. We build AI Emaily, so we are naming that limit before we name the case where AI Emaily is the adjacent thing worth considering.

The case: if the reason you keep reaching for Shift-Command-T is that a real share of your day is written outreach at volume — cold messages that need plain, internal notes that need rich, replies inheriting whatever the sender used — format toggling is a symptom of a different problem, which is that composition itself is manual. AI Emaily's Composer generates drafts against a Personal Context brain and per-client profiles you configure; approval-before-send in Copilot mode means every draft is one you actually read before it leaves. Formats are still a choice at send time; you just make fewer of them, because the drafts land in the shape the profile calls for.

The honest concession: Apple Mail beats us on native-toolkit macOS integration. Every system Services menu item, every macOS-level format command, and every OS-level dictation and text feature is available in Apple Mail because it is a Swift app that lives inside the platform. Our downloadable Mac app is an Electron shell on our web codebase — real Dock presence, real system notifications, features that land the same day as web, but not native-toolkit parity. If native macOS integration is why you use Apple Mail, keep using Apple Mail — that is the correct answer, and our comparison against a native Swift client would concede this dimension every time.

AI Emaily connects Gmail, Outlook and standard IMAP. It does not read your Apple Mail local archive. Packaging is a 7-day free trial on Pro and Autopilot plans — card required, $0 if you cancel before day 7 — rather than a permanent free tier. Current pricing is at aiemaily.com/pricing.