The Editor Looks Different From The Site

The block editor is a working preview, not a pixel promise: it arranges your blocks in the theme's styles, but the front end adds behaviour and context the editor does not run. When the two differ, the difference almost always belongs to one of the causes below, so check them in order rather than assuming a defect.

JavaScript Runs On The Front End

Sliders, carousels, counters, filters and every scroll-driven behaviour are powered by front-end JavaScript, and the editor shows their static arrangement instead of running them. A carousel lays its items out as a strip you can scroll sideways in the editor, where every item stays selectable and editable, and animates on the site: both surfaces doing their job. Judge motion and interaction on the published page, not in the canvas.

The shared Animation panel is the sharpest case: a block with an entrance animation plays it on the front end when it scrolls into view, so the block's position and timing can only be judged live. The same goes for the Scroll Effects panel's parallax and fades.

The Chrome Is On The Canvas, With Two Exceptions

A page opens inside its template, so the header, the footer, the content wrapper and the slider or hero the page assigns are all on the canvas while you edit. If you are looking at the content alone, Show template is turned off in the page's Template panel, which is a preference of yours rather than a fault; turn it back on to see the page dressed.

Two things still differ from the front end. A header built in the Header Builder and an assigned Footer record are swapped in as the page is served, so the canvas draws the theme's own header and footer template part instead of that record: edit the record on its own screen and check the result on the site. And the chrome decides part of its own appearance out there. A transparent header renders in its solid scheme on a page with nothing sitting under it, no hero, no assigned slider and no title band pulled up behind the bar, and that check runs on the front end, so the editor and the Site Editor still preview the transparent version.

The License State Gates Premium Output

Premium blocks follow the license: on a site with no active license they do not render on the front end, and an administrator sees a notice in their place while visitors see nothing. A block that is visible in the editor and absent from the page is the signature of exactly this. Check Canvas > License and see License Problems.

Caching Serves Yesterday's Page

A page cache, a CDN or an optimisation plugin can keep serving the page as it was before your edit, which reads as "the editor has my change and the site does not". Clear the site's cache and hard-reload the browser before investigating anything else, because this cause is the cheapest to eliminate.

Pitfalls

A section is invisible on the front end but present in the editor. Check three suspects in order: an entrance animation waiting for the section to scroll into view, a premium block on an unlicensed site, and a visibility utility class left in the block's Additional CSS class(es).

The menu shows an instruction row in the editor that is not on the site. A Canvas Header Navigation block with no menu assigned draws "Assign a menu in the block settings" while you edit, because that row is a message for you rather than for a visitor. The front end renders an empty menu in its place, so assign a menu and both surfaces fill.

Fonts differ between editor and site. The editor loads the theme's fonts, but a font registered by an imported demo applies through that demo's styles, so compare on the front end of a demo-styled page before changing typography settings.

Spacing differs at the page edges. The page template and its content wrapper are on the canvas, so edge spacing usually matches. Per-page layout classes are a different matter: they are applied as the page is served, so a page that overrides its wrapper that way is best judged on the preview.

Was this page helpful?