Colour handling is a single option with a large downstream effect. Getting it right before you convert saves a lot of re-styling later.
The two modes
- Keep original colours — every text colour, background, border colour and shadow colour is written to the widget as an explicit value. The result matches the source exactly.
- Use site colours — per-widget colours are skipped and Elementor’s Global Colours are referenced instead: headings map to Primary, body text to Text, button backgrounds to Accent, and so on.
When to use each
Choose site colours when you are pulling a block into an existing branded site. The section adopts your palette immediately, and when you later change a Global Colour the imported section changes with it. This is the maintainable choice for anything that will live on your site long-term.
Choose original colours when the design is the point — a client mock-up, a one-off landing page, or when the source palette is deliberately different from the rest of the site.
What colour values survive
Solid colours convert directly. Two-stop linear gradients are recognised and become Elementor gradient backgrounds with the angle and both stops preserved. More complex backgrounds — radial gradients, multi-stop gradients — cannot be expressed in the same control, so the first solid colour is used as a sensible fallback rather than producing an empty background.
Box shadows come across too, but Elementor’s shadow control holds a single shadow. If your CSS layered several shadows, the front-most one is kept and a warning tells you the rest need adding by hand.
CSS variables
Custom properties like var(--brand) are resolved by the browser before they are read, so what you get is the final computed colour, not the variable name. That is usually what you want. If you rely on variables for theming, switch to site colours and drive the palette from Elementor’s Global Colours instead — that is the WordPress-native equivalent of the same idea.
Transparency
Fully transparent backgrounds are treated as “no background” rather than being written as a transparent colour, which keeps the settings panel clean. Semi-transparent values like rgba(255,255,255,.88) are preserved as-is.
The full mapping
In site-colours mode each widget type is bound to a specific slot in your palette:
- Headings → Primary
- Body text → Text
- Button backgrounds → Accent
- Icons → Primary
- Dividers → Secondary
Turning on site typography does the same for fonts: headings take your Primary typography and body text takes Secondary.
The two options are independent. Site colours with original fonts is a common and sensible combination — the block adopts your palette while keeping a display face the design depends on. Set them separately rather than treating them as one switch.
Why the connection is live, not a copy
This is the part worth understanding, because it explains why the choice matters so much later. Site mode does not look up your Primary colour and paste its hex value onto the widget. It writes a reference to the global — Elementor stores it as a pointer to the palette entry, not as a value.
So the binding stays alive. Change Primary in Site Settings six months from now and every heading that was converted in site mode changes with it, on every page, without opening one of them. A converted page becomes a normal citizen of your design system rather than a foreign body that happens to match today.
With original colours the value is baked in. That is exactly right for a client mock-up you need to reproduce faithfully, and exactly wrong for a section you will maintain for two years.
Set your palette up first
One prerequisite catches people out. Site mode binds to whatever your Global Colours currently hold — it does not create or guess them. Convert into a site whose palette is still Elementor’s factory default and your section faithfully adopts the factory default, which looks like the conversion failed.
Spend five minutes in Site Settings → Global Colors defining Primary, Secondary, Text and Accent before you convert anything you intend to keep. Everything imported afterwards lands correctly on the first try.
Icons behave slightly differently
An icon converted in site mode is given currentColor rather than a fixed value, which means it inherits from whatever encloses it. Drop that icon into a dark section and it turns light along with the text around it, with no per-widget setting to remember.
It is a small thing that saves a specific and annoying chore: hunting down twelve icon widgets after changing a section background because they are all still the colour they were on white.
A practical recommendation
If you are unsure, convert once with original colours to verify the layout is faithful, then convert again with site colours for the version you actually publish. Comparing the two takes two minutes and makes the decision obvious.
As a default: anything going onto your own site, use site colours. Anything reproducing someone else’s design for approval, use original colours. When a mock-up is approved and becomes a real page, convert it again in site mode rather than recolouring it by hand.