Email marketing

Email marketing

Email marketing

Web templating in email marketing: what it is and how it works

Joey Lee

September 5, 2025

Web templating may sound like a developer’s tool, but email marketers use it every day without realizing it. The syntax your email service provider (ESP) supports determines how far you can go with personalization, automation, and dynamic content. In this article, we’ll break down the most common templating languages across major ESPs, from simple merge tags to advanced frameworks, so you can see which ones fit your team’s needs best and get a better understanding of the robustness of certain platforms.

Web templating languages in email marketing

If you have ever dropped *|FNAME|* into Mailchimp or {{ first_name }} into an ESP, you have written templating language. Web templating powers most modern websites, and email service providers borrow the same idea to personalize messages at send time. It is a great fit for email because templates are safe, fast, and expressive: you write one message with variables and simple logic, and the ESP renders a custom version for every recipient. Shopify’s Liquid docs sum it up well: web templating language dynamically inserts data where it is rendered.

What is a templating engine?

A templating engine is a tiny programming language designed for rendering text. You get placeholders for variables, control flow like if and for, and a toolbox of filters or helpers to format data. Engines are intentionally limited compared to full programming languages, which makes them safer for marketers and faster for ESPs to execute at scale. Popular engines include Liquid, Handlebars, Jinja, and the Django template language.

Why ESPs use templating
  • Separation of content and data. Marketers write copy once; the ESP injects profile, event, or catalog data at send time.

  • Safe, constrained logic. Engines expose only what is needed for personalization and layout, so templates remain secure and maintainable.

  • Performance at scale. Rendering lightweight template code is cheaper than running custom scripts for every recipient.

The engines at a glance

To make sense of how these languages stack up, it helps to compare their core features side by side. The table below shows which engines support variables, conditionals, loops, filters or helpers, partials, and template inheritance, along with a few notes on how they’re commonly used.


engine

variables

if

loops

filters or helpers

partials/
includes

template inheritance

notes

Liquid

✔ filters

✔ via render

widely used in ESPs and ecommerce; render supersedes include

Handlebars

#if

#each

✔ helpers

✔ partials

HTML escaping by default with {{ }}; {{{ }}} outputs unescaped

Jinja

✔ filters + tests

include

extends

macros and rich control flow

Django template language

✔ filters

include

extends

used by Klaviyo with Django-style tags and filters

AMPscript (SFMC)

n/a filters, rich functions

✔ include content blocks

n/a

scripting language, not a template engine; pairs with personalization strings like %%FirstName%%

Mailchimp merge tags

✔ conditional tags

◐ RSS-only loops

limited functions

simple merge and conditional blocks such as `*

ESP by ESP: What they use and why it matters
Iterable

Iterable implements Handlebars. You get variables, blocks like #if and #each, and a large library of helpers for text, math, dates, and arrays. Iterable’s docs also call out differences from upstream Handlebars and show where you can use snippets as reusable partials.

Customer.io

Customer.io uses Liquid throughout the product, with an extensive tag and filter list and UI support for inserting objects and previewing personalization.

Braze

Braze also uses Liquid. You can pull user attributes into messages, add conditionals, run loops, and format data with filters like dates. Braze also documents common Liquid patterns for campaigns.

Simon Data

Simon Data’s “custom context engine” is powered by Jinja2. That means you get full Jinja features like filters, tests, macros, includes, and template inheritance.

Bloomreach 

Bloomreach uses Jinja for personalization, with docs that cover syntax, blocks, and reusable snippets or macros.

Attentive

Attentive uses Liquid for email. You can use variables plus if/else and for in templates. Their help center also explains how they handle errors in Liquid code.

Klaviyo

Klaviyo’s message templating uses the Django template language. You can write {% if %} blocks, {% for %} loops, and apply Django filters like default or floatformat alongside Klaviyo-specific tags for unsubscribe and web-view links.

Salesforce Marketing Cloud

SFMC supports basic personalization strings such as %%FirstName%% and a powerful scripting language called AMPscript for conditionals, data lookups, math, HTTP calls, and content includes. AMPscript is how teams handle complex personalization beyond simple merge fields.

How the syntaxes feel in practice
  • Mailchimp merge tags. Perfect for simple personalization and a few conditional blocks. Minimal surface area, quick to teach, and hard to break. Mailchimp also supports conditional tag blocks when you need it.

  • Liquid. Friendly and readable with {{ variable }} and {% if %}. Good balance of power and safety, which is why you see it in Braze, Customer.io, and Attentive.

  • Handlebars. Logic happens via helpers, which keeps templates tidy. Iterable exposes many built-in helpers for real world tasks.

  • Jinja and Django template language. Full-featured templating with inheritance, macros, tests, and powerful filters. Best for teams with developer support or complex rendering needs. Used by Simon Data, Bloomreach, and Klaviyo. It is the most powerful syntax.

  • AMPScript/SFMC. Salesforce Marketing Cloud gives you two levels of templating. At the basic level you can use personalization strings like %%FirstName%% for quick merges. When you need more advanced personalization you move into AMPscript, which supports logic, data lookups, and content blocks. AMPscript is powerful but can feel clunky compared to newer engines like Jinja or Liquid. It was built before these languages became popular, so the syntax is less intuitive even though it gets the job done.

Choosing an ESP through the lens of web templating
  • You have basic needs. If your personalization is light and your team is mostly marketers, a simple syntax is best. Mailchimp’s merge tags or an ESP with Liquid used sparingly will keep velocity high and the risk low.

  • You have complex needs. If you plan to render product grids, events, localize copy, or share base layouts, pick an ESP whose language developers love and that has deep documentation. Jinja or Django-based systems and Handlebars with robust helpers are great fits. For SFMC, plan on AMPscript expertise.

Quick reference examples

Want to get a feel for what the syntax looks like system to system? Here are some snippets that show how different templating languages handle variables, conditionals, and loops.


Liquid

{% if user.tier == 'VIP' %}
  Hi {{ user.first_name | default: 'there' }} enjoy {{ discount | round }}% off
{% endif %}

Handlebars

{{#if firstName}}Hi {{firstName}}{{else}}Hi there{{/if}}
{{#each cart.items}}{{name}} × {{qty}}{{/each}}

Jinja or django

{% if firstName %} Hi {{ firstName }} {% else %} Hi there {% endif %}
{% for item in cart %} {{ item.name }} × {{ item.qty }}{% endfor %}

Mailchimp conditional block

*|IF:FNAME|*Hi *|FNAME|**|ELSE:|*Hi there*|END:IF

AMPscript

%%[ IF NOT EMPTY(FirstName) THEN ]%%
  Hi %%=ProperCase(FirstName)=%%
%%[ ELSE ]%%
  Hi there
%%[ ENDIF ]

The bottom line

Templating is the quiet engine behind modern personalization. When you compare ESPs, look past the drag and drop editor and check the language under the hood. If your needs are simple, pick a platform with a minimal syntax and keep moving. If your needs are complex, choose an ESP whose templating engine is robust, well documented, and pleasant for developers to use. That choice will pay for itself every time you ship another dynamic campaign.