.png&w=384&q=75)
We run our HRM automation on n8n — interview invitations, offer letters, rejection emails. The workflows look clean: a candidate moves to the right stage, a Code node builds the message, a Send Email node fires. During a recent debugging session we hit three separate email bugs in a single afternoon. Each one silently succeeded in n8n's green-node view while producing a broken result for the recipient.
Here is what caused each one and the exact fix.
Bug 1: HTML Tags Rendering as Plain Text
The interview invitation was arriving with the full HTML structure visible as literal characters — <p>Dear Candidate,</p> rendered as-is in the email body. The workflow was completing without errors. The Send Email node showed no warnings.
The root cause was a single node configuration decision. n8n's Send Email node has two separate body fields: Text and HTML. We were passing HTML-formatted content into the Text field. Most email clients render the content type the server declares — plain text stays plain, so every tag became visible.
The fix was moving the HTML string to the HTML field and keeping a simple fallback in the Text field for clients that strip HTML. One field change, no code changes, no workflow restructuring.
The lesson here is that n8n's node configuration is more specific than it looks. The field labels are not interchangeable descriptions of the same input — they map to different MIME parts in the outgoing message. Passing HTML to the wrong part produces exactly this result, and the workflow gives no indication that anything went wrong.
Bug 2: Gmail Hiding the Message Behind "..."
After fixing the HTML rendering, a second issue surfaced: Gmail was showing only the greeting line and then collapsing the rest of the message behind the three-dot expansion button. The email was arriving complete — Gmail was choosing to hide it.
Gmail clips messages that have a blank line immediately after the opening greeting. We were building the email body with a double newline between the salutation and the first line of content. That blank line is what triggers the collapse behavior.
The deeper problem was how we were generating that newline. Inside an n8n expression, writing inside a JavaScript string seems like it should produce a newline character. In practice, n8n's expression evaluator processes the JSON-encoded string and decodes as a literal newline character — which is invalid syntax inside a single-quoted JavaScript string literal. The expression throws an "invalid syntax" error, which pushed us toward a Code node. But the Code node was still producing the blank line that caused clipping.
The fix was building the email body as an array of lines and joining them with String.fromCharCode(10) — a single newline between every paragraph, no blank lines anywhere in the body. The Gmail clipping stopped immediately.
This is a pattern worth knowing: if you are building multiline strings in n8n Code nodes that will end up in email bodies, use String.fromCharCode(10) as your line separator and be deliberate about where blank lines appear. Gmail's clipping behavior is not well-documented, but the blank-line-after-greeting trigger is consistent across tested clients.
Bug 3: PDF Attachment Silently Dropped
The offer letter workflow generates a DOCX from a template, converts it to PDF using a LibreOffice sidecar, and sends the result as an attachment. We added a Code node between the PDF conversion step and the Send Email node to build a structured subject and body dynamically.
After the change, offer letters were arriving with no attachment. The workflow was completing cleanly. The Send Email node showed no error. The PDF simply was not there.
In n8n, binary data — file attachments, images, generated documents — is carried in a separate binary key on the item object alongside the json key. When a Code node returns [{ json: {...} }] without explicitly passing the binary key through, n8n drops the binary data entirely. The Code node is not doing anything wrong by its own logic — it returns what you told it to return. But the binary attachment from the previous node is gone.
The fix was one line: return binary: $input.item.binary alongside the json payload in the Code node output. The PDF started arriving in every offer letter immediately.
This is easy to miss because Code nodes that transform JSON data never need to touch the binary key. The habit of returning only the json object is correct for almost every use case — until a Code node sits in the middle of a pipeline that carries binary attachments. At that point, the passthrough has to be explicit.
What These Three Bugs Have in Common
All three bugs shared the same pattern: n8n reported a successful workflow execution while the output was broken. The emails sent, the nodes turned green, the execution logs showed no errors. The problem only appeared when a human opened the received email.
This is a property of how n8n validates execution — it confirms that nodes ran without throwing, not that the output matched the intent. For email workflows in particular, it means the only reliable verification is actually receiving and inspecting the email. We added a test address to every email node that fires during development, so each workflow run produces a real deliverable we can inspect rather than inferring correctness from green nodes alone.
The three fixes required no new workflow structure, no additional nodes, and no API changes. They required understanding how n8n handles the internals: MIME part selection in Send Email, expression parsing behavior in Code nodes, and binary data passthrough between nodes. Those internals are not prominent in the documentation, but they are the layer where email automation actually breaks.