WordPress Block Anatomy: What a Block Contains and Stores

A WordPress block has five practical parts. It has an identity, attributes, inner blocks, saved markup, and rendering behaviour. WordPress combines those parts into one editable content component.

The visible rectangle is only the editing surface. The important structure sits within saved post content and registered code. Understanding that split makes block problems easier to diagnose.

This guide describes anatomy, not block development. You will learn what exists and where. No JavaScript knowledge is required.

The five parts of a WordPress block

1. Identity

A unique registered name.

2. Attributes

Structured values for content and settings.

3. Inner blocks

Child components nested inside containers.

4. Markup

HTML saved between block boundaries.

5. Behaviour

Code controlling editing and output.

Not every block uses all five parts equally. A Paragraph relies heavily on saved markup. A Query block relies more heavily on runtime behaviour.

1. A block has a unique identity

Every registered block has a machine-readable name. The name contains a namespace and a short block name. A slash separates those pieces.

The core Paragraph block uses core/paragraph. A plugin uses its own namespace. That prefix prevents unrelated providers from claiming the same identity.

The identity connects saved content with registered code. WordPress finds the correct editor interface through that name. It also finds any server-side rendering callback.

People usually see a friendly title instead. The inserter says “Paragraph,” not core/paragraph. The technical name still governs compatibility underneath.

Renaming a registered block can therefore break old content. WordPress may no longer recognise the saved identity. Responsible developers preserve names across product updates.

2. Attributes hold structured values

Attributes describe the changing values within one block instance. They can hold text, numbers, booleans, arrays, or objects. Their declared schema defines acceptable types.

An Image block may track an attachment identifier and alternative text. A Columns block may track a column count. A custom table may track extensive row data.

Some attributes come from saved HTML. Others live inside the opening block comment. Developers choose storage based on the block’s design.

The official attributes reference documents sources and types. It also explains parsing from text, HTML, and element attributes.

Changing an attribute updates the editor’s in-memory block record. Saving serialises that new state into post content. The database does not receive every keystroke immediately.

Attributes are not arbitrary database options. They belong to a particular block occurrence. Two Image blocks can therefore hold different identifiers and captions.

3. Inner blocks create nested structure

Container blocks can hold other blocks. Those children are called inner blocks. Their order and nesting create the document tree shown in List View.

A Columns block contains individual Column blocks. Each Column can contain paragraphs, images, buttons, and more. A Group can wrap almost any collection.

Inner blocks remain real blocks with separate identities. The parent does not flatten them into one setting. Editors can still select and change each child.

Parents can restrict permitted children. They can also provide a starting template. These rules shape editing without changing WordPress’s general nesting model.

Deep nesting increases selection difficulty and frontend markup. Use containers for meaningful relationships. Avoid adding wrappers merely to chase visual adjustments.

4. Saved markup preserves visible content

Many blocks save HTML inside post_content. A Paragraph saves a paragraph element containing its text. WordPress places block comments around that HTML.

The comments identify boundaries without appearing on the page. Browsers ignore them during normal display. WordPress reads them when rebuilding the editing tree.

For example, an opening comment identifies a Paragraph block. Its paragraph HTML follows. A closing comment marks the end of that block.

This arrangement gives static content a useful fallback. The saved HTML can remain readable when supporting JavaScript disappears. Styling may still change or disappear.

Not every block saves complete output. Dynamic blocks can save only identity and attributes. Their frontend HTML gets generated during a request.

That rendering distinction deserves its own decision guide. Here, remember one principle. Saved markup and visible output are sometimes different objects.

5. Registered code supplies behaviour

Registered code tells WordPress how the block edits and renders. It also declares names, icons, categories, styles, supports, and asset files. The detail lives in block styles vs block variations.

Modern blocks commonly declare metadata inside block.json. WordPress can read that shared contract on both servers and browsers.

The official metadata reference recommends server registration from this file. That approach enables optimised asset loading and consistent declarations.

Editor code creates controls and previews. Frontend scripts may add interaction. Server code may calculate output, permissions, or database queries.

These layers can fail independently. A block might display correctly but edit poorly. Another might edit correctly while frontend scripts fail.

Registered definitions and saved instances differ

A registered definition describes one block type. A saved instance represents one placement within content. Confusing those levels creates incorrect assumptions.

Installing a plugin can register ten block types. Adding one block creates one instance. Duplicating that block creates another instance with separate attributes.

Updating the plugin changes the shared definition. It may affect every saved instance. Editing one instance normally changes only that placement.

Styles can complicate this boundary. Shared CSS affects many instances without changing stored attributes. Global style changes can do the same.

Where exactly does WordPress store blocks?

WordPress stores the serialised block document in the post’s post_content field. This applies to posts, pages, and other block-enabled content types.

The document mixes HTML with special block comments. Comment attributes use JSON-like data. Inner blocks appear between their parent’s opening and closing boundaries.

Some plugins also use post metadata or custom database tables. Those stores can support specialised features. They are not the standard block document itself.

Media files remain in the Media Library. A block commonly stores their identifiers or URLs. Deleting an Image block does not automatically delete its attachment.

Reusable design assets can live elsewhere. Patterns, templates, and global styles have their own ownership. Their blocks still follow familiar structural concepts.

What is not necessarily stored inside the block?

• The final computed CSS can come from WordPress, themes, or plugins.
• Responsive behaviour can come from external stylesheets.
• Interactive behaviour can depend on separately loaded JavaScript.
• Database results can be fetched during frontend rendering.
• Global design defaults can live within theme settings.
• Attachment files remain separate from their referencing blocks.

This separation explains many mismatches. The database can preserve content while presentation changes. It can also preserve settings while required code vanishes.

Content, settings, and styles can all become attributes

The word “attribute” sounds narrower than its real job. Attributes can represent content, configuration, presentation, or references. Their purpose depends on each block’s contract.

A heading’s text is content. Its level is structural configuration. Its chosen colour is presentation. All three values can influence the saved block.

WordPress also provides standard style attributes through block supports. These may cover spacing, colours, borders, and typography. Themes decide whether many related controls appear.

Not every visible control creates a new attribute. Some controls change existing values. Others change editor state without affecting saved content.

A selected-block toolbar is not part of the content. List View expansion is not content either. Those interface states can vanish safely after closing the editor.

This distinction helps during troubleshooting. Ask whether the missing thing was content, presentation, or temporary interface state. Then inspect the corresponding layer.

How block changes travel from control to page

1. An editor selects one saved block instance.
2. A control displays the instance’s current attribute value.
3. The editor chooses or enters a new value.
4. The block requests an attribute update.
5. The canvas rerenders its preview from current state.
6. The editor marks the overall post as changed.
7. Saving serialises every accepted change into the document.
8. The frontend later reads that saved state.

Frontend output may use saved HTML or fresh server rendering. The control path remains conceptually similar. Attributes connect editing choices with eventual output.

Preview errors can therefore originate at several stages. The control may save incorrectly. Serialisation may fail. Rendering or styling may then misread correct data.

Change one layer during each test. Small experiments reveal ownership faster. They also protect correct content from unnecessary repairs.

How WordPress rebuilds the editing canvas

1. WordPress loads the saved post_content document.
2. The parser recognises block comments and their boundaries.
3. It creates an ordered tree of block records.
4. Registered definitions provide editing interfaces for recognised names.
5. Attributes populate the appropriate content and controls.
6. Inner blocks appear beneath their parent components.
7. The editor tracks changes within an in-memory state.
8. Saving serialises the updated tree back into content.

The WordPress data-flow guide documents this unidirectional cycle. Blocks receive attributes and request changes through defined actions.

This architecture enables undo, redo, autosaves, and dirty-state warnings. It also explains why invalid markup triggers editor notices.

Why does block validation fail?

Static blocks compare saved markup with their current expected output. Unexpected differences can trigger an invalid-content warning. WordPress then offers recovery choices.

Manual HTML edits can cause differences. Plugin updates can change expected markup. Filters, formatting tools, or migrations can also alter saved content.

An invalid notice does not automatically mean lost content. Preview the frontend first. Then compare recovery, conversion, and restoration options on staging.

Do not press recovery across many pages blindly. A repair can discard unsupported details. Backups and representative testing remain essential.

What happens after a block plugin is disabled?

The saved identity remains inside post content. WordPress cannot provide the normal editor without registration. It may show an unsupported or missing block.

Saved static HTML may still appear publicly. Plugin styling and scripts may disappear. Dynamic blocks may lose their entire visible output.

Results vary by block, not merely by plugin. Test a paragraph-like block and interactive block separately. Record both frontend and editor behaviour.

Our deactivation guide provides a practical exit test. Run it before adopting any large block library.

How to inspect a block without coding

1. Create a disposable draft on a staging site.
2. Insert the block and add realistic content.
3. Open List View and inspect its nesting.
4. Change one setting and observe the visual result.
5. Use the editor’s code view carefully.
6. Find the opening comment and registered name.
7. Check whether readable HTML sits between boundaries.
8. Preview the post before and after plugin deactivation.
9. Restore the plugin before continuing other tests.

Never conduct this test first on production. Deactivation can affect every instance immediately. Staging keeps the experiment contained and reversible.

What makes block anatomy portable?

Readable saved HTML improves graceful degradation. Modest nesting eases migration. Standard elements also help browsers, feeds, exports, and accessibility tools.

Provider-specific attributes can reduce portability. Dynamic output increases code dependence. Custom databases can make complete migration more complicated.

Dependence is not automatically harmful. A useful dynamic feature needs active code. The important requirement is understanding and pricing that dependence honestly.

Choose blocks by their weakest acceptable state. Ask what readers see after failure. Then ask what editors can recover without specialist help.

Frequently asked questions

The verdict

Good anatomy makes blocks understandable and recoverable. WP Block Suite keeps specialised content inside WordPress’s shared editor. Test the free plugins first. Then compare the $299 lifetime suite when several Pro tools fit.