Theme Palette Website Builder · guide for designers

How it works

You pick 16 colors.
The whole website reads from them.

Every color on a site — every heading, button, divider, background — used to be typed in by hand, one field at a time. Now each of those fields points at one of your 16 colors instead. Change the color once; every place that points at it follows.

311 color values that used to be typed by hand
16 colors you set, once, at the top of the file

See it move

One website, driven entirely by your swatches

Nothing below is hard-coded. Every color you see comes from your 16 swatches. Edit one and watch. Point at a swatch and the parts it controls will light up.

Est. 1994

A table by the window

Reserve View menu

Our kitchen

Cooked over open fire

Body copy sits on the default background. Titles, subtitles and paragraphs each have their own slot so you can tune them separately.


Dividers and section edges use the border color.

Private dining

The back room

On the contrasting section every kind of text collapses to a single slot: text on inverse. That is why it is used more than any other color.

The two photographs are stand-ins. What matters is the tinted panel over them — that is the overlay slot, and it is why hero text stays readable on any image.

The one piece of syntax

Double braces mean “use that swatch”

Your colors are declared once, at the top of the file, in theme_palette. Everywhere else in the file, a color field either holds a raw color like #FBF8F3 — or the name of one of those palette colors, wrapped in double braces. The second kind is a reference: a pointer back up to the top.

build_instructions.json

          

Point at any {{name}} below and its definition at the top will light up — that is the link the builder follows.

  • One declaration, many users. primary is decided once in theme_palette. The button in buttons and the CTA tab in the navigation both point at it. Neither one owns the color.
  • It works the same everywhere in the file. The buttons list and every command block use identical syntax. There is nothing extra to learn per section.
  • The builder swaps names for values before the site is generated — switch the view above to see it. The finished site contains ordinary colors; the braces never reach the browser.
  • Spelling matters, and mistakes are silent. A name that doesn't exist is left exactly as typed. See what that looks like.

Your working order

Top of the file first. Always.

This is a real sequence — doing it out of order is what creates most of the mess.

  1. 1

    Fill in all 16 colors

    Before you touch a single section, go to theme_palette at the top and set every slot. Not the three you care about — all sixteen. Leftovers from the starter palette are the single most common cause of a site that looks almost right.

  2. 2

    Look at the whole site

    Most sections are already pointed at sensible colors. If step 1 was done well, a large part of the site is simply finished at this point, with no further edits.

  3. 3

    Where a color is wrong, aim it somewhere else

    Only now do you open individual sections — and the fix is almost never a new color. Ask “which of my 16 does this actually want?” and change the name inside the braces. That is the whole job.

The habit worth building

Re-aim the pointer — don't paste a color

Say the popup should be your deep red instead of the page background. Both edits below make the popup red today. Only one of them stays correct tomorrow.

Costly

Paste the color in

"background_color": "#520100"

The popup is now disconnected from your palette. When the brand red changes, this field keeps the old one — and nothing points at it to remind you. Multiply by every field edited this way.

Cheap

Point at the slot that already holds it

"background_color": "{{secondary}}"

Same result on screen today. But this popup now moves with the brand forever, and anyone reading the file can see why it is that color.

Rule of thumb. Reach for a raw color only when no slot holds what you need and no slot should. If the color you are about to paste is already sitting in your palette, you wanted a reference.

The other half of the habit

Changing one spot, or changing it everywhere?

These need opposite moves, and getting them the wrong way round is the most common wasted afternoon on this file. Before editing anything, answer one question: is this color wrong here, or wrong everywhere it appears?

Wrong here

One section wants a different color

The body text is right across the site, but this one panel should pick up the brand color instead. That is a genuine exception.

Re-aim that one field.

"text_color": "{{text}}"  "{{primary}}"

Wrong everywhere

The color itself is not what you want

Body text should be charcoal, not warm brown — in every section, on every page. Nothing is wrong with where the fields point. The value behind the name is wrong.

Change the value in the palette. Touch nothing else.

"text": "#403A33"  "#1F2933"

What this looks like when it goes wrong

In a real setup, the designer wanted the text on the dark sections to be their soft tan rather than the starter cream. Reasonable. But instead of changing the one value, they went through the file and re-pointed every field, one at a time:

// repeated in 26 separate places
"text_color": "{{text_on_inverse}}"  "{{accent}}"

Meanwhile text_on_inverse sat untouched at the starter cream — a color the site no longer used anywhere. The whole change was this, once:

"text_on_inverse": "#F3EDE3"  "#DFC19B"

26 edits became 1. And it is not only the time. Those 26 fields now say “this text is the accent color,” which is not what anyone meant — so the next person to adjust the accent will move 26 pieces of body text along with it.

The tell. If you find yourself making the same edit for the third time, stop. You are not fixing sections — you are changing a color. Go back to the top of the file and change it there.

Live check · reads your swatches

Some colors travel in pairs

Several slots exist only to sit on top of another slot. Move the background of a pair without moving its text, and the text disappears. These read from the rail — edit a swatch and watch them respond.

Target is 4.5:1 for text and 3:1 for things you only need to see, like a hover color or an icon. These are the same thresholds an accessibility audit will apply.

Live check · reads your swatches

And some colors must never be the same

Two slots can each be a perfectly good color and still break the page — because they land on top of each other. A button filled with the same color as the section behind it is not a button any more; it is floating text.

Watch out

A misspelled name fails without a word

Nothing warns you. Nothing turns red. The build finishes normally and the name travels through to the finished site as plain text, where it means nothing at all.

"text_color": "{{text_on_primary}}"
reads your swatch
"text_color": "{{text_on_primar}}"
no such name — passes straight through ?

Both of these have shipped on real sites. The safest habit: copy the name from the palette at the top of the file rather than typing it from memory, and let the editor's autocomplete finish it for you.

Reference

What each of the 16 is for

The names describe a job, not a color. “Inverse” means the opposite tone to your background — not your second brand color. Counts show how many places in a standard setup already point at each slot.

Swatch Name What it does Used

Live check · before you hand off

Six things worth confirming

The first five read your current swatches and answer themselves. The last one is a quick look through the file.