What Is the WordPress Block Editor? A Plain-English Guide

The WordPress block editor builds posts and pages from separate, movable content units. Each paragraph, image, heading, list, or layout becomes its own block. You edit those blocks visually, while WordPress stores structured content underneath.

WordPress made this editor the default with WordPress 5.0. Its development name was Gutenberg. That name still appears in searches, plugins, and technical discussions.

The running term here is “block editor”. It describes the product better. Gutenberg is a project name; blocks are the daily working model.

What does the block editor replace?

The older Classic Editor presented one large writing field. Formatting buttons sat above that field. Images, shortcodes, and HTML lived inside the same document stream.

That approach worked well for articles. Complex layouts required shortcodes, custom fields, or separate page builders. Editing structure often meant editing invisible instructions.

The block editor makes structure explicit. A heading is a Heading block. An image is an Image block. A two-column section contains Columns and Column blocks.

You can select, move, duplicate, group, or remove each unit. Changes stay scoped to that block. The surrounding content usually remains untouched.

The Classic Editor still exists through a plugin. Some established workflows still need it. New sites should begin with blocks unless a dependency says otherwise.

What is a WordPress block?

A block is a named content component with content, settings, and rendering rules. The editor knows what that component represents. It can therefore offer controls designed for that exact job.

A Paragraph block offers text formatting and typography. An Image block offers alt text, dimensions, and cropping. A Group block organises other blocks and controls their shared layout.

Blocks can contain other blocks. WordPress calls those nested components inner blocks. This creates layouts without turning the whole page into one proprietary object.

WordPress includes blocks for common publishing tasks. Plugins can register more. Themes influence how every block looks and which design controls appear.

The official block documentation describes three visible parts. Most blocks have editable content, a toolbar, and sidebar settings. Their exact controls vary.

What does the editor workspace contain?

The workspace has four practical areas. Learn those areas before exploring individual blocks. The interface becomes much less mysterious.

1. The canvas

The centre canvas holds your page or post. Click any block to edit it. Type a forward slash to search available blocks quickly.

The canvas tries to resemble the published page. Theme editor styles improve that resemblance. The frontend remains the final source of truth.

2. The top toolbar

The top toolbar contains the inserter, undo, redo, document overview, and publishing controls. It also opens preview and editor preferences.

Selected blocks can show another toolbar nearby. A preference can pin that toolbar overhead. Neither option changes the saved content.

3. List View

List View exposes the page structure as a tree. Nested Groups, Columns, and blocks become easy to select. Complex pages are nearly unmanageable without it.

You can drag blocks within that tree. You can also collapse entire sections. Meaningful anchor names make repeated editing much faster.

4. The settings sidebar

The sidebar switches between document settings and selected-block settings. Document settings include categories, excerpts, publication dates, and featured images.

Block settings control the selected component. They may include colour, spacing, typography, dimensions, behaviour, or advanced attributes. Theme support affects what appears.

Canvas

Write, insert, select, and arrange visible blocks.

Toolbar

Insert, undo, preview, save, and publish.

List View

Navigate the document tree and nested structures.

Sidebar

Change publication data or selected-block settings.

What can you build with core blocks?

Core blocks cover more work than many buyers expect. Blogs, documentation, landing pages, and brochure sites can stay entirely native.

Text blocks handle paragraphs, headings, quotations, lists, code, and tables. Media blocks handle images, galleries, audio, video, files, and covers.

Layout blocks include Groups, Rows, Stacks, Columns, and spacing controls. Theme blocks display navigation, queries, post data, and site information.

Patterns combine several blocks into reusable starting layouts. Synced patterns update every connected placement. Ordinary patterns create independent copies instead.

Core does have limits. Rich tables, specialised galleries, sliders, and schema-heavy content often need plugins. Our core-only test maps those gaps honestly.

How does WordPress store block content?

WordPress still stores post content in the familiar post_content field. Blocks do not require a separate page-layout database. The editor serialises its block tree into compatible content.

Special HTML comments mark each block boundary. Those comments can also hold attributes. Static blocks commonly save their frontend HTML between the comments.

Dynamic blocks may save only a comment and attributes. WordPress then generates their output during requests. Some blocks combine saved HTML with dynamic enhancement.

The official data-flow reference explains this cycle. WordPress parses saved content into blocks, edits them in memory, then serialises them again.

This storage model supports normal WordPress exports and revisions. It also keeps much static content readable outside the original editor. Dynamic features still depend on their provider.

Is the block editor a page builder?

It can build pages, but its architecture differs from proprietary builders. The editor belongs to WordPress core. Themes and plugins extend a shared block system.

Traditional page builders often supply their own editing runtime and storage assumptions. Their layouts depend heavily on that product. Blocks aim for a common platform.

That does not make blocks automatically faster or safer. Plugins can still load excessive assets. Themes can still create lock-in. Implementation quality remains decisive.

The practical comparison covers storage, performance, workflows, and exit cost. Read our blocks-versus-page-builders guide before planning a migration.

Is the block editor the Site Editor?

No. The block editor usually edits one post or page. The Site Editor edits templates, template parts, navigation, and global styles.

The two interfaces share block controls. Their scope differs. A Paragraph inside a post changes that post. A template change can affect hundreds of posts.

The Site Editor requires a block theme. Classic themes can still use blocks inside content. They simply keep PHP-based templates outside the Site Editor.

This distinction prevents expensive mistakes. Always check whether you are editing content, a pattern, or a template. The save screen should name the affected objects.

What are the block editor’s main advantages?

Content becomes easier to rearrange

Moving one section no longer means selecting fragile text ranges. List View shows the complete structure. Groups keep related blocks together.

Controls match the content type

Image settings belong to images. Heading levels belong to headings. Editors see relevant choices without scanning one enormous formatting toolbar.

Reusable systems become native

Patterns package trusted layouts. Global styles create consistent design defaults. Block locking protects structure while leaving real content editable.

Plugins share one editor

Different block plugins can register components inside the same interface. You do not need another complete page builder for each specialised feature.

What are the real limitations?

Selection can frustrate beginners. Nested containers make clicking the intended block difficult. List View solves much of that problem, after someone discovers it.

Editor previews are imperfect. Theme styles, caching, scripts, and responsive behaviour can differ on the frontend. Important pages still need real previews.

Core blocks prioritise broad usefulness. Specialised workflows can feel shallow. That gap created the block-plugin market, including the products we sell.

Design freedom can also undermine consistency. Unrestricted colours and spacing invite one-off decisions. Themes, patterns, and permissions must provide sensible boundaries.

Finally, blocks do not erase technical ownership. Dynamic blocks need active code. Theme templates still shape presentation. Updates can still introduce regressions.

How should a beginner start?

1. Create a private draft, not a production landing page.
2. Add paragraphs, headings, images, lists, and buttons.
3. Open List View and inspect the resulting structure.
4. Group related blocks, then move the whole Group.
5. Try Row, Stack, Columns, and spacing controls.
6. Preview the page at desktop and mobile widths.
7. Save one useful section as an ordinary pattern.
8. Add plugins only after a real requirement remains blocked.

Do not begin by installing five block libraries. Learn core vocabulary first. Otherwise, every plugin makes the same basic concept look unrelated.

Also avoid building the homepage first. Choose an ordinary article or service page. Mistakes become cheap, visible, and easy to reverse.

Which blocks should you learn first?

Start with Paragraph, Heading, List, Image, Buttons, Group, Row, Stack, and Columns. Those blocks teach content, hierarchy, and layout.

Learn Spacer last, if ever. Gap and padding usually create more consistent spacing. Repeated Spacer blocks often hide a weak layout system.

Learn Details before installing a simple accordion. Learn the core Table before buying a table plugin. Free native capability deserves the first attempt.

Then identify the first genuine gap. A richer table, gallery layout, slider, or schema component may justify extension. Name the job before choosing software.

What does a reliable block workflow look like?

A reliable workflow separates writing, structure, design, and final checking. Mixing every decision together makes simple pages feel difficult.

Begin with an outline using Heading blocks. Add plain paragraphs below those headings. Ignore colours, borders, and decorative spacing during this stage.

Next, group sections that belong together. Use List View to confirm the nesting. Containers should describe real layout relationships, not merely fix random spacing.

Apply approved styles only after the content works. Reuse existing patterns wherever possible. A familiar section usually beats a new one-off design.

Then preview the frontend. Check desktop and narrow screens. Test links, buttons, headings, images, and keyboard navigation before publishing.

Finally, inspect the save summary. WordPress may list posts, templates, and styles together. Save only the objects you intended to change.

How do blocks affect everyday publishing?

Writers can insert media without memorising HTML. Editors can move complete sections without rebuilding them. Designers can provide patterns instead of lengthy formatting instructions.

Those benefits require shared rules. A team needs approved colours, spacing, patterns, and heading practices. Otherwise, blocks simply make inconsistency easier to create.

Permissions also matter. Authors rarely need every design control. Locking structure can protect layouts while leaving words and images editable.

Reusable sections need clear ownership. Ordinary patterns create detached copies. Synced patterns keep connected copies. Template changes have even broader reach.

Choose the smallest scope that solves the problem. Local content belongs in a post. Repeated content may belong in a pattern.

Site-wide structure usually belongs in a template. Site-wide visual defaults belong in global styles. That ownership model prevents surprising changes.

When should you add a block plugin?

Add a plugin after confirming core cannot meet a named requirement. “More blocks” is not a requirement. A sortable pricing table is.

Test the candidate on staging. Build one realistic example. Measure its frontend assets and inspect what remains after deactivation.

Check its update history, support process, and licence terms. Confirm that its controls fit your team. A powerful block can still create editorial friction.

Avoid overlapping libraries without a clear reason. Duplicate blocks confuse writers and expand testing. One deliberate toolkit is easier to govern.

The weak case for another plugin is occasional decoration. Core blocks and small CSS changes may suffice. Prefer fewer dependencies when outcomes match.

Frequently asked questions

The verdict

The block editor becomes useful when real requirements outgrow core. WP Block Suite covers content, tables, galleries, and sliders. Try every free version first. Then compare the $299 lifetime suite when several categories need Pro.