iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
Fix WordPress formatting by first deciding whether the defect exists only in the editor or also on the published page. Save a copy of the affected block, try Attempt Block Recovery, then inspect the block’s HTML, move code into the correct block or stylesheet, and isolate theme or plugin conflicts on staging. This order repairs the least amount of content while preserving a reliable rollback.
Start by identifying what is actually broken
WordPress formatting problems fall into two different categories. An editor warning can be caused by a block’s stored markup even when visitors see a normal page. A live-site problem means the rendered HTML or CSS is wrong, regardless of whether the editor looks correct. Treating these as the same issue often makes the damage worse.
Recommended Free Tools
| What you see | Likely area | First check |
|---|---|---|
| “This block contains unexpected or invalid content” in the editor | Block markup no longer matches the block’s expected structure | Copy the block, then select Attempt Block Recovery |
| Code appears as text, or angle brackets disappear | Markup was entered in a visual paragraph or encoded for display | Decide whether the code is meant to run or merely be shown |
| The editor looks wrong but the published page is fine | Editor stylesheet scope or theme support | Inspect editor styles, theme.json, and editor-style registration |
| The editor looks fine but visitors see broken spacing, columns, or typography | Front-end CSS, missing core block styles, or a theme/plugin conflict | Inspect the live page and test a staging copy with components isolated |
WordPress.org describes an invalid-content message as appearing when the affected block contains a formatting problem. The same documentation lists malformed HTML, unexpected inline formatting, and theme or plugin interference as common causes. Do not start by deleting the block: the warning is often recoverable.
Protect the original before editing
Make a reversible copy before accepting a recovery or conversion. Select the affected block, open its options menu, and use the copy command; paste the result into a temporary draft, a staging page, or a plain-text document. If the block contains custom attributes or embeds, also copy its HTML from Edit as HTML. This gives you a way back if recovery removes a class, link, image, or nested block.
#1 Best Overall
- Used Book in Good Condition
- Work on staging or a duplicated draft when the page is important or heavily trafficked.
- Record the page URL, the block type, and the last known good revision.
- Do not deactivate production plugins or switch a live theme merely to test a theory.
Recover an “unexpected or invalid content” block
1. Try Attempt Block Recovery
- Select the block showing the warning.
- Choose Attempt Block Recovery.
- Read the repaired preview rather than accepting it automatically. Check text, links, images, alignment, classes, and spacing.
- Save a revision and view the page on the front end.
Recovery asks WordPress to reconcile the saved markup with the block’s current serialization rules. It is the least invasive option because it keeps the block type when the content can be brought back into the expected shape.
2. Use Resolve when recovery is wrong
If the preview changes content or still shows the warning, open the block’s three-dot menu and select Resolve. WordPress presents the differences and available actions. Compare the original copy you made with the proposed result before choosing one.
- Convert to Custom HTML: choose this when exact custom markup, data attributes, or hand-written structure matters more than block controls. You will manage that markup yourself afterward.
- Convert to Classic Block: choose this for legacy Classic Editor content or when the old editing model is the most faithful representation. It may remove block-native controls and styling options.
- Keep the existing block: use this only when you understand which changes will be discarded and have a backup.
Conversion is not a cure for invalid HTML. It changes how WordPress stores and edits the content, so inspect the resulting markup before publishing.
Inspect and repair the block’s HTML
Open the block menu and choose Edit as HTML (or use the code editor for the post). Look for the errors most likely to invalidate a block:
- An opening element with no matching closing element.
- Duplicated wrappers left behind after pasting from another site.
- Elements nested where the block does not permit them, such as a paragraph inside another paragraph.
- Inline CSS or attributes that the block does not support.
- Tags inserted by a visual editor, browser extension, or copied document.
Repair one structural problem at a time. Keep the block’s required wrapper and attributes, remove unsupported formatting, and switch back to the visual view to see whether the warning disappears. If the editor immediately recreates the warning, compare the generated HTML with a new block of the same type; the difference usually reveals the unsupported tag or attribute.
| Markup symptom | Why it causes trouble | Safer repair |
|---|---|---|
Unclosed <div>, <span>, or link tag |
The parser changes the block boundary and the saved serialization no longer matches | Close or remove the element, then validate the nesting |
Inline style on a paragraph block |
The block may reject unsupported inline styles | Use block design controls or a stylesheet; use Custom HTML only when the markup itself is intentional |
| Extra wrapper around a heading, image, or button | Unexpected children can fail block validation | Recreate the block and move only supported content into it |
| Legacy HTML pasted into a native block | Old markup may not serialize as the current block expects | Convert to Custom HTML or Classic Block after preserving a copy |
Put HTML and CSS in the correct context
When code should be displayed to readers
If the purpose is to show code, do not paste executable markup into a normal paragraph. Angle brackets must be escaped so the browser treats them as text. Use a Code or Preformatted block, or the semantic elements <code> and <pre>. For example:
Free tools Windows power users keep installed
One-click scans. No signup required.
<button class="notice">Save</button>The Classic Editor documentation explains that its visual editor encodes angle brackets for display, while the HTML editor leaves markup interpretable by the browser. That distinction determines whether a snippet is shown or executed.
When custom markup should run
Use a Custom HTML block for intentional HTML that visitors should receive, such as a small embed or a semantic element not represented by a core block. Keep the markup self-contained, close every tag, and verify it at the same viewport sizes as the rest of the page. Do not use a Custom HTML block as a dumping ground for a whole page’s CSS.
Where CSS belongs
Use the theme’s supported style controls for ordinary typography, color, spacing, and layout. Put reusable rules in the theme stylesheet or the appropriate global-style system. Inline styles are harder to maintain and can be rejected by a block or overridden by more specific rules. A rule that fixes one paragraph but changes every paragraph on the site belongs in a stylesheet, not in that block’s content.
Fix an editor that does not match the published page
The block editor does not load styles exactly like the classic editor or the front end. WordPress’s Block Editor Handbook notes that editor styles are scoped differently: selectors such as body are rewritten to target .editor-styles-wrapper. A stylesheet that works on the live page may therefore have no effect in the editor, and an editor-only rule may never reach visitors.
Rank #3
Check theme support and stylesheet registration
For classic themes, editor styling depends on theme support and the registered editor stylesheet. The relevant mechanisms are add_theme_support('editor-styles') and add_editor_style(). A minimal registration looks like this:
function example_theme_setup() {
add_theme_support( 'editor-styles' );
add_editor_style( 'style-editor.css' );
}
add_action( 'after_setup_theme', 'example_theme_setup' );Use the exact functions supported by your theme and test after each change. Do not paste PHP into the post editor. If you maintain a block theme, inspect its theme.json settings and styles instead of adding competing rules to every page.
Check selector scope
Compare the browser’s computed styles in the editor with those on the live page. A rule beginning with body .entry-content may not match the editor because the content is inside .editor-styles-wrapper. Conversely, a selector written only for .editor-styles-wrapper is editor-specific. Adjust the scope deliberately rather than increasing specificity at random.
Check style loading order
Block styles can be loaded as general editor styles, front-end styles, or view styles. The Block Editor Handbook distinguishes the editorStyle, style, and viewStyle contexts. A rule intended only for the visitor-facing page should not be assumed to affect the editor. A rule needed for editing must be enqueued in the editor context. Inspect the generated document and network panel to confirm that the expected file is present.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchRepair front-end layout and theme.json conflicts
If the editor is correct but visitors see a broken layout, inspect the published HTML and CSS first. Core block styles provide structural behavior for blocks; removing or overriding them can break columns, buttons, galleries, and spacing. In block themes, theme.json is the recommended place for global settings and styles. Duplicate rules in a custom stylesheet can conflict with those generated styles, especially when both define the same block supports.
- Open the live page in browser developer tools and identify the element whose size, display mode, or margin is wrong.
- Check which rule wins in the Styles and Computed panels.
- Confirm that the required core block stylesheet is loaded and not blocked by optimization or a conditional enqueue.
- Remove the duplicate or obsolete rule in the child theme, customizer, or plugin stylesheet.
- Make the smallest change that restores the intended layout, then test other pages using the same block.
A global style fix can affect every instance of a block. Test representative pages, not only the page where the problem was first reported.
Find a plugin or theme conflict without damaging production
WordPress documentation explicitly notes that a theme or plugin can interfere with the editor. The safest isolation sequence is controlled testing on staging or in a maintenance window:
- Create a staging copy and record the current active theme, plugins, WordPress version, and the affected page.
- Update WordPress, the theme, and plugins in staging. A compatibility fix may already exist.
- Test the page with all plugins active and the current theme. Confirm the symptom still occurs.
- Temporarily deactivate plugins in groups, starting with those that alter the editor, blocks, HTML filtering, optimization, or CSS. After each change, reload the editor and the front end.
- When the symptom disappears, reactivate the group members one at a time until the conflict returns.
- With the suspected plugin disabled, test a compatible default theme. If the problem remains, the plugin or content is more likely; if it disappears, inspect the theme’s styles or block registration.
- Check the suspect component’s settings, changelog, and compatibility notes. Keep the fix on staging until several representative pages pass.
This method identifies a conflict without assuming that the last installed component is guilty. Do not leave security, backup, or performance components disabled on a public site while testing.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Retest at real viewport sizes and clear caches last
After the markup and CSS are correct, check the repaired block at desktop and mobile widths. Pay attention to wrapped buttons, column stacking, image dimensions, heading overflow, and spacing around nested blocks. Test in a private browser window to avoid a logged-in editor preview masking a front-end problem.
Only then purge page, object, browser, or CDN caches. Clearing a cache cannot repair invalid markup; doing it first can hide whether the underlying change worked. If the old appearance returns after a purge, inspect whether an optimization layer is serving an outdated stylesheet or combining rules in an order different from staging.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Choose the least destructive fix
| Situation | Preferred action | Trade-off |
|---|---|---|
| Native block with a small serialization mismatch | Attempt Block Recovery | Preserves block controls, but the proposed repair must be checked for content changes |
| Custom attributes or exact hand-written markup must survive | Convert to Custom HTML | Preserves markup, but future editing is less guided and validation is your responsibility |
| Legacy Classic Editor content | Convert to Classic Block | Matches the old editing model, but reduces block-native controls |
| Editor-only style mismatch | Correct editor stylesheet scope or theme support | Requires theme-level work rather than a one-off content edit |
| Live-site layout failure | Inspect front-end CSS, core block styles, and theme.json |
A global correction may affect every page using that style |
| Problem appears only with a component enabled | Isolate the plugin or theme on staging | Requires controlled testing before a production change |
Use reversibility as a deciding factor. A staging revision and a copied block are safer than an irreversible conversion made directly on a published page.
Common symptoms and targeted fixes
The warning returns every time I save
A plugin, theme filter, or unsupported attribute may be rewriting the block on save. Compare the block’s HTML before and after saving, update components, and run the staging isolation sequence. If the content is intentionally custom, keep it in a Custom HTML block instead of forcing it into a native block schema.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsFormatting disappears when I switch from HTML to Visual view
The visual editor may remove markup it does not support, or the markup may be interpreted rather than displayed. Use supported block controls for ordinary formatting, a Custom HTML block for intentional markup, and escaped Code or Preformatted content for snippets.
Only one browser shows the problem
Test a private window and disable extensions that inject styles or modify text. If the defect is absent for other users and on another device, clear that browser’s cached assets after confirming the server response is correct.
Columns or buttons are broken after a theme update
Inspect whether core block styles and the theme’s generated styles are both loading, then compare the affected block with a new block on staging. Remove obsolete overrides rather than adding another high-specificity rule. Check the theme’s compatibility notes before rolling back.
The front end is fixed but the editor remains wrong
That is an editor-style scope problem, not a content problem. Verify editor-styles support, the file passed to add_editor_style(), and selectors that need to target .editor-styles-wrapper.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Prevent future formatting failures
- Keep WordPress, themes, and plugins updated, especially components that register blocks or filter post HTML.
- Use native block controls for routine formatting and reserve Custom HTML for markup that genuinely needs it.
- Store reusable design rules in the theme’s supported stylesheet or
theme.json, not repeated inline attributes. - Test updates on staging and keep page revisions or backups before major editor changes.
- When pasting from documents or websites, paste plain text first when the source carries unknown wrappers and styles.
- After a fix, test a new instance of the same block and at least one mobile width so the correction is not limited to one page.
When to escalate
Ask a WordPress developer or hosting support team for help when invalid content is recreated by a server-side filter, a theme’s block registration is malformed, or the issue persists with all plugins disabled and a compatible default theme. Provide the copied block HTML, the exact error text, the WordPress and component versions, the staging reproduction steps, and whether the defect is editor-only or visible to visitors. That evidence is more useful than a screenshot alone.
WordPress.org’s block-error documentation was updated June 22, 2026, and its central guidance remains practical: recover the block first, inspect the formatting problem, and consider theme or plugin interference. The Block Editor Handbook likewise emphasizes that editor styles work differently from classic-editor styles. Following those boundaries keeps a formatting repair focused, reversible, and testable.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
