I had just finished splitting a long section on a client's Shopify theme into a set of tidier blocks. To mark where each block began, I dropped in divider comments like {# LEFT RAIL #} between the markup, a habit carried over from projects that use Jinja and Twig. Theme check ran clean, not a single warning. I pushed to staging with confidence.
The moment the product page opened in a browser, there it was, sitting plainly in the middle of the layout: {# LEFT RAIL #} rendered as ordinary text. Not a hidden comment, but literal curly braces a shopper could read. Every divider I had written leaked onto the live page exactly as typed.
The wrong first instinct
My first reaction was to blame the build. I figured a minifier had failed to parse the comment, or that staging was serving a half-baked cache. I purged the cache, re-pushed, opened it in incognito. The brace text stayed right where it was.
What made it strange: theme check had said nothing. If this were genuinely broken syntax, there should have been a parse error. But there was none. The page rendered perfectly, the layout was intact, and in the middle of it sat text that should never reach a human. That "valid but wrong" combination is what finally pointed me at the real cause.
Why this happens
Shopify Liquid has no inline comment syntax like that. The {# ... #} form belongs to Jinja2 and Twig, not Liquid. Liquid's parser does not recognize {# as the opening of anything, so it treats it as ordinary text and emits it verbatim into the output.
That is exactly where the trap is. Because Liquid never sees {# as a special token, nothing is wrong as far as the parser is concerned. No error, no exception. This is a rendering bug, not a parse bug. And precisely because it is not a parse error, static checks like theme check will never flag it. To those tools, {# LEFT RAIL #} is just a run of literal characters, no more dangerous than typing the words "LEFT RAIL" directly into the template.
I was so fluent in Jinja syntax that my fingers typed it automatically, and Liquid dutifully printed anything it did not understand. Nothing was there to protect me from a habit applied in the wrong place.
The fix
The fix is simple once the cause is clear: replace every {# ... #} with Liquid's actual comment tag, {%- comment -%} ... {%- endcomment -%}.
{%- comment -%} LEFT RAIL {%- endcomment -%}Note the leading and trailing hyphens, {%- and -%}. Those strip the whitespace around the tag, so no leftover blank lines remain in the output once the comment is removed from the render. Without the hyphens you get correct markup but with an empty-line gap where the comment used to be.
To sweep the rest of the theme for stray {# ... #}, I did not trust my eyes. Since theme check stays silent, the only method I could rely on was to grep directly for the literal {#:
grep -rn '{#' sections/ snippets/That command scans every section and snippet file and returns each line that still holds a Jinja-style comment. I ran it, got a list of locations, replaced them all with the {%- comment -%} form, then ran grep once more to confirm the result was empty. One more push, and the product page was finally clean of wild curly braces.
The takeaway
Every template language has its own comment syntax, and they are not interchangeable. Jinja uses {# ... #}, Liquid uses {%- comment -%} ... {%- endcomment -%}. The danger is not merely getting the syntax wrong, it is that Liquid fails silently: instead of erroring, it prints your comment onto the page for shoppers to read.
Because the failure is silent, static tooling like theme check will not save you. So when you port templates from another ecosystem into Shopify, do not trust "check passed" alone. grep specifically for the literal {# across sections/ and snippets/ before you push. Since that incident, the grep for {# has become a standing part of my checklist whenever I touch a theme ported from a Twig or Jinja codebase.