Shopify Theme Editor Bug: {% style %} vs <style> Explained

Introduction

A client reached out about a frustrating bug in their Shopify theme editor — the Undo button wasn't behaving correctly, and worse, the preview was showing the wrong data entirely. The UI said one thing. The storefront preview showed another.

Our first instinct was to look at a speed optimization we had implemented on the theme — not because it was a recent change, but because it was the most architectural thing we'd touched and felt like the likeliest candidate for something this subtle.

Even Shopify support agreed and pointed there first.

But after thorough verification, the optimization had nothing to do with it. Going back to support with more context is what finally cracked it — and the real cause turned out to be something far smaller than anyone expected.

A single Liquid tag — something most Shopify developers use without thinking twice.

The Bug

Here's exactly what the client was experiencing:

• Open the Shopify theme editor
• Select a section and change the background color from light gray to dark blue
• Settings panel updates ✅ Preview updates ✅
• Click Undo
• Settings panel reverts back to light gray ✅
• But the preview? Still showing dark blue ❌

The UI and the preview were completely out of sync. From a merchant's perspective, this is deeply confusing — and breaks trust in the editor itself.

In real scenarios, this could lead to merchants making incorrect design decisions because what they see in the editor isn't what actually gets saved.

The Initial Investigation

When you're debugging something in the theme editor, the natural instinct is to look at your biggest structural changes first — even if they're not new.

There was a speed optimization in place that handled how assets and stylesheets were being loaded. Optimizations that defer or async-load stylesheets can sometimes interfere with how the theme editor injects live updates, so it was a reasonable place to start.

Shopify support looked at it too and suspected the same thing.

I spent time verifying it from multiple angles — disabling parts of the implementation, testing in isolation, checking the editor behavior with and without it. Nothing changed. The undo bug persisted regardless.

That ruled it out completely. So I went back to support with a more detailed breakdown of the actual behavior — the specific steps to reproduce, which settings were affected, and what exactly was and wasn't updating. That's when the conversation shifted, and I was able to pinpoint what was actually causing the issue: how the color settings were being output inside the section file.

The Root Cause: {% style %} and How the Theme Editor Patches It

In the section file, the Liquid {% style %} tag was being used to apply merchant-configurable colors, like this:

liquid
{% style %}
  .section-{{ section.id }} {
    background-color: {{ section.settings.background_color }};
    color: {{ section.settings.text_color }};
  }
{% endstyle %}        

This is a common pattern. The Shopify docs even recommend it for applying color settings. And for the most part, it works fine.

Here's what {% style %} actually outputs in the DOM:

html
<style data-shopify>
  .section-abc123 {
    background-color: #d3d3d3;
    color: #000000;
  }
</style>        

Notice the data-shopify attribute. That's the key detail.

The Shopify theme editor uses this attribute to identify style blocks that it should patch in real time when a setting changes — without triggering a full page refresh. When you change a color in the settings panel, the editor's JavaScript finds the data-shopify style tag and updates the CSS values directly in the DOM.

This works perfectly for forward changes.

The problem is with undo.

When you hit Undo, the theme editor reverts the setting value in the panel — but the mechanism it uses to reverse the DOM change is not the same as the one used for applying changes. It doesn't re-patch the data-shopify style tag. The tag is already mutated in memory, and the undo operation doesn't cleanly reverse that change.

So you end up in a split state: settings panel showing the old value, DOM still holding the patched new value. That's exactly the desync the client was seeing.

Once this became clear, the fix itself was surprisingly simple.

Why the Plain <style> Tag Works

When you switch to a regular HTML style tag:

html
<style>
  .section-{{ section.id }} {
    background-color: {{ section.settings.background_color }};
    color: {{ section.settings.text_color }};
  }
</style>        

There is no data-shopify attribute. The theme editor does not try to patch this tag directly. Instead, it triggers a full section re-render every time a setting changes — including when you undo.

A full re-render means the section's HTML is completely regenerated from the current settings state and injected fresh into the preview. So whether you're applying a change or undoing one, the preview always reflects exactly what the settings panel shows.

No split state. No desync.

The Fix

Replace {% style %} / {% endstyle %} with a plain <style> tag in your section files.

Before:

liquid
{% style %}
  .section-{{ section.id }} {
    background-color: {{ section.settings.background_color }};
  }
{% endstyle %}        

After:

html
<style>
  .section-{{ section.id }} {
    background-color: {{ section.settings.background_color }};
  }
</style>        

That's it. Two lines changed. Issue gone.

The Edge Case: Color Filters

One more thing worth flagging before you go and swap all your tags.

If you're applying Liquid filters to color values — for example, converting a color to RGB format for opacity support like this:

liquidbackground-color: rgba({{ section.settings.background_color.rgb | replace: ' ', ',' }}, 0.8);

Neither {% style %} nor <style> will give you reliable live preview behavior in the theme editor. The editor's live patching mechanism cannot handle filter-transformed color values.

The recommended approach here is to use CSS custom properties. Define the raw color as a CSS variable and let CSS handle the rest:

html
<style>
  .section-{{ section.id }} {
    --section-bg: {{ section.settings.background_color }};
  }
</style>        

Then reference the variable in your stylesheet with opacity applied natively in CSS. This keeps the editor happy, the preview accurate, and your styles flexible.

Key Takeaways

• {% style %} outputs a data-shopify style tag that the theme editor patches directly.
• This patching works on forward changes but silently breaks on undo/redo.
• Plain <style> triggers full section re-render, keeping preview and settings always in sync.
• For color filters, CSS custom properties are the right approach.
• When debugging editor issues, always isolate undo/redo behavior — it narrows root cause faster.

Closing

A small tag — but a big impact on the merchant experience.

The fix itself took minutes once we knew what to look for. Getting there took multiple rounds of investigation, ruling out the wrong suspects, and the right back-and-forth with Shopify support.

If you're building custom Shopify themes and using {% style %} for dynamic color settings, audit your section files and make the switch to plain <style> tags — it's a low-effort change that prevents a genuinely confusing merchant experience.

If you're working on custom Shopify themes and run into similar issues, feel free to reach out — happy to help.

Have you run into similar theme editor quirks? Drop them in the comments — would love to compare notes.