Hey there!
I’m building an end-to-end ticketing automation for a local festival: it reads a Google Sheets database, runs some parsing/logic, and emails each buyer a QR code, the brand logo, and some text via a connected corporate SMTP address.
My concern: the email has two images, the brand logo (top, in the header) and the QR (below the text). The QR is referenced by expression so it resolves correctly. But if a provider decides to display the text version instead of the HTML, the customer loses the logo and the QR.
For context, the QR is also included as a file attachment, not just inline, so even if rendering fails the buyer still has the QR. But I’d like to understand the HTML/text behavior properly.
Questions:
-
With Email Format: Both, how does n8n actually decide what gets sent: does it send both parts in one message, or pick one?
-
Do all modern providers (Gmail, Yandex, Mail.ru, iCloud) render the HTML part, or is there a real risk some show the text version to customers? - most important
-
Any best practices to guarantee the HTML/QR renders for paying customers?
Thanks!
Hi @Nick_Vieru
When you select the “Both” format in n8n, the system doesn’t pick one version to send; instead, it bundles both the plain-text and the HTML versions into a single email (technically called a multipart/alternative message). Once the email arrives, it is the recipient’s email app—not n8n—that decides which version to show. In almost every case, the app will try to display the HTML version because it is more visually appealing.
For modern providers like Gmail, iCloud, Yandex, and Mail.ru, there is very little risk of a customer seeing only the text version. HTML rendering is the global standard for email. The only time a user would see the text-only version is if they have manually changed their settings to “Plain Text Only” for extreme security or accessibility reasons, or if the email is flagged as high-risk spam by the provider.
Regarding your images, n8n handles inline images using “Content-IDs” (CIDs), which tell the email client to pull a specific attachment and place it inside the HTML body. While this usually works, some corporate clients (like certain versions of Microsoft Outlook) can be finicky and may occasionally strip the inline rendering and simply show the images as traditional attachments at the bottom of the mail.
Since you are already including the QR code as a separate file attachment, you have already implemented the best safety net possible. To further guarantee a professional look, you can add “alt text” to your HTML image tags (e.g., alt="Your Ticket QR Code") so that even if the image doesn’t load, the user knows what is missing. Your current setup is robust and follows industry best practices for critical transactional emails
Thanks! That clears it up and makes it much less worisome for me.
I will add the alt HTML tag to the QR code and the brand logo. Have a good day!