How to Import an Elementor Header Template (JSON)

Header templates are the most common import question I get, and the confusion has one root: people import a header the way they import a page section, then wonder why it never shows up site wide. A header is a Theme Builder template, and Theme Builder templates play by their own rules.

The type field decides everything

Open any header JSON from our header template library and near the top you will find a type field set to header. That single field tells Elementor to file the import under Theme Builder instead of saved page templates. When I built our export pipeline I verified this the blunt way: strip the field and the same file imports as a page template, invisible to the Theme Builder entirely.

If your imported header is missing from Theme Builder, the type field is the first thing I would check, not the last.

The import, step by step

• Download the JSON from the component page.
• In WordPress, go to Templates, Theme Builder, and pick the Header tab.
• Use Add New, then the import arrow in the top corner, and choose your file. On current Elementor versions you can also import from Templates, Saved Templates; the type field routes it correctly either way.
• Open the imported header once in the editor and save. This regenerates its CSS on your install, which prevents the unstyled first render some people report.

Display conditions are not optional

A header template without display conditions shows nowhere. After importing, Elementor prompts you to set conditions; the usual choice is Entire Site. The prompts feel skippable and people skip them, which produces the second most common support message I receive. Set Entire Site, save, and hard refresh your front end.

Our navigation menus deserve a note. The menu widget inside a header references a WordPress menu by id, and your site's menu ids are not mine. After import, select the menu widget and point it at your own menu. The structure, spacing, and dropdown styling stay; only the link list is yours. This is also why I never pretend a header can ship with working links baked in; that content lives in WordPress, not in the JSON.

Sticky behavior and transparency

Sticky headers survive import because stickiness is a widget-level setting stored in the template. Transparent-over-hero designs need one extra step: the transparency effect assumes your page hero sits behind it, so check the header against a real page, not the editor canvas alone. I test every header in our library against a fixture page before it ships, and transparent variants are the ones that need the most local judgment.

For the full walkthrough with screenshots of each dialog, the header import guide stays updated as Elementor moves dialogs around. If you are building out the rest of the site frame, the footer templates follow the same rules with type set to footer.

What actually transfers, and what stays behind

People assume an imported header is a frozen copy of what they saw in the preview. It is closer to a recipe than a photograph. The structure transfers exactly: container layout, widget arrangement, spacing, sticky settings, breakpoints. The colors and fonts arrive by reference; our headers point at Global Styles slots, so an accent-colored button in the preview becomes your accent color at home. The parts that stay behind are the ones owned by WordPress rather than the template: menu contents, the logo, and any page the header links to.

The logo case is worth spelling out. Header templates use the site logo widget where possible, which reads whatever logo your site identity has set. If your logo lives only in your old theme's settings, set it under Site Identity and the imported header picks it up. When a header shows a placeholder image instead, that is a hardcoded image slot, and I rebuilt several early templates specifically to eliminate those.

When two headers collide

A question I get from every migration project: what happens to the header my theme already renders? If the theme is a classic one, the Elementor header replaces it wherever conditions match, and the theme header simply stops printing. If you run a header plugin alongside, disable one of them; two systems fighting over the same body class produces the double-header effect people screenshot in panic. My rule on client builds is one owner for the site frame. Decide that Elementor owns the header and footer, retire the alternatives, and the mental model stays simple for whoever maintains the site after you.

Give the mobile breakpoint a real test before calling the job done. Imported headers carry their responsive settings, but your logo proportions and menu length are unique, and a menu that fit the demo's four links may wrap awkwardly with your seven. Two minutes with the responsive preview catches it while the editor is still open.

FAQ

Why does my imported header show unstyled?

Open it once in the editor and save. That forces CSS regeneration on your install. It is a one-time step per template.

Can I import a header with free Elementor?

Theme Builder requires Elementor Pro. Our header templates are marked with a Pro badge for exactly this reason.

Do imported headers replace my theme's header?

Once display conditions are set, the Elementor header renders instead of the theme's header on matching pages. Remove the conditions and the theme header returns.

My menu shows the wrong links. Broken import?

No. The menu widget points at a WordPress menu id from the source site. Select the widget and choose your own menu; everything else is already in place.

What is your full checklist for a header going live?

The one I run on every build, in order. Import the file and confirm it landed under Theme Builder's Header tab, not saved templates. Open it once in the editor, point the menu widget at the site's real menu, confirm the logo widget reads Site Identity, and save to trigger CSS generation. Set display conditions to Entire Site unless a landing page needs excluding, and actually press publish on the conditions dialog rather than closing it. Hard refresh the front end logged out, because admin bars shift header offsets and hide sticky bugs. Scroll to verify sticky behavior and the transparent-to-solid transition if the design has one. Switch to a phone-width viewport and open the collapsed menu; count that every top-level item is reachable and the toggle contrast passes against your real background. Click the logo, click two menu links, and click the header's call to action, since a header that navigates wrong is worse than one that styles wrong. Finally, if the site had a previous header system, confirm it is fully retired so the two never stack. The whole pass takes under ten minutes and it has caught something on most sites I have run it against, usually the conditions dialog or the mobile menu.