Gutenberg is more than an editor. While the editor is the focus right now, the project will ultimately impact the entire publishing experience including customization (the next focus area).

Discover more about the project.

Editing focus

The editor will create a new page- and post-building experience that makes writing rich posts effortless, and has “blocks” to make it easy what today might take shortcodes, custom HTML, or “mystery meat” embed discovery. — Matt Mullenweg

One thing that sets WordPress apart from other systems is that it allows you to create as rich a post layout as you can imagine — but only if you know HTML and CSS and build your own custom theme. By thinking of the editor as a tool to let you write rich posts and create beautiful layouts, we can transform WordPress into something users love WordPress, as opposed something they pick it because it’s what everyone else uses.

Gutenberg looks at the editor as more than a content field, revisiting a layout that has been largely unchanged for almost a decade.This allows us to holistically design a modern editing experience and build a foundation for things to come.

Here’s why we’re looking at the whole editing screen, as opposed to just the content field:

  1. The block unifies multiple interfaces. If we add that on top of the existing interface, it would add complexity, as opposed to remove it.
  2. By revisiting the interface, we can modernize the writing, editing, and publishing experience, with usability and simplicity in mind, benefitting both new and casual users.
  3. When singular block interface takes center stage, it demonstrates a clear path forward for developers to create premium blocks, superior to both shortcodes and widgets.
  4. Considering the whole interface lays a solid foundation for the next focus, full site customization.
  5. Looking at the full editor screen also gives us the opportunity to drastically modernize the foundation, and take steps towards a more fluid and JavaScript powered future that fully leverages the WordPress REST API.


Blocks are the unifying evolution of what is now covered, in different ways, by shortcodes, embeds, widgets, post formats, custom post types, theme options, meta-boxes, and other formatting elements. They embrace the breadth of functionality WordPress is capable of, with the clarity of a consistent user experience.

Imagine a custom “employee” block that a client can drag to an About page to automatically display a picture, name, and bio. A whole universe of plugins that all extend WordPress in the same way. Simplified menus and widgets. Users who can instantly understand and use WordPress — and 90% of plugins. This will allow you to easily compose beautiful posts like this example.

Check out the FAQ for answers to the most common questions about the project.


Posts are backwards compatible, and shortcodes will still work. We are continuously exploring how highly-tailored metaboxes can be accommodated, and are looking at solutions ranging from a plugin to disable Gutenberg to automatically detecting whether to load Gutenberg or not. While we want to make sure the new editing experience from writing to publishing is user-friendly, we’re committed to finding a good solution for highly-tailored existing sites.

The stages of Gutenberg

Gutenberg has three planned stages. The first, aimed for inclusion in WordPress 5.0, focuses on the post editing experience and the implementation of blocks. This initial phase focuses on a content-first approach. The use of blocks, as detailed above, allows you to focus on how your content will look without the distraction of other configuration options. This ultimately will help all users present their content in a way that is engaging, direct, and visual.

These foundational elements will pave the way for stages two and three, planned for the next year, to go beyond the post into page templates and ultimately, full site customization.

Gutenberg is a big change, and there will be ways to ensure that existing functionality (like shortcodes and meta-boxes) continue to work while allowing developers the time and paths to transition effectively. Ultimately, it will open new opportunities for plugin and theme developers to better serve users through a more engaging and visual experience that takes advantage of a toolset supported by core.


Gutenberg is built by many contributors and volunteers. Please see the full list in


How can I send feedback or get help with a bug?

We’d love to hear your bug reports, feature suggestions and any other feedback! Please head over to the GitHub issues page to search for existing issues or open a new one. While we’ll try to triage issues reported here on the plugin forum, you’ll get a faster response (and reduce duplication of effort) by keeping everything centralized in the GitHub repository.

How can I contribute?

We’re calling this editor project “Gutenberg” because it’s a big undertaking. We are working on it every day in GitHub, and we’d love your help building it.You’re also welcome to give feedback, the easiest is to join us in our Slack channel, #core-editor.

See also

Where can I read more about Gutenberg?


Mixed Feelings

I think I can see the potential in the blocks. But I also see plenty of things that really get in the way of efficiently writing and editing.

The way I use the editor to write and update posts always involves switching between the “Visual” and the “Text” mode – and it is particularly nice how clean and tidy the “Text” in the Classic Editor looks. The new features in Gutenberg bring so much complexity and clutter to some aspects of my daily workflow that it is simply not effective to use Gutenberg.

My main concern is the [gallery] shortcode. In the Classic Editor in Text mode, it is SO easy to update a gallery after uploading an image and editing it by simply copying & pasting the ID of the image into the list of ids in the gallery shortcode:

Screenshot: Gallery shortcode, Classic Editor, Text mode

By comparison, the HTML view in Gutenberg is an insane mess and the option to simply paste a media ID is gone:

Screenshot: Gallery, Gutenberg HTML view

What’s worse, there aren’t even any options to EDIT the gallery in Gutenberg. All that can be done is rearranging the images. No columns option, no layout option… and this is in version 3.5 of Gutenberg?!

At the very least, Gutenberg should be untied from WordPress 5.0 for now to take the pressure out of it. I’m hesitant to even save one single post created with Gutenberg because there’s no easy way back (as far as I can see).

I work with galleries multiple times per day on a number of photography related websites, and Gutenberg turns my workflow into a click-orgy, or plainly breaks it.

So far so good!

I’m loving it so far! Its very user-friendly and greatly helps those first-timers/beginners. And you can access the coding too just like the original editor for advanced users.

Though what I didn’t like about drag-and-drop builders is that they use blocks and google adsense automated ads can’t insert in between those blocks or in between the texts in the posts. They can only insert either on the very top of the post or at the end of the post.

I have yet to try automated ads with Gutenberg and I really hope it allows the insertion of ads in-between blocks automatically just like with the classic editor.

5 stars since it looks like it

Never Release It

I usually love change and advancement. I’m all for trying something new and I welcome anything that makes posting more enjoyable. This Gutenberg editor, however, is change, minus the advancement. Oh, it’s fancier, but twice as hard to use and far more complicated than it should ever be. The simplest thing to do on WordPress is WRITE. This editor takes something incredibly simple and makes it almost impossible to do. This is not advancement at all. Never release this. Do not include it by default in the next upgrade. This editor is maddening; maddening I say. I shouldn’t have to read detailed instructions just to figure out how to write a sentence. Rethink this editor. Ask yourselves how this editor will be for a complete newbie to WordPress and then I think you’ll know whether you should move forward with releasing it or go back to the drawing board.


I was excited when I first saw it because I thought WordPress had finally introduced a proper WYSIWYG editor into the software to replace the minimalist editor that’s already there. Instead I found a cluttered, hard to use, and frankly unnecessary editor. This does nothing the average blogger or writer needs. It feels more like a half baked drag and drop page builder than a post editor. I cannot and will not use Gutenberg.

Very Concerned. Please make this optional, not mandatory

If the Classic editor is going to be optional and available via plugin, then why not just make the Gutenberg editor be the optional component, not the Classic Editor? I haven’t really heard any rational behind why this cannot be the roll out plan for v5.0 can you address this? Maybe there is a good reason for it that I am just not aware of. I was at WCUS last year, I heard Matt’s keynote, I get the reason behind why Gutenberg exists (competing with wix, evolving cms, better user experience, etc.). Other than working in conjunction with the customizer I am just not sure why it’s going to be baked in mandatory. Make it mandatory at anytime you want, that makes sense to me, just not on core.

Here is my situation:
I manage a large multisite installation for a University, we have several hundred websites on it. Almost all of the sites run a theme we built that uses a custom built page builder sort of thing built around ACF Pro with TinyMCE as the editor it’s sort of like Gutenberg but really locked down with a purposely very finite number of things you can do with it.

The thing we built really works great for our use, but Gutenberg doesn’t work with it AT ALL. We don’t allow our users via any GUI element to change things like colour options, font options, and column choices, etc. We have quite a few very specific page layouts and functional components such as accordions or tabbed content areas that people can use. We don’t give our users the ability to go crazy with building different kinds of colour combos or multi column pages. This approach helps us keep our brand adherence across our wide variety of sites managed by different levels of users. Brand adherence is a really big deal for us as I am sure it will be for other types of large organizations.

The thing is, I actually do quite like Gutenberg on my personal websites that I have away from work. In a “anything you want to do you can do” world its great, but for our situation at the University it doesn’t work, where we need to keep things tight and limit options, it’s actually bad and I can’t see it working any time in the future without a complete reworking of our sites which would require an absolutely enormous amount of work. We would have to remove most of what Gutenberg does. We would have to create custom page templates with pre-defined blocks, remove a bunch of the default blocks, make our own blocks, etc. etc. Tons and tons of planning and work.

Here’s the thing, if you make this optional and not mandatory I think it’s possible that the amount of sites that would enable the Gutenberg option could eventually be greater than the amount of people that will enable the Classic Editor option if Gutenberg was made mandatory. And if it were optional, and you folks at Automattic were monitoring the percentages of Gutenberg to Classic Editor, when you start to get close to that tipping point where more people have adopted Gutenberg than the CE, maybe a little way in the future, in like WP version 5.3 then talk about making it mandatory, with the Classic Editor the option. That makes sense to me, and I would like to hear your thoughts on that Tammy @karmatosed Matt @matt Matias @matveb and Joen @joen.

Also, if Gutenberg was mandatory it would get a four star rating from me, there are currently lots of bugs but it’s actually pretty decent, just should be optional by default.

Not Needed At All

No need to change out the editor in WordPress. If you want to use this plugin just use the plugin but DO NOT include it as the new editor for WordPress in the upcoming release.

Read all 960 reviews

Contributors & Developers

“Gutenberg” is open source software. The following people have contributed to this plugin.


“Gutenberg” has been translated into 31 locales. Thank you to the translators for their contributions.

Translate “Gutenberg” into your language.

Interested in development?

Browse the code, check out the SVN repository, or subscribe to the development log by RSS.



  • Add an edit button to embed blocks to modify the source.
  • Improve margin collapse within column blocks.
  • De-emphasize inline tokens within the inserter for a better user experience.
  • Polish focus and active styles around buttons and inputs.
  • Polish styles for checkbox component, update usages of toggle to checkbox where appropriate. Update documentation.
  • Improve pre-publish panel styling and textual copy.
  • Prevent duplicate DotTips from appearing.
  • Integrate “queries data” into the entities abstraction for data module.
  • Hide block movers if there are no blocks before and after.
  • Initial improvements for responsive image handling in galleries.
  • Use correct color for primary button bottom border.
  • Allow transitioning post status from scheduled to draft.
  • Improvements for auto-completer keyboard interactions.
  • Place strikethrough formatting button after link as it’s less important.
  • Resolve issue with preview sometimes opening redundant tabs.
  • Align timepicker with calendar on pre-publish panel.
  • Expand date filter select box width within media library.
  • Constrain media blocks to content area width in front-end.
  • Reapply box-sizing to slider thumbs.
  • Avoid showing line separator in block settings menu when it’s the last item.
  • Introduce additional keyboard shortcuts to navigate through the navigateRegions component.
  • shift+alt+n to go to the next region.
  • shift+alt+p to go to the previous region.
  • Replace all withAPIData usage and deprecate the higher-order component.
  • Add persistence via data plugin interface.
  • Introduce new redux-routine package for synchronous generator in data module.
  • Move embed API call out of block and into data module.
  • Remove no longer needed workaround targeted at resolving a TinyMCE error.
  • Abort selection range set on unset range target. Resolves an issue when merging two empty paragraph blocks created while at the end of an inline boundary.
  • Removing or merging RichText should only trigger if the selection is collapsed:
  • Fix issue with backspace not working as expected when deleting text content from the first block.
  • Fix case where paragraph content could move to previous paragraph when deleted.
  • Remove provisional block behaviour to improve reliability of various interactions.
  • Restore horizontal edge traversal implementation to address issue where pressing Backspace may not place the caret in the correct position if within or after a RichText field.
  • Ensure Gutenberg is disabled when editing the assigned blog posts page.
  • Initialize the Autosaves controller even if revisions are disabled. Fixes several bugs around saving with revisions turned off.
  • Display warning when Cloudflare blocks REST API requests.
  • Improve validation for attribute names in serializer.
  • Add Slot to block menu settings for extensibility.
  • Fix File Block center align behavior.
  • Fix behaviours when deleting on an empty RichText field.
  • Fix parent-dropdown missing for custom post-types.
  • Fix import style statements in ColorIndicator.
  • Fix height of used-once block warning.
  • Fix link for innerBlocks docs.
  • Fix link to server-side-render component.
  • Fix race condition with DomReady.
  • Fix awkward capitalisation in demo post content.
  • Fix warning for unrecognised forwardedRef prop.
  • Fix regression with URL input focus box.
  • Fix error in custom HTML preview when block is empty.
  • Fix colspan bug in table block for tables with thead tags.
  • Fix issue with image inspector controls disappearing once an image block is set to wide/full alignment.
  • Fix issue when image size remains blurry if manually set to a smaller size (i.e., medium) and then changed alignment to wide/full.
  • Fix issue with meta boxes being absent when script enqueued in head depends on wp-edit-post.
  • Resolve an issue where removing all text from a Button block by backspace would cause subsequent text changes to not be accurately reflected. Broader issue with TinyMCE inline elements as containers.
  • Avoid using remove() because it’s unavailable in IE11.
  • Address further feedback on duplicated DotTips implementation.
  • Update re-resizable to version 4.7.1 — fix image & spacer blocks resizing on IE.
  • Use a unique querystring package instead of three different ones.
  • Introduce filters to allow developers the ability to customize the Taxonomy Selector UI for custom taxonomies.
  • Introduce RichText component for mobile native and implement the Paragraph Block with it.
  • Use standard label for Alt Text input.
  • Consolidate similar i18n strings.
  • Remove title attributes from the Classic Editor warning.
  • Remove unused code in taxonomies panel.
  • Remove oEmbed fixture files.
  • Remove jQuery dependency from @wordpress/api-fetch.
  • Remove filler spaces from empty constructs.
  • Remove REST API shims for code introduced in WP 4.9.8.
  • Remove unused terms, taxonomies, and categories code.
  • Replace the apiRequest module with api-fetch module.
  • Add inline comment that explains a stopPropagation() within tips implementation.
  • Add gutenberg_can_edit_post filter.
  • Add watch support for stylesheets in packages.
  • Add JSDoc comment to Popover’s focus() method.
  • Add readme docs for all components.
  • Autogenerate documentation from readme files.
  • Add doc note about automatically applied attributes in save.
  • Add test for block mover.
  • Allow demo content to be translatable.
  • Update CSS selectors from :before to ::before.
  • Export the description for server-registered blocks.
  • Export getBlockTypes on react native interface.
  • Expose redux-routine to react native.
  • Expose unknown-type handler methods for mobile.
  • Specify missing wp-url dependencies.
  • Improve JS packages descriptions.
  • Downgrade Docker image version for WordPress for test validation.
  • Move CI back to latest WordPress version and bump minimum version to 4.9.8
  • Use @wordpress/compose instead of @wordpress/components.
  • Update docs for Button component.
  • Update package-lock.json.
  • Updated dependencies: jest, npm-package-json-lint and read-pkg-up.
  • Add Babel runtime dependency to redux routine.
  • Prevent Travis from running when changes are only made to .md files.
  • Add stylelint for SCSS linting.
  • Set babel dependencies to fixed version and add core-js2 support.
  • Trigger E2E test failure on console logging.
  • Update doc links to resources moved to packages folder.
  • Update api-fetch package documentation.
  • Update Lerna to 3.0.0-rc.0.
  • Generate source maps and read those from the webpack build.
  • Rewrite e2e tests using jest-puppeter preset.
  • Introduce a new Extending Editor document specific to editor filters.
  • Improve test configuration and mocking strategy.