A merchant wants to experiment with design elements in the theme editor - button colors, font choices, border thickness, opacity. They're not comfortable editing Liquid code; they want to click, preview, save. The question for the developer: how do you expose the right knobs to the theme editor without giving merchants a way to break the theme?

The theme-editor control surface

Shopify themes have a specific file that controls which settings merchants see in the theme editor: config/settings_schema.json.

This schema defines:

• Theme settings - global controls (site typography, brand colors, button defaults)
• Section settings - per-section controls (image, heading, call-to-action per hero section)
• Block settings - nested controls within sections (individual feature blocks)

A well-designed settings schema gives merchants meaningful control without overwhelming them with technical knobs.

The file structure

config/settings_schema.json defines what the merchant sees:

config/settings_data.json holds the merchant's saved values. This file isn't edited by developers directly - it's updated every time the merchant saves settings in the theme editor.

Liquid templates consume the settings via settings.color_button_primary, settings.font_heading, etc.

The correct answer for "where to expose design tokens"

The file that controls merchant-editable design is config/settings_schema.json. Adding a new setting there makes it appear in the theme editor's global settings. Merchants click, preview, save; the change propagates across every section that references the setting.

This is distinct from:

• config/settings_data.json - the saved values, not the schema
• sections/*.liquid - per-section settings defined in schema tags at the bottom of each section file
• assets/*.css - compiled CSS, not editable through the editor
• templates/*.json - page template structure, edited through the theme editor's customization mode

Setting types that fit design tokens

Shopify's settings schema supports many types. For design tokens, the useful ones:

• color - hex color picker
• color_background - background with optional transparency
• color_scheme - references a color scheme defined elsewhere
• font_picker - select from Shopify's font library (Google Fonts + system fonts)
• range - numeric slider (for border thickness, opacity percentage, image border radius)
• select - dropdown (for size options like "small/medium/large")
• checkbox - boolean toggle
• text - short text input (for custom CSS class names, if you really must)

For the scenario at the top - button colors, fonts, border thickness, opacity - the right setting types are color, font_picker, and range respectively.

Consuming settings in Liquid and CSS

In Liquid, settings are accessed via the global settings variable:

For bulk CSS styling, many themes compile settings into CSS custom properties in the layout:

Then component CSS uses the custom properties:

This separation means design-system changes in the theme editor propagate everywhere in one place.

Color schemes for complex theming

Modern Shopify themes support color schemes - named combinations of background, text, button, and accent colors that apply to sections. A merchant can define "Light scheme" and "Dark scheme" and apply either to any section.

Color schemes live in the schema too but have their own structure:

This is the pattern Dawn and modern OS 2.0 themes use. Merchants pick a scheme per section; the theme renders with the scheme's colors consistently.

Font pickers and the font_url filter

For fonts, the font_picker setting type returns a font object with a family name and loading URL. Themes use the font_url filter to load the right stylesheet:

This emits the proper @font-face declaration for the chosen font. Merchants can pick any of Shopify's library fonts (Google Fonts + system) and the theme adapts automatically.

Settings organization for non-technical merchants

A well-organized settings schema:

• Groups related settings under headers ("Colors", "Typography", "Buttons")
• Uses clear labels ("Primary button color" not "color_button_primary")
• Includes help text explaining the effect
• Orders settings from most-impactful to least
• Provides sensible defaults

A schema with 100 ungrouped settings is unusable even by technical merchants. A schema with 15 well-organized settings lets non-technical merchants confidently experiment.

What to expose vs hide

Not every theme value belongs in the settings schema. Good candidates:

• Brand colors
• Typography choices
• Layout parameters (max content width, spacing scale)
• Button styles
• Section-level toggles (show/hide features)

Bad candidates:

• Things requiring CSS knowledge (box-shadow syntax, custom positioning)
• Things that would break layout at wrong values (minimum padding below which content overlaps)
• Implementation details (cache timeouts, third-party IDs)

The boundary: if a wrong value breaks the theme meaningfully, it doesn't belong in merchant-editable settings.

What ships with a well-designed theme settings schema

A theme that supports non-technical merchant self-service has:

• config/settings_schema.json with grouped, labeled, defaulted settings
• Design tokens consumed via CSS custom properties
• Settings exposed through the theme editor in an intuitive order
• Defaults that produce a usable theme without any customization
• Documentation (or help text in the editor) explaining what each setting does
• Versioning discipline - renaming a setting's ID in code breaks merchant's saved values

Merchants who can self-serve design tokens stay happier with their theme. The developer's work is making the right set of knobs available without offering footguns.