Jonas Venn here. If you build WordPress sites the way I do—editor-first, lean, and without page builders—you know the ache of finishing a layout in the block editor only to hit preview and see a page that looks like it was interpreted by a different browser. Margins drift. Font sizes collapse. Spacer blocks misbehave. The trust you placed in the editor evaporates. Let’s fix that. We’re going to make the block editor output so close to the frontend that you stop checking preview and start shipping.
Why the Block Editor Betrays Your Layout
The block editor runs inside an iframe with its own stylesheet. That isolation is intentional—it prevents your admin theme from mangling content—but it also means the editor doesn’t inherit your theme’s frontend CSS unless you explicitly hand it over. The result: a heading that looks bold and tight in the editor sits loose and thin on the live page. A group block with a background colour you chose from the palette renders a shade you didn’t pick.
Three things usually cause the mismatch:
- Missing editor styles. Your theme’s
style.cssdoesn’t load inside the editor, so typography, spacing, and colour rules are absent. - Block-specific overrides. Core blocks ship opinionated frontend styles that the editor doesn’t mirror, like
.wp-block-coverpadding or.wp-block-quoteborder width. - CSS specificity gaps. Even when editor styles exist, they often lose to inline styles or block support defaults that the frontend treats differently.
Understanding those three lets you close the gap methodically instead of patching it with random CSS hacks before every launch.
Step 1: Enqueue a Real Editor Stylesheet
Stop relying on add_theme_support( 'editor-styles' ) alone. Most themes use it to pull in a trimmed-down editor-style.css that ships with outdated rules. Instead, build a dedicated editor stylesheet that imports the exact same design tokens your frontend uses.
Register it with add_editor_style() and point it at a file that loads your CSS custom properties, your reset or normalizer, and your typography scale. If your frontend uses a Google Font, enqueue it inside the editor with the enqueue_block_editor_assets action so the font-family matches. No more fallback serif in the editor while the frontend shows Inter.
function jv_editor_styles() {
add_editor_style( 'assets/css/editor.css' );
wp_enqueue_style( 'jv-editor-font', 'https://fonts.googleapis.com/css2?family=Inter:wght@400;600&display=swap', array(), null );
}
add_action( 'after_setup_theme', 'jv_editor_styles' );
add_action( 'enqueue_block_editor_assets', function() {
wp_enqueue_style( 'jv-editor-font' );
});Inside editor.css, keep the same :root block that defines your spacing variables, colour palette, and fluid type scale. The block editor respects custom properties if they’re loaded before the blocks render. This single change eliminates the worst of the visual drift.
Step 2: Tame Block Support Output with theme.json
WordPress 5.8 gave us theme.json, and it is the most reliable way to control block spacing, colour, and typography across both editor and frontend from one source. When you define settings.spacing.spacingScale or styles.typography.fontSizes in theme.json, the block editor generates consistent classes and inline styles that the frontend picks up verbatim.
The trick is to avoid mixing theme.json settings with legacy CSS overrides. Pick one lane. If you set a global content width of 720px in theme.json‘s layout section, don’t also set max-width on .entry-content in your stylesheet. The double declaration creates a race condition where the editor shows one width and the frontend another depending on load order. Let theme.json own layout widths, and use your stylesheet only for things theme.json can’t reach, like link hover states or form elements.
Block Gap Consistency
Block gap is the invisible spacing between sibling blocks, and it’s the most common source of editor-frontend mismatch after typography. In theme.json, define styles.spacing.blockGap with a value from your spacing scale. The editor reads it. The frontend renders it via the .wp-site-blocks > * + * selector that core outputs. If you overwrite that selector in your CSS with a different value, you break the parity. Audit your theme’s stylesheet for any rule that targets .wp-site-blocks spacing and delete it. Trust the generator.
Step 3: Register Block Styles That Travel
Custom block styles registered with register_block_style() are only half the story. The editor will show the style name and apply a class, but the frontend only gets the class if your theme’s CSS loads the corresponding rules. To make the preview trustworthy, write the CSS for your custom block style in the editor stylesheet as well.
Better yet, build block styles that use only the design tokens already available in the editor. A “framed” image style that adds a border should reference var(--wp--preset--color--border), not a hardcoded hex. When the colour palette shifts in theme.json, both sides update. That’s the kind of consistency that lets you build layouts without constantly clicking preview.
Step 4: Handle the Iframe Reality
The block editor iframe sandboxes content, which means global styles applied to the <body> or <html> elements won’t cascade into your blocks. If your frontend relies on a body class for background colour or font smoothing, the editor won’t see it. Use the editor-styles-wrapper class, which core applies to the iframe’s body, to replicate those global rules inside the editor stylesheet.
.editor-styles-wrapper {
background-color: var(--wp--preset--color--background);
-webkit-font-smoothing: antialiased;
font-family: var(--wp--preset--font-family--primary);
}Also watch for viewport-dependent units. The iframe width is narrower than the frontend viewport, so a vw-based font size or padding can look correct in the editor but blow out on a wide monitor. Stick with rem, em, or the fluid type scale from theme.json, which calculates based on container width, not viewport width.
Step 5: Audit Third-Party Blocks
A block from a plugin you installed six months ago is probably loading its own editor CSS and frontend CSS from different files. The developer may have tested neither against your theme. When a block consistently lies about its spacing, open the browser inspector on the editor iframe and on the frontend page side by side. Compare the computed box model. If the frontend shows extra padding from a plugin stylesheet, override it in your editor stylesheet with a selector scoped to that block’s class. You’re not fixing the plugin; you’re aligning the preview.
For a site that suddenly shows blank pages or broken layouts after a plugin update, the problem often starts with a missing template or a misrouted query. I wrote about diagnosing that exact scenario in What to Fix First When a New WordPress Site Says Nothing Found. The same methodical, layer-by-layer approach applies here: isolate the block, check its CSS source, and align the rules.
Step 6: Build a Visual Regression Habit
You don’t need a fancy tool. Before you publish a page, open two browser tabs: one with the block editor in fullscreen mode, one with the frontend preview. Resize both to the same width. Scroll through and look for alignment shifts, colour differences, or spacing anomalies. Make it part of your build checklist. After you do it ten times, you’ll start seeing patterns—a particular group block variant that always needs a margin reset, or a third-party button block that ignores your border-radius variable. Codify those fixes in your editor stylesheet so you never think about them again.
The End State: Trust the Editor
When the block editor matches the frontend closely enough, something shifts in your workflow. You design in the editor. You make spacing decisions in the editor. You check responsive behaviour by resizing the editor frame, not by opening a staging URL on your phone. The preview button becomes a final confirmation, not a debugging step. That’s the bar. It’s reachable with a disciplined editor stylesheet, a well-configured theme.json, and a refusal to let third-party CSS run unexamined.
FAQ
Why does my heading font look different in the editor even after I added editor styles?
Two common causes. First, the editor iframe may not be loading the font file because the @font-face declaration is only in your frontend stylesheet. Enqueue the font separately on the enqueue_block_editor_assets hook so the iframe can download it. Second, a core block style or a plugin stylesheet might be setting a different font-weight or letter-spacing inside the editor. Inspect the computed styles in the iframe to find the override and mirror it in your editor stylesheet.
How do I stop full-width cover blocks from breaking out in the editor?
Cover blocks use an inner container that responds to the theme’s content width. If your theme.json sets a layout.contentSize but the editor stylesheet doesn’t apply it to the iframe’s body, the cover block will render at the iframe’s edge instead of the intended wide width. Add the .editor-styles-wrapper class to your editor stylesheet and set its max-width to match your layout.contentSize. Then let the block’s own alignment styles handle the rest.
Can I use CSS Grid inside the block editor and expect it to match the frontend?
Yes, but you need to be explicit. The block editor’s iframe doesn’t strip CSS Grid, but it does reset some box-model properties. If your grid layout uses a gap value that relies on a CSS custom property, make sure that property is defined in the editor stylesheet’s :root block. Also test the grid inside the group block container, because the group block can add wrapper divs that affect direct-child selectors. When in doubt, apply the grid class to the outermost block container.
Why do spacer blocks show different heights in the editor versus the frontend?
Spacer blocks use inline styles for height, which normally match. But if your theme or a plugin applies a margin or padding to all blocks through a global CSS rule, the spacer block inherits it on the frontend while the editor iframe may not. Inspect the spacer on the frontend for extra vertical space coming from a parent selector. Then either remove the global rule or scope it to exclude spacer blocks specifically.