Somebody asks for the blue to be slightly darker. On a site set up properly that is one field and thirty seconds. On a site where every heading had its colour picked by hand in the widget, it is an afternoon of opening pages, hunting for the ones you missed, and finding three more a fortnight later.
The difference is about twenty minutes of setup at the start, and almost nobody does it. Elementor puts the tools at the top of the editor and makes them entirely optional, so it is easy to build a whole site without touching them.
By the end of this you will have a palette and a set of text styles defined once, sensible defaults for headings, body text, links, buttons and forms, and a naming scheme that survives the next redesign. I will also cover what happens when your theme and Elementor disagree.
Before you start
You need an administrator account and the Elementor editor on any page. That is genuinely it. Nothing here can take a site down and there is no code to paste.
One warning worth having before you start rather than after: changing a global colour changes it everywhere it has been applied, instantly, across the whole site. That is the point, and it is why the first pass belongs on staging if the site is live. Note also that Elementor spells its labels the American way, so where I write “colour” the panel says Global Colors.
Step 1: Find Site Settings
Open any page in the editor. Click the Elementor logo in the top left of the panel, then choose Site Settings. If your version shows a hamburger menu in that corner instead, it is behind that.
Nothing here is attached to the page you opened it from; it applies site-wide. The menu has three groups. Design System holds Global Colors and Global Fonts. Theme Style holds the defaults for typography, buttons, images and form fields. Settings holds site identity, layout and the rest.
Step 2: Set up your global colours
Open Design System > Global Colors. Elementor gives you four to start with: Primary, Secondary, Text and Accent. Edit those and add as many more as you need.
Work from the brand rather than from the page. Write down every colour the site uses on purpose, not every colour that appears on it. Most sites need six to ten: a main brand colour, a second one, neutrals for body and muted text, near-white and near-black for backgrounds, a border grey, and often a single alert colour.
Add each one, paste the hex value, and give it a name. The name decides whether the palette is still useful after the next redesign.
Step 3: Name colours by role, not by colour
Call a colour “Dark Blue” and you have written today’s design into its name. When the brand moves to green you get two bad options: rename everything and chase down every reference, or leave a colour called Dark Blue that renders green and confuse everyone who touches the site, including yourself.
Name it by the job it does and the problem disappears. “Brand Primary” can become green without lying. A palette that survives a rebrand looks roughly like this:
- Brand Primary and Brand Secondary
- Heading Text and Body Text, often near-black but rarely identical
- Muted Text for captions, meta and anything deliberately quieter
- Page Background and Surface, the second being cards and panels
- Border for rules, and Inverse Text for text on a dark band
Keep the list short, because a palette of thirty is one nobody can hold in their head, and do not create a global for a colour used once.
Step 4: Set up your global fonts
Open Design System > Global Fonts. The same four names appear, and again they are roles rather than descriptions.
Each global font is a full typography style, not just a family: family, size, weight, transform, style, line height and letter spacing, each with the device switcher beside it, so a heading can be 48px on desktop and 32px on mobile from one definition. That responsive part saves the most time, because the alternative is a mobile size on every heading widget.
On a typical site I define Heading for h1 to h3, Sub Heading for card titles, Body for paragraphs, Small for captions and form labels, and Button for call to action text.
Keep the number of actual font families to two, three at the outside. Every family and weight is another file the browser fetches before it can paint text. If you are chasing Core Web Vitals, the font list is one of the first places to look.
Step 5: Set the Theme Style defaults
This is the step almost everyone skips and it does more work than the previous two combined. Under Theme Style you set the default styling for elements, so the site is right before you place a widget. Drop a Heading on a page and it arrives at the correct size, weight and colour. You style exceptions rather than everything.
Typography covers body text and links. Set the body font and colour, and the link colour for both normal and hover. Links are the thing people forget most often, which is why so many Elementor sites have browser blue somewhere in the footer. Typography > Headings sets h1 to h6 individually. Do all six even if you only think you use three, because plugins and archive templates use the ones you did not plan for.
Buttons sets typography, colour, background, padding, radius and hover state for every button on the site, so you never style a button in a widget again. Images sets border, radius and shadow. Form Fields sets typography, colour, background, border and radius for inputs and labels, plus the focus state. Unstyled inputs are the fastest way to make a good design look unfinished.
Set every one of these using a global colour and a global font, not a raw value. That is where the discipline lives.
Step 6: Actually apply the globals
Defining a palette and then picking hex codes in widgets is the failure mode, and it is easy to do, because the ordinary picker is right there and the global is one extra click away.
In any colour control, click the small globe icon beside the swatch. That switches the picker from a raw value to your list of global colours. Choose one and the widget is linked to the global rather than holding a copy of its value. Typography controls work the same way. The check is visual: a plain swatch means a one-off value, an active globe and a name means it is linked.
Elementor also generates CSS custom properties from the globals, named --e-global-color-primary and so on, plus typography variables such as --e-global-typography-primary-font-family. Custom CSS can reference the palette instead of repeating hex values:
/* Reads the palette, so a change in Site Settings updates this too. */
.my-custom-callout {
background-color: var(--e-global-color-primary);
color: var(--e-global-color-accent);
}Any custom CSS that hardcodes a brand hex is a place the rebrand will miss.
Step 7: Watch a change propagate
Change one global colour, save, and reload the front end. Every widget linked to that global updates, everywhere, including inside templates, headers, footers and popups. What does not update is anything holding a copy of the old value: your unlinked widgets.
That gives you the cheapest audit you will ever run. Set the brand colour to a violent pink, save, click through the site, then set it back. Everything that did not move was styled by hand.
The current picture: variables and classes in Elementor 4
If your site is on Elementor 4 with the Atomic Editor active, there is a second system alongside this one.
V4 introduces Color Variables and Typography Classes, native to the atomic elements and managed in their own Variables and Class managers. Version 4.0 also introduced the ability to sync them: a Color Variable to a V3 Global Color, a Typography Class to a V3 Global Font. Where that link exists, updating the variable propagates to the legacy global, so the change reaches V3 widgets on the same site. Elementor’s documentation is clear that font syncing covers typography itself and not colour, size or weight, with fuller migration tooling described as coming later.
The rest is worth stating precisely, because there is noise around it. Atomic features are on by default for new installations, and Elementor has said new sites run version 4 by default from April 2026. Nothing migrates automatically, so an existing site keeps everything as it is after an update; the only visible change is a notice about the Atomic Elements section in the panel. V3 widgets and V4 atomic elements work on the same page, the whole thing can be switched at the Atomic Editor tab in Elementor > Settings (Elementor has been reorganising its menu, so some builds list it under Editor > Settings instead), and there is no published end-of-support date for V3.
When your theme fights Elementor
Here is the situation that sends people back to picking hex codes: you set a global font and some of the text ignores it.
Nothing is broken. Two systems are styling the same element and one is winning on CSS specificity. Your theme has its own typography settings, in the Customizer or its own options panel, and so does Elementor. Whichever produces the more specific selector, or loads later, wins.
Elementor provides a switch for exactly this. Go to WP Admin > Elementor > Settings, on the General tab, and you will find Disable Default Colors and Disable Default Fonts. Ticking these stops Elementor applying its own defaults and lets the theme’s typography through. That is right when the theme is the intended source of truth, and wrong when Elementor is.
To find out which is winning, use the browser inspector rather than guessing. Right-click the text and choose Inspect. The Styles panel lists every rule applying to it, with overridden ones struck through. The rule at the top is the winner, and beside it is the stylesheet it came from. An Elementor rule generally comes from a file with elementor and a post ID in the name, or from a .elementor-kit- class, which is where Site Settings output lands.
Two other causes. Elementor Canvas loads without theme styling, so if one page looks different from the rest, check its template in Page Settings. And form or ecommerce plugins ship opinionated CSS of their own, where the fix is that plugin’s settings rather than an override.
Reach for !important last, if at all. It wins the argument today and makes the next change harder, which is the exact problem globals exist to solve.
How to check it worked
Click through several widgets and confirm the colour and typography controls show the globe icon active with a name rather than a raw hex value. Then run the pink test from Step 7; anything that did not move is unlinked.
Finally, drop a fresh Heading, a Button and a Form onto a blank draft page without styling them. If your Theme Style defaults are right, all three should already look like they belong. If they arrive looking like generic Elementor, that step is not finished.
When it does not work
The colour changed in the editor but not on the front end
Cached CSS, almost always. Clear your page cache and CDN, then use Elementor > Tools > Regenerate CSS & Data. If it is right in an incognito window but wrong in your normal one, that is your browser cache.
Some text ignores the global font entirely
Either that widget has its own typography set directly, which always beats the global, or the theme is winning on specificity. Inspect the element and read which rule sits at the top. If it is a widget setting, clear it and attach the global instead.
Changing a V4 variable did not update my old widgets
The variable is not synced to the corresponding V3 global. Open the Variables manager and use the sync option on it. Remember that font syncing covers typography only, so colour, size and weight still need setting on the V3 side.
Common questions
How many global colours should I have?
Usually six to ten. Enough to cover text, backgrounds, borders and the brand colours, few enough to remember. If you are scrolling the list to find one, you have too many.
Should I set colours in Theme Style or in Global Colors?
Both, in order. Define the values in Global Colors, then use those globals when setting the Theme Style defaults. Theme Style decides what elements look like; Global Colors decides what the values are.
Can I copy my globals to another site?
Elementor’s kit export and import carries Site Settings, so exporting a kit from one site and importing it into another brings the palette and text styles across.
Is it worth retrofitting this to an existing site?
Usually yes, and it is less work than it sounds. Define the palette and text styles, set the Theme Style defaults, then work through pages by traffic rather than alphabetically.
Twenty minutes now, or an afternoon later
Global colours and fonts are not a design feature. They are a maintenance feature that happens to make design consistency easier, and the value is entirely in what happens the day someone asks for a change.
The parts that matter most are the least obvious. Name by role rather than by colour, so the palette survives a rebrand. Set the Theme Style defaults, so most of the site is right before anyone touches a widget. Apply globals by reference every time, because one hardcoded hex is one page you will miss. And when something ignores a global, open the inspector and find out which rule is winning instead of piling on !important.
If you have inherited a site where none of this was done, run the pink test first. It tells you within ten minutes whether you have a tidy-up or a genuine rebuild, and if it is the second, a rebuild done properly starts with the design system rather than bolting one on afterwards. Get in touch if you would rather not spend the afternoon.
