Every personalized email is a template with gaps in it: a first name, a product the customer last bought, a block that shows only to loyalty members. A templating language is what fills those gaps when the message is sent. The platform decides which language its personalization tools support: Braze and Customer.io use Liquid, Bloomreach Engagement uses Jinja, Salesforce Marketing Cloud uses AMPscript, Iterable uses Handlebars. A marketer can build a message without code, but custom logic is written in the platform’s language. That makes the question a platform question, and buyers treat it as one.
What is the difference between Liquid and Jinja?
Liquid and Jinja are both template languages that personalize a message at send time, inserting customer data, conditional content and items such as product recommendations, and they look almost the same on the page: {{ first_name | capitalize }} prints a value in either, and logic sits inside {% if %} tags in both. Liquid is the open-source language Shopify created, built so that people editing templates cannot run code on the server: it works through a fixed set of objects, tags and filters. Jinja is a Python templating engine whose expressions work much like Python’s, though a Jinja template can reach only the variables and functions the platform exposes to it.
The differences show in the details. Liquid writes {% elsif %} where Jinja writes {% elif %}; Liquid does arithmetic with filters, {{ price | times: 0.9 }}, where Jinja accepts {{ price * 0.9 }} directly; and Jinja adds macros and template inheritance, which standard Liquid does not have. Simple placeholders can carry across unchanged, but conditions, calculations and reusable blocks generally need adapting, and a platform that supports either language may not support all of it.
What the interviews add is where the effort actually lands:
Buyers almost never set the two languages side by side. Liquid comes up from Braze buyers, as something their own marketers write, and in several cases as a reason they like the platform. AMPscript comes up from Salesforce Marketing Cloud buyers, as a skill they have to hire or contract. Jinja comes up from a handful of Bloomreach and Simon Data buyers, and the verdict on it depends on whether the team writing it has developers.
So the useful comparison is not Liquid against Jinja. It is how much of a platform’s personalization lives in code, and who on your team can write that code.
One financial services company put the shared ground plainly while comparing email platforms: “Everybody has an open source templating language. They're all using Liquid or Handlebars or whatever.” Its next sentence is the condition every other buyer on this page is arguing about: “If you have a capable team, which we do, we can code all that stuff and we can make the template dynamic.”
Against AMPscript
AMPscript is Salesforce Marketing Cloud Engagement’s own scripting language, used in email, SMS, mobile messages and landing pages, with Server-Side JavaScript available alongside it. Several buyers name AMPscript and SQL in the same breath, because on those teams the same person writes the queries that build the data and the script that prints it.
Against Handlebars and Django-style tags
Iterable uses Handlebars, which shares the {{ }} output but writes logic as block helpers such as {{#if}}; Iterable’s documentation says it does not support every part of the language. Klaviyo uses the Django template language, whose syntax Jinja’s closely resembles, and supports most of its filters plus some of its own.
Against storefront Liquid
Liquid also runs Shopify storefront themes, and several buyers who mention Liquid in these interviews mean the website, not email. That is a different job, run by web developers rather than email teams. This page is about messaging templates.
Does Bloomreach use Liquid or Jinja?
Jinja. Bloomreach Engagement documents Jinja2, commonly referred to as Jinja, as its personalization language, not Liquid. It supports personalization in email campaigns (body, subject line, sender, pre-header and UTM parameters), weblayers, HTML blocks, scenario actions, experiments and asset templates. Jinja cannot be used everywhere in the product: the same documentation excludes scenario triggers, A/B split operators and surveys, and a placeholder only resolves if the customer value is stored in Bloomreach.
For a team arriving from Braze or Customer.io, that means any logic beyond simple placeholders is adapted to Jinja rather than carried across. A home-furnishings retailer that runs Bloomreach as its email platform credits that flexibility for what it gets out of the platform: “what you can do with like scrappy developers, and we have some of those on my team, where we can do a lot of great work around using Jinja and different types of HTML to get everything we need out there.” How Bloomreach and Marketing Cloud compare more broadly is on Bloomreach vs. Salesforce Marketing Cloud.
Who writes the templates?
On several teams here, someone between a marketer and a developer. In these interviews the people who talk about template code are the lifecycle, CRM and email leads who run the sends, and several describe one person on the team who carries the technical half for everyone else.
A video-game publisher’s email lead describes the role exactly: “I'm the AMPscript expert, I'm the SQL person, and so it's like I'm not developer level, but I'm in between marketer level and developer level.” A parts distributor has built its team around the same split, with an automation specialist it relies on “for some advanced SQL queries and AMPscript to really get into some of that personalization,” and an email coordinator handling list loads and day-to-day sends. On Braze, a fintech’s email lead describes keeping an HTML developer on the team for template questions, and a vendor account manager who learned Liquid to answer the simpler ones.
That middle role is one of the hidden costs of platform personalization. Where marketers can maintain the logic themselves, no separate specialist may be needed; where the work outgrows their skills or the platform’s visual tools, the role becomes a hire, a borrowed engineer or a contract.
Does the templating language matter when choosing an email platform?
Less than who has to write it. Buyers describe four places the work ends up. These are staffing arrangements observed in the interviews, not requirements of the languages:
- Marketers write it themselves
- A technical specialist on the marketing team writes it
- Engineering is borrowed to write it
- An agency or contracted partner writes it
Braze buyers describe Liquid in the first; Marketing Cloud buyers describe AMPscript in the second and the fourth.
Marketers write it themselves
The pattern Braze buyers describe. Liquid appears in their interviews as everyday work, used for loyalty content, replenishment reminders, product recommendations and multi-brand sends, and in several cases as a reason they chose or stayed with the platform. Customer.io buyers describe the same arrangement on the same language.
An online-learning company chose Braze for “the ability to just apply simple HTML and Liquid to the designs as opposed to more proprietary build structures.” A quick-service restaurant chain says its personalization “is sophisticated but also a low level of effort,” and a menswear retailer lists among Braze’s strengths that “it uses liquid HTML.” An insurance software company says of Customer.io’s Liquid: “If data exists in the event payloads or data warehouse, I can reference it dynamically without custom dev work.”
A specialist on the marketing team writes it
The in-between role described above. Buyers on this route rate the language highly for what it can do, and are candid that the rest of the team depends on one or two people to do it.
The video-game publisher calls AMPscript limitless “if you're a JavaScript person or you become an AMPscript person,” and says the platform’s SQL-driven audience tools are hard even for its resident expert, “which means it's nearly impossible for my juniors to use it.” The home-furnishings retailer’s Jinja work on Bloomreach runs on developers it has on its own team.
Engineering is borrowed to write it
When a marketing team lacks the coding skills its templates require, the work moves to engineers who have other jobs. Both buyers on this route were describing Simon Data, a customer-data platform that also sends messages. Its documentation describes templates as HTML combined with Jinja, alongside an optional drag-and-drop email editor; these two buyers describe template work that still needed more technical skill than their teams had. That is a staffing problem, not a sign that every Simon Data customer codes.
An ecommerce retailer rating the platform low says email templates “require a use of a coding called Jinja code. And marketers typically are not developers,” so the team keeps going to its developers, which in the buyer’s words means they “use up engineering capacity just to build simple email templates.” A resale company says “I thought it would be more marketing friendly,” and that Jinja is “not too hard to learn” for people who write SQL, “But our teams weren't SQL proficient.”
An agency or contracted partner writes it
The route buyers describe as a cost of the platform rather than of the campaign. It is a Salesforce Marketing Cloud story in these interviews, and it comes from buyers who like the platform as well as from those leaving it.
A payments company says “because of their complex AMPscript requirements, a company is guaranteed to need third-party support with Marketing Cloud.” The video-game publisher keeps a partner on call for the scripts it cannot write itself: “I have literally two contracts that exist only because Salesforce is complicated.”
The same language can sit on different routes. Jinja sits on route two at the home-furnishings retailer and on route three at the two Simon Data buyers, and a healthcare company’s data team, writing Jinja inside dbt rather than an email platform, calls it “a templating language that was easy to learn.” The language did not change between those accounts. The person writing it did.
One thing is starting to move these routes: AI that writes or repairs the code. A fitness apparel brand says Braze’s AI operator catches template errors — “Anytime a Liquid breaks in the template or there's certain coding that isn't correct, it can identify it and help the team to correct it.” A health insurer says AI on Marketing Cloud “actually helps enable that for some of the less experienced marketing folks who don't have a web development background,” and a grocery retailer is shopping for an email builder that writes Braze’s Liquid for its marketers. These describe help with writing the code, not proof that the specialist role goes away.
Which email platforms use Liquid, Jinja, AMPscript or Handlebars?
Braze and Customer.io use Liquid; Bloomreach Engagement and Simon Data use Jinja; Salesforce Marketing Cloud uses AMPscript; Iterable uses Handlebars; Klaviyo uses the Django template language. These are the languages each vendor’s own documentation names for personalization, checked in November 2026, not necessarily the only way to build a message on the platform, and each platform supports its own subset: Braze, for example, supports Liquid up to and including Liquid 5 and says it supports only certain portions of Shopify’s Liquid.
Liquid
Braze · Customer.io
Also Shopify, for storefront themes rather than email.
Jinja
Bloomreach Engagement · Simon Data
Also dbt, for data models rather than messages.
AMPscript
Salesforce Marketing Cloud Engagement
With Server-Side JavaScript and SQL queries alongside.
Handlebars and Django-style tags
Iterable (Handlebars) · Klaviyo (Django template language)
A buyer’s own label is not always a reliable guide to which group a platform sits in. The fitness apparel brand calls Liquid “Braze's own sort of coding”; it is Shopify’s open-source language, which is why the same syntax works in Customer.io and on a Shopify storefront. Customer.io’s documentation adds a version detail worth checking on an older account: accounts created on or after November 28, 2023 use its latest Liquid version, and earlier accounts are on a legacy one they can upgrade.
Customer.io buyers disagree about how forgiving its Liquid is. The insurance software company above values reaching raw event data directly; an edtech company comparing it with Braze says “there are also behaviors that are really hard to predict, how certain Liquid code is going to render. There are very few guardrails in terms of mistakes actually being implemented in campaigns.”
What does writing templates cost a team?
People more than licences. Buyers price templating in specialist hires, contracts and engineering hours, and the clearest cases are on Marketing Cloud, where AMPscript is described as proprietary and hard to staff.
A lender says “AMPscript developers are hard to come by and they're not cheap,” and in a later interview calls it “a proprietary code that only Salesforce uses.” A home-services company holds its rating down partly because of “getting the folks with the specialized skills to actually work in AMPscript.” A fashion retailer that had just moved onto Marketing Cloud says “you need someone who knows how to do code, write queries, AMPscript,” and describes hiring an outside agency to deploy its emails. A parts distributor that rates the platform for its power still says “You do need somebody who can understand SQL and AMPScript.”
The other side of the ledger shows up when buyers leave. An online marketplace that moved from Marketing Cloud to Iterable says the new platform “doesn't require a lot of HTML coding as Salesforce did, which is already a huge time saver,” and an apparel retailer that moved to Bloomreach says “The number of hours they're spending in debugging things or building an email template has gone down significantly.” A specialty health retailer that made the same move to Bloomreach described months of “building all of the back-end coding and segmentation for our journeys” ahead of warming up its sending, and in a later interview said it had been fully migrated since May 2026. That rebuild is an upfront migration cost, separate from the ongoing work of maintaining and troubleshooting the templates after the move.
Want this checked against your own stack?
Start my checkup →Should you choose an email platform by its templating language?
Not by the language alone. Our recommendation is to choose by whether your team can build, test and maintain the personalization you need on that platform. Both languages can carry sophisticated messages; in these interviews the effort depends on the platform’s tools, the complexity of the logic and who writes it, and a powerful language is worth less when every campaign needs a specialist the team does not have.
The checks below are ours too, drawn from these accounts rather than a practice buyers describe. First, name the person who will own the logic, whether a marketer, a specialist or an engineer, and have them recreate a representative complex template during the trial, working the way your team actually would: with the platform’s visual editor, documentation, AI assistance and normal support. Second, count the templates that carry real logic (recommendations, loyalty tiers, multi-language content), because those are the ones that have to be adapted when you move, and the ones a specialist or agency will be paid to maintain. Third, check the vendor’s supported subset, down to the tags, filters, data objects and how templates render, since Braze’s Liquid and Iterable’s Handlebars each leave out parts of the standard language by their own documentation, Bloomreach’s documentation limits where Jinja can be used, and a pattern your current team relies on may not exist. Fourth, price the people as well as the software: specialists, agencies, engineering support and the marketer hours spent maintaining and troubleshooting templates are ongoing costs, and belong in the comparison beside the one-time migration work. Fifth, test the AI helpers on your own templates rather than the demo’s, since buyers describe them catching and writing code, not replacing the person who owns it.
For the wider case against Marketing Cloud’s complexity, see leaving Salesforce Marketing Cloud and Braze vs. Salesforce Marketing Cloud; for how Braze stacks are wired, the Braze stack page; and for the category itself, what is an ESP.
Common questions
What is the difference between Liquid and Jinja?
Both are template languages that personalize a message when it is sent, inserting customer data and conditional content, and both use the same delimiters: double curly braces to print a value and curly-brace-percent tags for logic. Liquid is the open-source language Shopify created, built so that people editing templates cannot run code on the server; it does its work through a fixed set of objects, tags and filters. Jinja is a Python templating engine whose expressions work much like Python’s, so it allows inline arithmetic and comparisons, and adds macros and template inheritance, though a template can reach only the variables and functions the platform exposes to it. Simple placeholders can look identical in both, but conditions, calculations and reusable blocks generally need adapting, and a platform that supports either language may not support all of it.
Does Bloomreach use Liquid or Jinja?
Jinja. Bloomreach Engagement’s documentation describes Jinja2, commonly called Jinja, as the templating language used to personalize email campaigns (body, subject line, sender, pre-header and UTM parameters), weblayers, HTML blocks, scenario actions, experiments and asset templates. The documentation does not mention Liquid. Teams moving to Bloomreach from a Liquid platform such as Braze or Customer.io should plan to adapt any logic beyond simple placeholders to Jinja.
Which email platforms use Liquid?
Braze and Customer.io both use Liquid for message personalization, according to their documentation; Braze supports Liquid up to and including Liquid 5 and says it supports only certain portions of Shopify’s Liquid. Shopify itself uses Liquid for storefront themes, which is a different job from email. Bloomreach Engagement and Simon Data use Jinja, Iterable uses Handlebars, Klaviyo uses the Django template language and Salesforce Marketing Cloud uses AMPscript.
What is AMPscript, and how is it different from Liquid?
AMPscript is Salesforce Marketing Cloud Engagement’s own scripting language, used across email, SMS, mobile messages and landing pages, and used alongside SQL queries that prepare the data it reads. Liquid is an open-source template language that several platforms share. In buyer interviews AMPscript is the language buyers describe as a staffing problem: buyers who praise its power still say it needs a specialist, and several describe agencies or contracted partners kept on mainly to write it.
Does Iterable use Liquid or Handlebars?
Handlebars. Iterable’s support documentation says to use Handlebars for dynamic content and personalization in its templates, and notes that it does not support every part of the Handlebars language, so some standard Handlebars syntax behaves differently there. Handlebars shares the double-curly-brace output with Liquid and Jinja but writes its logic as block helpers rather than percent tags.
Do marketers need to know code to use Liquid or Jinja?
For first-name personalization, no; for product recommendations, conditional content and loyalty logic, someone on the team does. In these interviews Braze buyers describe marketers writing Liquid themselves, while buyers of other platforms describe specialists, borrowed engineers or outside agencies doing the work. Where Jinja is the language, one retailer credits developers on its own team for what it gets from Bloomreach, and two others describe marketers who could not write Jinja on Simon Data without help. Newer AI assistants inside some platforms now write or repair template code, which buyers describe as narrowing the gap.
Is it hard to move email templates from Liquid to Jinja or AMPscript?
For anything beyond simple placeholders, it is a rebuild rather than a conversion. The languages differ in syntax and in what each platform supports, so conditions, calculations and reusable blocks have to be adapted and tested on the new platform. That rebuild is an upfront cost, separate from maintaining the templates afterwards. One specialty retailer that moved from Salesforce Marketing Cloud to Bloomreach described months of auditing templates and rebuilding the back-end coding and segmentation for its journeys before moving its sending across, and it reported being fully migrated in a later interview. Counting the templates with real logic in them, before signing, is our recommendation rather than a practice buyers describe.
Get a checkup on your tech stack
A checkup for your marketing stack, built from hundreds of verified buyer interviews: what matters most to you, a shortlist for your stack, and your next steps.
Start my checkupFree · no password · your answers are anonymized before they inform research like this.