Stricter Liquid parsing: what changed and how to fix an older theme

From 13 January 2026, Shopify enforces stricter Liquid parsing for themes. New submissions to the Theme Store and App Store already have to pass it. The reason is straightforward: some code that was historically accepted was being evaluated in ways the author didn't intend, and a stricter parser lets Shopify improve Liquid without breaking things unpredictably.

If you maintain older themes, here's what to look for. The patterns below come from Shopify's own strict-parser migration guide, so check that page for the complete and current list.

How to find problems

• Theme Check and the Shopify CLI flag strict-parser violations while you work. Run them on every theme you maintain.
• Work on a duplicate theme, never the live one.
• After fixing, click through the store: product page, collection, cart, search, any custom section. A parser fix shouldn't change behaviour, but verify that.

Patterns that no longer work, and the fixes

1. Logical operators in assignments.

{% comment %} Before {% endcomment %}
{% assign visible = false or true %}

{% comment %} After {% endcomment %}
{% liquid
  assign visible = false
  if settings.show_a or settings.show_b
    assign visible = true
  endif
%}

Logical operators belong in conditions, not in assign.

2. Filters in render tag arguments.

{% comment %} Before {% endcomment %}
{% render 'image', alt: image.alt | escape %}

{% comment %} After {% endcomment %}
{% assign safe_alt = image.alt | escape %}
{% render 'image', alt: safe_alt %}

Compute the value first, then pass it in.

3. Conditionals as render arguments. Passing settings.a or settings.b as an argument isn't allowed. Wrap the render in an if, or compute a variable first.

4. The with keyword plus key-value pairs.

{% comment %} Before {% endcomment %}
{% render 'icon' with style: 'lock' %}

{% comment %} After {% endcomment %}
{% render 'icon', style: 'lock' %}

5. Missing argument values. A bare responsive or responsive: isn't valid. Give it a value, such as responsive: true.

6. Positional arguments to render. Use key-value pairs: product: product, collection: collection.

7. && and ||. Use the words and and or.

8. Parentheses in conditionals. if x and (y or z) must be restructured. Remove the parentheses, or split into nested conditions that express the same logic.

9. Logical operators in case statements. Nest an if inside the when block.

10. A stray => in when. Write when 550, not when => 550.

11. Inline comments after code. Put the comment on its own line.

12. Bare bracket access. Use self[key] rather than a bare [key].

Be careful with "equivalent" rewrites

Some of these fixes aren't mechanical. Rewriting a condition that used parentheses to control precedence can change what it means if you flatten it carelessly. Write down what the original meant to do, rewrite it, and test the cases that exercise each branch.

If a theme is automatically rewritten

Shopify can rewrite files to make them compatible and add a comment explaining the change. Treat that as a starting point. Review the diff, since you're now responsible for code you didn't write, and keep the theme in version control so you can see exactly what changed.

A process I'd use on every older theme

1. Duplicate the theme and put it under version control.
2. Run Theme Check, and list every strict-parser violation.
3. Fix in small commits, one pattern at a time.
4. Test the affected templates and sections.
5. Preview, compare with the live store, then publish.
6. Add Theme Check to your routine, so new code never regresses.

Strict parsing is a good example of the kind of change that's invisible until it isn't. A little maintenance now beats a broken section in the middle of a sale. It pairs well with documenting your snippets properly, which I cover in LiquidDoc and Theme Check.