Liquid and Django: Two Templating Languages, One Family Resemblance

While building a dynamic FAQ section for a Shopify product page recently — a snippet that checks a JSON metafield and renders question/answer pairs only if the merchant has actually filled them in — I kept getting a strange sense of déjà vu. The {% if %}, the {% for %}, the pipe-delimited filters, the dot-notation property access. I'd seen this shape before, just wearing different clothes: Django's template language.

It turns out that's not a coincidence. Here's a walkthrough of where Shopify's Liquid and Django's Template Language (DTL) genuinely converge, where they diverge in ways that matter, and why the resemblance exists in the first place.

(Screenshots from the actual FAQ snippet referenced throughout.)

A Shared Lineage, Not Just a Coincidence

Liquid was created by Shopify co-founder Tobias Lütke and has been in production since 2006. It wasn't designed in a vacuum — multiple accounts of its origin note that it deliberately follows the same approach as Django's template language: a syntax that's easy for non-programmers (merchants, theme designers) to read and write, expressive enough to handle real logic, but restricted enough that it can never execute arbitrary or malicious code on someone else's storefront.

That last constraint is the whole reason Liquid looks the way it does. Django's template language was built to be safe by convention for developers building their own sites. Shopify needed something safe by design — thousands of independent theme developers were going to run this logic inside Shopify's own infrastructure, on other merchants' data, so "logic-lite and sandboxed" wasn't a nice-to-have, it was the entire point. Borrowing DTL's syntax and philosophy solved that problem without reinventing it.

Where the Resemblance Is Uncanny

Looking at the actual snippet from the FAQ section, a few things map almost one-to-one onto Django syntax.

Output tags. Both languages use double curly braces to print a variable to the page:

Liquid:  {{ product.description }}
Django:  {{ product.description }}

Identical. Dot notation for property access, no parentheses, no method-call syntax — both treat "reach into this object and grab a field" as the most common operation a template needs to do, so both make it as terse as possible.

Logic tags. Both wrap control flow in curly-percent brackets, as opposed to the double-curly used for output:

Liquid:  {% if faq_items.size > 0 %} ... {% endif %}
Django:  {% if faq_items %} ... {% endif %}

Same delimiter, same if / endif and for / endfor block-closing convention, same general shape. Anyone who's written a Django template can read a Liquid {% for item in faq_items %}...{% endfor %} loop without needing a reference doc, and vice versa.

Filters via the pipe operator. Both languages repurpose the Unix pipe character to mean "pass this value through a transformation":

Liquid:  {{ product.price | money }}
Django:  {{ product.price | floatformat:2 }}

This is a deliberate, shared piece of syntax DNA — not something either language invented from scratch. It reads like a shell command, and that's exactly the point: chain small transformations together without nesting function calls.

Comments. Both support block-level comments with matching open/close tags:

Liquid:  {% comment %} ... {% endcomment %}
Django:  {% comment %} ... {% endcomment %}

The "logic-lite" philosophy. Neither language lets you define arbitrary functions, run raw code, or do anything a template shouldn't be doing. Both are explicitly not general-purpose programming languages — they're designed to stay legible to the person styling a page, not just the person who wrote the backend.

Where They Genuinely Part Ways

The similarities are real, but they stop well short of being interchangeable. A few of the differences actually matter if you're moving between the two.

Whitespace control. In the FAQ snippet, you'll see tags like {%- if faq_metafield.value != blank -%} — that hyphen is Liquid's whitespace-trim syntax, stripping the newline/indentation around the tag so the rendered HTML doesn't end up full of stray blank lines. Django's template language has no equivalent hyphen-trim syntax at all. If you want to control whitespace in vanilla Django templates, you reach for the separate {% spaceless %} tag instead, which works differently (it strips whitespace between HTML tags, not around template tags). This trips people up constantly when porting snippets between the two.

Extensibility and trust model. This is the deeper difference, and it flows directly from why each language exists. Django templates run entirely on infrastructure the developer controls, so Django happily lets you write custom template tags and filters in actual Python and register them for use in templates. Liquid can't make that trade-off — Shopify runs Liquid templates from tens of thousands of independent theme developers, on shared infrastructure, against other merchants' store data. So Liquid deliberately has no path to "just write some Ruby here." Every tag and filter has to be explicitly implemented and exposed by Shopify (or whatever host application embeds Liquid) — nothing is user-extensible into arbitrary code. Same-looking syntax, very different trust boundary underneath it.

Template composition. Django has a real inheritance model — {% extends "base.html" %} plus named {% block %} regions that child templates override. Liquid doesn't have a direct equivalent; it composes templates by rendering discrete, self-contained snippets into a parent file ({% render 'faq-from-metafield' %} in the FAQ example), closer to an "include" than true inheritance. You can approximate Django-style layout inheritance in Liquid, but it's not a first-class concept the way it is in DTL.

Filter arguments. Django filters are mostly single-argument, colon-separated ({{ value|date:"Y-m-d" }}). Liquid filters can take multiple comma-separated arguments ({{ value | replace: "a", "b" }}), which gives Liquid slightly more flexibility per-filter at the cost of being a little less uniform.

A small vocabulary quirk. Liquid has an {% unless %} tag (a negated if, syntactic sugar many Rubyists will recognize) with no Django equivalent — DTL has no built-in "unless." It's a small thing, but it's a good example of Liquid's Ruby roots showing through a syntax that otherwise reads as very Django-like.

Ecosystem and portability. Django's template language is tightly coupled to Django itself and lives almost exclusively in Python-world. Liquid, by contrast, was built to be embeddable — the original is Ruby, but it's been ported to Python, JavaScript, Rust, OCaml, and more, and it powers systems well beyond Shopify (Jekyll's static site generation being the best-known example). The "sandboxed by design" property that makes Liquid safe for multi-tenant use is the same property that makes it portable — a language with no ability to execute host-language code is much easier to reimplement faithfully in a different host language.

Why the Resemblance Isn't Superficial

It would be easy to write this off as "well, most templating languages end up looking similar." But the specific choices — curly-brace output tags, pipe-based filters, block-style control flow, deliberate exclusion of arbitrary logic — aren't the only way to solve "bridge data and HTML." Compare that to Mustache or Handlebars, which lean much further toward "logic-less" and refuse to give you real conditionals or loops with arguments the way Liquid and Django both do. Liquid sits in a specific, deliberate middle ground between "no logic at all" and "full programming language" — and that middle ground is exactly where Django's template language already was when Liquid was built. The resemblance isn't convergent evolution; it's closer to Liquid picking up a design that had already solved the problem it needed solved, then adapting it for a much less trusted, much more multi-tenant environment.

Django code examples to come — the syntax above is accurate to DTL, but I'll swap in real screenshots from a live Django project once I've got one handy to pair with the Liquid screenshots above.