Block Spacing and Layout

Where block spacing actually comes from: not the block you are editing, but the layout rules a block theme declares in theme.json — content width, wide width, and a default block gap that every container inherits unless it overrides it. Inconsistent spacing almost always means those rules are missing, contradictory, or being overridden per block instead of fixed once — though a control that won't save at all is an editor problem, not a layout one.

The layout system: content, wide, full

A block theme defines two widths under its layout settings: a content width, which is how wide ordinary text and most blocks run, and a wide width, which is a looser boundary for blocks explicitly set to "wide" alignment. Both are CSS values, commonly expressed with min() so the layout also respects the viewport on small screens.

A block with no alignment set sits inside the content width. "Wide" pushes it out to the wide width. "Full" ignores both and runs edge to edge. These three states are why the same paragraph and the same image can occupy visibly different columns on one page — someone chose different alignments, and the theme's width values decide how far each one actually extends. If a theme never defines these values, the editor falls back to browser and core defaults, which is one reason a page can look fine in the editor and cramped or unexpectedly wide on the front end.

Block gap

Block gap is the space WordPress inserts between blocks inside a container automatically, driven by a blockGap setting in theme.json and rendered as a CSS custom property. It is not margin added by each block; it is a single value applied by the container to the space between its children, similar to gap in CSS flexbox or grid, because under the hood it frequently is exactly that.

This matters for two reasons. First, block gap can be set globally and then overridden per block or per group, so a page with inconsistent vertical rhythm often has one section that set its own gap and never got adjusted when the global value changed. Second, disabling block gap for a container without providing an alternative is a common cause of blocks appearing jammed together, since there is then no spacing mechanism doing the work at all.

Margin, padding, and which blocks expose them

Not every block ships with spacing controls. Container blocks — Group, Row, Stack, Cover — almost always expose padding and sometimes margin in the block's Styles or block-supports panel. Simple content blocks such as Paragraph or Heading typically expose margin only, if anything, because their vertical spacing is meant to come from block gap rather than per-block settings.

This split explains a frequent complaint: "I can't find a padding option on this block." If a block was not built with spacing support declared in its block.json, no such control exists, and the fix is to wrap it in a Group and pad the group instead of hunting for a setting that was never added.

Constrained versus flex layouts

WordPress containers use one of two layout types. A constrained layout stacks children vertically and centres each one inside the content or wide width — this is the default for Group and for the post content area itself. A flex layout arranges children in a row or column with no automatic width constraint, which is what powers Row and Stack.

The practical difference: put a full-width image inside a constrained Group and it still gets centred and capped unless you explicitly set it to full width. Put the same image inside a flex Row and it behaves like any flex item, sized by its own width and the row's alignment settings, with no automatic centring against the content column. Choosing the wrong layout type for a container is a common source of "why is this the wrong width" reports that have nothing to do with the block itself, as covered in more depth in what is a block in WordPress.

Why a full-width block overflows

A block set to full width is meant to break out of the content column and reach the edges of the viewport. Overflow happens when something between the block and the viewport edge still has left or right padding or margin applied — a parent Group with horizontal padding, for instance, contains the full-width child inside its own box, so the child can only reach the edges of that box, not the actual screen edge.

The other common cause is a fixed-width element inside the full-width block: an image with an explicit pixel width, or a table that will not shrink, forcing horizontal scroll on narrow screens. This is the same category of layout instability that shows up in how to fix cumulative layout shift in WordPress — a dimension that does not respond to the container causes visible shifting or scrollbars once real content loads.

Fixing spacing at the theme level

Adjusting spacing block by block does not scale and does not survive edits by other authors. The durable fix lives in the theme, set through theme.json or the site editor's Styles panel: set consistent contentSize and wideSize values, define a spacing scale so editors pick from a fixed set of steps rather than arbitrary pixel values, and set a sensible default block gap so most containers need no manual override at all.

Reserve manual per-block spacing for genuine exceptions — a hero section that needs less padding than everywhere else — rather than as the default way of getting a page to look right. When a theme's own layout values are wrong, customising a WordPress theme at the theme.json level fixes every page that uses that container, instead of one page at a time. If the site is not on a block theme at all, these controls will be partial or absent, and it is worth confirming with what is a WordPress block theme before chasing settings that may not exist.

Common mistakes

• Fighting layout with custom CSS instead of theme.json. Overrides in custom CSS stack on top of inline block styles and get harder to trace with every addition.
• Setting spacing per block instead of at the container. Padding belongs on the Group or Row, not repeated across every child.
• Disabling block gap without a replacement. Removes the only mechanism creating vertical space, and blocks collapse into each other.
• Nesting a full-width block inside a padded container. The child cannot reach the viewport edge and visibly overflows or clips instead.
• Assuming every block has padding controls. Simple content blocks often do not; wrap them in a Group.

Verify

Open a page on the front end, not just the editor preview, and check spacing at both mobile and desktop widths, since content and wide widths behave differently below their breakpoints. Inspect a full-width block in browser dev tools and confirm no ancestor is constraining it with padding or a fixed width. If CSS is not loading at all, spacing will look broken for reasons unrelated to layout settings — rule that out first before adjusting theme.json.