Paste your template. You get it rendered twice — once with a complete recipient record, and once with the fields empty, because some recipients always are.

Three failures, and only one of them is a typo

An unclosed field — {{first_name with no closing brace — is sent literally to everyone. In an editor it looks very nearly right, which is exactly why it survives proofreading. In the preview above it appears unchanged, in red, the way the recipient will read it.

Two syntaxes in one template means a block was pasted in from a template built on another platform. Mailchimp's *|FNAME|* means nothing to a Klaviyo send and vice versa, so one of them goes out raw. This one is almost never a typo — it is a copy-paste.

No fallback is not a syntax problem at all. Hi {{first_name}}, is perfectly valid and produces "Hi ," for every recipient whose record is blank. The second preview above is that email. There are always some.

Why two previews rather than one verdict

A list of findings tells you a rule was broken. Seeing "Hi ," sitting at the top of your own email tells you what it will look like to a customer — and that is the thing that makes people go and add a default.

Where these rules come from

Nowhere official: no email platform publishes a formal grammar for its merge fields. These patterns are the forms in common use — Mailchimp's *|FIELD|*, the {{ }} of Liquid-based platforms, %%FIELD%%, ${field}, [FIELD] — and every rule here is labelled as our own engineering rule rather than dressed up as a standard.

Every check this tool runs (6 rules)

TPL-U01 A merge field is not closed

An opening delimiter with no matching close. The whole fragment is sent literally, so every recipient reads the raw placeholder — and in an editor it looks very nearly right, which is why this survives proofreading.

Fix: Close the delimiter, matching the opening one exactly.

Source: Own engineering rules for merge-field syntax. The delimiters differ by email platform and none of them publishes a formal grammar, so these patterns come from the forms in common use rather than from a specification.

TPL-X01 Two different merge syntaxes in one template

The template mixes delimiter styles — for example Mailchimp’s *|FIELD|* alongside {{field}}. Only one of them belongs to the platform sending the mail; the other is passed through untouched. This nearly always means a block was pasted in from a template built elsewhere.

Fix: Convert everything to the syntax your platform uses.

TPL-F01 No fallback for a personalisation field

A name field with no default produces "Hi ," for every recipient whose record is blank — and there are always some. This is not a syntax error, it is a data one, which is why it shows up only when the send has already gone out.

Fix: Give the field a default, e.g. *|FNAME:there|* or {{ first_name | default: "there" }}.

TPL-C01 Field name looks like a placeholder from the example

Names like first_name, FNAME or customer_name are correct on most platforms — but example templates also ship with names such as YOUR_COMPANY or SAMPLE_TEXT that were meant to be replaced by hand, not merged.

TPL-S01 Spaces inside the delimiters

Some platforms tolerate {{ field }} and some do not. Where they do not, the field is treated as unknown and left as written.

TPL-V01 Merge fields are consistent and closed

One syntax, every delimiter matched.

Own engineering rules. Merge-field delimiters differ by platform and none of them publishes a formal grammar, so these come from the forms in common use.

Email Merge Field Checker

Three failures, and only one of them is a typo

Why two previews rather than one verdict

Where these rules come from

Every check this tool runs (6 rules)

Related tools