Employed AI to explain why this feature is urgently needed to hopefully get this request needed attention and implementation.

[CRITICAL] Rich Text Email is Inherently Insecure: "Plain Text Default" for ALL Senders Implementation is Critically Needed

The Fundamental Flaw: Email was built in 1971 on a protocol (SMTP) designed for trust, not security. It assumes the sender is honest and the path is safe. In 2026, this 55-year-old assumption is catastrophically obsolete. Rich text (HTML) email layers a complex, modern rendering engine on top of this insecure foundation, creating a massive, unavoidable attack surface. The issue is not just "bad actors"; the issue is the medium itself. Every HTML email, regardless of sender, carries inherent risks that plain text physically eliminates.

Why Rich Text is Simply Insecure (The Data):

The Rendering Engine is the Vulnerability: To display rich text, your email client must act like a web browser, executing complex HTML and CSS code. This creates a direct path for Zero-Click Exploits. Recent critical vulnerabilities like CVE-2025-36918 (MSHTML) and CVE-2026-42897 (Exchange/OWA) allow attackers to execute arbitrary code simply by the email being rendered, with no click required. Plain text mode disables this rendering engine entirely, making such exploits physically impossible.

AI Has Industrialized Deception: As of July 2026, 82.6% of all phishing emails are AI-generated. These are not poorly spelled spam; they are grammatically perfect and contextually aware. Crucially, AI-generated rich text emails achieve a 54% click-through rate (vs. 12% for plain text) because they use HTML/CSS to create visual urgency (fake buttons, cloned branding). The format itself is the weapon.
Invisible Surveillance is Ubiquitous: Approximately 68% of all commercial emails contain invisible tracking pixels. These 1x1 images load automatically in rich text mode, leaking your IP address, device fingerprint, location, and read habits to third parties. This happens even with "known" senders whose accounts may be compromised or who use aggressive marketing tools. Plain text prevents any remote content from loading, guaranteeing anonymity.

AI Prompt Injection via Hidden Layers: A growing 2026 threat involves hiding invisible text (white-on-white) within rich HTML to manipulate AI email summarizers (like Copilot) into marking malicious emails as "safe." This "prompt injection" exploits the gap between what you see and what the AI reads. Plain text strips all hidden layers, ensuring data integrity for both humans and AI agents.

Trusted Senders Are Not Safe: The idea that "known senders" are safe is a dangerous myth. Accounts are constantly compromised (Vendor Email Compromise rose 66% in 2024). When a trusted contact is hijacked, their rich text emails bypass spam filters and exploit your trust. The format (HTML) allows the attacker to inject fake invoices or urgent requests that look legitimate. Security must be based on content verification, not sender reputation.

The Solution: "Plain Text Default" for Everyone We urgently request a "Secure Plain Text Default" mode that treats all incoming emails as potentially hostile, regardless of origin:

Default to Plain Text for ALL Emails: Automatically strip HTML, CSS, and remote images from every single incoming message. This neutralizes rendering exploits, tracking pixels, and hidden injection attacks at the source.

Per-Message "Load Rich Text" Toggle: Provide a prominent "Load Rich Text" button for users to manually enable rendering on a per-email basis only when absolutely necessary (e.g., complex invoices). This forces a conscious security decision.

Safe Attachment Handling: Ensure attachments (PDFs, docs) remain accessible via a sandboxed viewer even in plain text mode, as the risk lies in the HTML body/scripts, not the attachment file itself.

Conclusion: Rich text email is a legacy liability in a 2026 threat landscape defined by AI automation and zero-click exploits. The 1971 trust model is broken; code execution via email rendering is the new normal. A "Plain Text Default" is not a regression; it is the only logical defense against a protocol that was never designed to be safe.

Please urgently prioritize these critically needed feature to align Proton Mail with the reality of modern cybersecurity.

10 years since this suggestion. Is there really no progress?

As Fastmail does it would be great, fast and cuts out all the rubbish

I am a web developer and need this feature to be able to send and recieve plaintext HTML code.

This is something to be implemented. Thunderbird client allows this already.

Is there an explanation why the developers ignore this incredibly important safety feature?

Echoing the comments shown below. The ability to view email messages lin plain text format is a critical feature when dealing with potentially suspect content.

Proton Mail is a great tool. Please implement this feature to make it even better.

Thanks...

Much need in the Android app at least, use cases:

- some people somehow like to send emails typed in a fancy cursive font, reduced to a tiny and unreadable size in Android (had to copy and paste in my notes app to read it)

- some html newletters are incorrectly displayed in dark mode when a colored background is applied in the email embedded html, i.e. text switches to white because of dark mode, but an html yellow background is left unchanged

it's 2023, and no progress on this?

If I could +10, I would, so have the maximum 3 instead.

This is an absolute "must have" in my opinion, having moved over to a Proton Ultimate subscription I'm really surprised there is no support for this in Proton. With all the tracking crap in emails now-a-days it doesn't seem analogous with a privacy-focused service.

I'd be perfectly happy weathering some discomfort in reading a poorly formatted text email over having HTML emails, as other users have mentioned it can be distracting, annoying, and just plain unwanted. Just give me the message content, I don't need (or want) the sparkles.

Many thanks

How is this not an option?

Would this not negate the need for "tracker protection"?

Same I would love to able to read emails with plain text as a user default option, so it can enforce my theme.
And a toggle per email to switch to html/text if needed.

Would love an option to read emails in plain text, forcing html to be plain text. Plus make it an option that can be set as a user default as well.

I Second @morgan, @TU request. javascript will render when veiweing an html email with embedded javascript. Even images can be crafted to subvert image redering libraries. The receiving protonmail user need not even click on any link, but get infected, identity stolen, cross-site-scripting, etc just by rendering html w/javascript or images.

I would like to have an option so that by DEFAULT all composed email will be composed as plain text. At the moment I have to click on plain text every single time because everyone sends me HTML emails but I never want to reply with an HTML email ever. It's really annoying to do this all the time.

And then I want the same for incoming email: It should be stripped down to text by DEFAULT when the option in settings is activated on both the web app and the mobile native app because all this HTML email that is difficult to read on various screen sizes is really annoying.

HTML emails, they have: complicated layouts, can contain adverts and are worse for readability. Is it possible to automatically convert an inbound HTML email to plain text, containing the message text without any of the additional formatting etc? I hope other people beside myself would appreciate this, to make life a little easier. Thank you.

I still can't believe there is not an option to both read email in text mode and force email reply to txt mode

In addition to the security issues with HTML email...I also really dislike dealing with HTML email. It's ugly, distracting, and difficult to read when covered in must-load images.

Plain text for received messages, is a protection
please provide it.

We have composer plain text can we have a receiver plain text? Html is evil