Block Editor Doesn't Match the Front End: Why the Preview Lies, and How to Fix It

The mismatch, described by the people who edit

Editors notice this before developers do, because they live in the editor. They write a post that looks right, publish it, and find the live page has different spacing, fonts or widths. Or the opposite: the editor looks plain and unstyled, so they guess at sizes and the live page comes out oversized. Either way, the preview stops being a preview, and every edit needs a second trip to the front end to check.

• Fonts in the editor fall back to a default serif or sans-serif instead of the theme's typography.
• Content width differs: narrower or full width in the editor, something else live.
• Wide and full alignment options are missing from image and group blocks.
• Colors in the palette do not match the theme's colors, or custom CSS classes look unstyled.
• Theme styles leak into the editor's own interface, such as link resets or missing paragraph spacing.

These have been reported against real themes. An OceanWP user found the editor falling back to a serif font instead of the theme typography. A Neve user on 4.2.4 reported editor styles not loading after WordPress 7, which staff could not reproduce. Hello Elementor threads include 'Gutenberg style is not loading'. Bricks users have seen theme styles leaking into the editor, removing paragraph spacing.

Where the editor gets its styles

The front end loads whatever the theme and plugins enqueue: style.css, generated CSS, plugin files and anything printed in the page head. The editor does not load all of that. It loads WordPress's own editor styles, block styles, and only the theme styles the theme explicitly sends to it. Every mismatch comes down to a style that reaches one side and not the other.

Block themes: theme.json keeps both sides honest

In a block theme such as Twenty Twenty-Five, Twenty Twenty-Four or Ollie, colors, fonts, spacing and content widths are declared in theme.json, and WordPress generates matching CSS for the editor and the front end from that one file. Twenty Twenty-Four does not enqueue a front-end theme stylesheet at all. So when a block theme's editor disagrees with its front end, the cause is almost always something added on top: custom CSS in a child theme's style.css, a plugin stylesheet, or a block style written for one side only.

Check by finding where the differing style is defined. Inspect the element on the live page, note the stylesheet that sets the rule, and see whether that file loads in the editor. Users coming from classic themes often put CSS in the wrong place; Twenty Twenty-Five's support forum has questions about exactly that. Moving custom styles into theme.json or the Styles panel makes them apply on both sides. See Twenty Twenty-Five CSS not updating, Ollie layout broken and Twenty Twenty-Four layout broken.

Classic themes: the opt-in editor stylesheet

A classic theme has to send its styles to the editor deliberately. WordPress's theme handbook shows add_editor_style() called on the after_setup_theme hook, and classic themes also need add_theme_support('editor-styles'). WordPress then adapts those rules for the editor canvas, rewriting body selectors to target the editor's wrapper. A theme that skipped this, or sends an old, thin editor stylesheet, shows an editor that looks nothing like the site.

Customizer settings add a second gap. Astra prints its Customizer CSS inline on the front end; Kadence adds its dynamic CSS inline to its global stylesheet; GeneratePress caches its dynamic CSS in the database. Whether that CSS is also printed in the editor depends on each theme's code, and after an update it sometimes is not. Width is a third: classic themes must declare wide alignment support, or the wide and full options never appear. Storefront enqueues a dedicated editor stylesheet, and its 4.6.2 release made the editor respect the browser's default font size, which shows how specific these fixes are.

Builder pages were never meant to match

If a page was built in Elementor, Divi, Avada or Bricks, the block editor is the wrong window. Builder pages are designed and previewed in the builder, and their CSS loads on the front end. Opening them in the block editor shows raw blocks, shortcodes or a single builder placeholder. Avada's documentation says a page made in Gutenberg cannot be edited with Avada Builder and vice versa. Bricks asks per page whether WordPress or Bricks renders it.

Block plugins sit in between. Kadence Blocks, Spectra, GenerateBlocks and Otter style their own blocks in both places, but a version mismatch after an update can leave blocks marked invalid; see Kadence Blocks invalid content and GenerateBlocks layout broken after an update. Old WPBakery content is a separate story: moving WPBakery to the block editor.

Bringing the editor back in line

1. 1

   Identify the theme type

   If Appearance shows Editor, it is a block theme and theme.json is the source of truth. If it shows Customize, it is classic and needs an editor stylesheet.

2. 2

   Find the differing rule

   Inspect the same element in the editor and on the live page. Note which stylesheet sets the font, width or color on each side.

3. 3

   Update theme and plugins

   Update the theme, block plugins and WordPress on staging. Several editor-style faults were fixed in theme releases.

4. 4

   Move custom CSS

   In a block theme, move rules into theme.json or the Styles panel. In a classic child theme, add them to an editor stylesheet loaded with add_editor_style().

5. 5

   Check width settings

   Confirm theme.json content and wide sizes, or the classic theme's wide alignment support, match the front end.

6. 6

   Test with plugins off

   On staging, disable plugins to see whether one injects styles into the editor, as with builder styles leaking in.

7. 7

   Clear caches and compare

   Clear caches, reload the editor without its cache, and compare a test post side by side.

If the editor is not just unstyled but refusing to save, that is a different fault: see publishing failed or updating failed. Styles that change only after a delay belong in CSS changes not showing.

Keeping the editor honest after updates

Put design decisions where both sides can see them: theme.json for block themes, a maintained editor stylesheet for classic themes. Keep one-off CSS out of the Customizer's Additional CSS when editors need to see it. After every WordPress release, open a test post with headings, buttons, an image and a wide group block and compare it to the live page. WordPress major releases change the editor more than anything else on the site.

Our theme customization team writes proper editor styles for classic themes, and our theme developer service builds block themes with theme.json from the start. See also the Kadence block editor review and GeneratePress with the block editor.

When editing should not need a second window

The block editor tries to show the page as visitors will see it, but on WordPress the page is styled by a theme, a builder, block plugins and the Customizer, each deciding separately what reaches the editor. Owners end up publishing to find out what they wrote. That gap is the real cost.

Athena CMS takes a different route: plain fields for content, a real preview before anything goes live, and every version kept, with the layout itself held in one tested Next.js codebase rather than split across a theme and plugins. It comes with a custom site, which costs more to build than a theme. Compare the editing experience in WordPress vs Next.js vs Athena CMS and Athena vs WordPress. More symptoms live in the troubleshooting hub.