n8n Email Parser: Parse Emails and Extract Data to JSON

n8n is one of the easier ways to connect the tools a business already runs: an inbox on one side, a spreadsheet, database, CRM, or Slack channel on the other. The part that trips people up is almost never the connection. It is the email itself. A message arrives as a MIME document with a plain-text body, an HTML body, headers, and sometimes attachments, and turning that into the three or four fields you actually care about is its own small project. This guide walks through how to parse emails in n8n with the built-in nodes, where the work gets fiddly, and when it makes more sense to hand the parsing step off.

How do I parse an email in n8n?

Start with the Email Trigger (IMAP) node, which connects to your mailbox and fires when new mail arrives. Pass the message to a Code node that reads the body and pulls out the fields you want, then send those fields on to whatever node stores them. The trigger handles capture; the Code node handles parsing; the rest of the workflow handles delivery.

That three-step shape (trigger, parse, deliver) is the backbone of nearly every email workflow in n8n. The trigger and delivery steps are quick to set up because they are just node configuration. The parse step in the middle is where you write logic, and how hard it gets depends entirely on how consistent your incoming emails are.

How do I get the email body from the IMAP node in n8n?

The Email Trigger (IMAP) node outputs the message with the body available as fields you reference by expression, typically textPlain for the plain-text version and textHtml for the HTML version. Pick the message format that fits: Resolved returns full data with attachments as binary, RAW returns the body as a base64url string, and Simple returns the message but is not suitable for inline attachments.

For straightforward parsing, read textPlain in a Code node, since it has no markup to strip. If the data you need only exists in the formatted HTML version, for example a table, you will work with textHtml instead and have to deal with the tags, which is where parsing starts to get involved.

How do I extract specific fields from an email body in n8n?

The common approach is a Code node that searches the body for known labels and captures the value after each one. When emails follow a fixed structure, like a web form notification with Name, Email, and Message lines, a few regular expressions return exactly what you need. Here is the pattern most n8n workflows use:

// Code node: pull labeled fields out of the email body
const body = $json.textPlain || '';

const get = (label) => {
  const m = body.match(new RegExp(label + '\\s*:\\s*(.+)', 'i'));
  return m ? m[1].trim() : null;
};

return [{
  json: {
    name:     get('Name'),
    email:    get('Email'),
    order_id: get('Order'),
    total:    get('Total'),
  },
}];

This works well for clean, predictable senders. The moment a sender changes a label, reorders lines, wraps a value across two lines, or sends the data inside an HTML table instead of plain text, the expressions stop matching and you are back in the Code node adjusting patterns.

Can n8n parse email attachments and PDFs?

The IMAP trigger can download attachments and outputs them in the binary section of the node, but downloading a file is not the same as reading the data inside it. To get values out of a PDF or spreadsheet attachment you need an extra step: an Extract From File node for simple text, or an OCR or AI model node for a real invoice or receipt layout. n8n does not pull structured fields out of an attachment on its own.

This is the point where many workflows balloon. A single invoice email can need the trigger, a download step, a file-extraction step, an AI step to read the layout, and then cleanup logic, all before the data is usable. If your attachments are PDFs you also want as spreadsheets, a dedicated PDF to Excel converter handles that side cleanly, but the field-level extraction is still its own task.

Why does my n8n email parsing break when the email format changes?

Because regex in a Code node matches the exact shape of the email you built it against. It keys off specific labels, line positions, and punctuation, so any change to the wording, order, or layout means the pattern no longer finds the value. A vendor tweaks an invoice template or a platform redesigns a notification, and your workflow silently returns null fields.

This is the core maintenance cost of a hand-built parser. It is not that the logic is hard to write the first time; it is that real-world senders change their emails on their own schedule, and every change is a workflow you have to go back and fix. The more sources you parse, the more often something breaks.

How do I extract data from an .eml or .msg file in n8n?

n8n does not include a native MIME parser node, which is a long-standing request in its community, so reading a saved .eml or .msg file inside the workflow means writing custom decoding or calling an outside tool. For a backlog of exported message files, it is usually faster to convert them outside n8n and feed the result back in.

An EML and MSG converter turns a folder of saved messages into clean CSV or JSON in one pass, which you can then import or pipe into your n8n flow. That keeps the file-decoding problem out of your workflow logic entirely.

How do I send parsed email data from n8n to a spreadsheet or database?

Once the parse step returns clean fields, delivery is the easy part. n8n has nodes for Google Sheets, databases, Airtable, CRMs, and Slack, so you map your parsed fields to columns or table rows and the data lands wherever you need it. The output of your Code node or API step flows straight into the destination node.

If the goal is a running spreadsheet, n8n can append a row per email to Google Sheets or you can collect the parsed output and drop it into Excel. The delivery side is rarely the bottleneck; getting clean, reliable fields out of the email is.

Is there a simpler alternative to building an email parser in n8n?

Yes. Instead of maintaining regex in a Code node, call a dedicated parser from an HTTP Request node and let it return structured JSON. You define the fields you want once, in plain language, and the parser reads the body and HTML tables and hands back clean values. Your n8n workflow keeps the trigger and the delivery steps and drops the brittle parsing logic.

This is the same trade-off teams make with other automation platforms, like choosing a parser over expression-based parsing in Power Automate or over the Zapier email parser, whose limits and replacements are set out on the Zapier email parser alternative page. n8n still orchestrates the workflow; the email parser API just handles the one step it does not do well, so a format change becomes a field you rename rather than a workflow that quietly breaks. The n8n email parser page covers how MailParse plugs into that webhook or HTTP Request step. If you are weighing your options, the guide to the best email parser covers what to look for in an accurate, low-maintenance parsing layer.