Part of our guide to Update Your Shopify Theme Without Losing Customizations.
Short answer: some of your customizations survive a theme update and some get replaced — and which is which is predictable. A theme update does not run a smart merge of your changes. It installs a fresh copy of the theme's code and brings your theme-editor settings across. So the split comes down to one thing: did you make a change in the theme editor, or did you make it by editing theme files?
This guide gives you the exact list on each side of that line, so you know what to expect before you touch the Update button. For the full picture of the topic, this sits under Update your Shopify theme without losing customizations.
What a theme update actually replaces
When you update a theme, Shopify publishes the new version's files: all of its
.liquid templates, sections, and snippets, plus its CSS and JavaScript. Your old
copy's files are not patched — they are superseded by the new release's files.
Separately, Shopify stores the settings you configured in the theme editor as
data. On themes that support the current update flow, those settings are copied
into the updated version. That is why your homepage layout, colors, and the text
you typed usually come back looking the same — the data survived, even though
every .liquid file underneath it was replaced.
What survives an update
These live as theme-editor data, not as code, so a supported update carries them across:
- Your section layout — which sections are on each template, their order, and which ones are hidden.
- Settings you typed or picked — headings, body text, button labels and links, images, colors, fonts, and toggles inside each section.
- Blocks you added — individual slides, FAQ rows, testimonials, and other repeatable items inside a section.
- Global theme settings — logo, color schemes, typography, and layout options set under Theme settings.
- Content in built-in flexible sections — text and configuration you entered in Rich text, Image with text, Custom Liquid (the setting), Multicolumn, and similar sections the theme already shipped.
The common thread: you set all of it in the editor, and none of it required editing a file.
What gets replaced
These are code, and code is exactly what an update swaps out:
- New section files you added to
sections/— a customfeature-banner.liquid, for example. - New snippets you created in
snippets/and referenced with{% render %}. - CSS you pasted into
assets/theme.css,base.css, or any theme stylesheet. - JavaScript you added to theme asset files.
- Direct edits to shared files like
theme.liquid,layout/theme.liquid, or a template's.liquid. - Liquid you hand-edited inside an existing section file to change its markup or logic.
If a customization involved opening the code editor (Themes → ⋯ → Edit code) and changing a file, assume the update will not carry it over. To recover work that was already lost this way, see a theme update removed my custom code.
The one test
Before an update, sort each customization with a single question:
Did I make this change in the theme editor, or by editing a file?
Editor changes are data and copy over. File changes are code and get replaced. A quick way to audit: open Themes → ⋯ → Edit code and look at the file list. Any section, snippet, or asset that is not part of the theme's standard file set — or any standard file whose contents you altered — is at risk in the next update.
One nuance: settings tied to code you removed
Editor settings survive, but a setting only means something if the section it belongs to still exists. If a merchant configured a custom section you built, and the update replaces the theme without that section file, the setting has nothing to attach to. In practice the content stops rendering even though the data technically persisted. This is why re-applying your custom files after an update matters — the settings are waiting for the code to come back.
How to make the whole question moot
There are two honest ways to stop worrying about the file-versus-editor split.
Keep a disciplined workflow. Duplicate the theme before updating, keep a written list of every custom file, and re-apply that list to the updated theme. The exact routine is in back up your theme customizations before updating.
Render the section from outside the theme. A section delivered by an app through a Theme App Extension is not a theme file, so a theme update never replaces it. That is the model SectionGuard uses — your sections and their settings come through every update without a re-apply step. If you want to compare that against keeping sections in theme files, the honest comparison lays out exactly what each approach survives.
If you rely on a section across theme changes, that structural route removes the question entirely; for a one-off tweak, the disciplined workflow is plenty.