I’m a WordPress user and, if you’re anything like me, you always have two tabs open when you edit a post: one with the new fancy pants block editor, aka Gutenberg, and another with a preview of the post so you know it won’t look wonky on the front end.
It’s no surprise that a WordPress theme’s styles only affect the front end of your website. The back end posy editor generally looks nothing like the front end result. We’re used to it. But what if I said it’s totally possible for the WordPress editor nearly mirror the front end appearance?
All it takes is a custom stylesheet.
Mind. Blown. Right? Well, maybe it’s not that mind blowing, but it may save you some time if nothing else. 🙂
WordPress gives us a hint of what’s possible here. Fire up the default Twenty Twenty theme that’s packaged with WordPress, fire up the editor, and it sports some light styling.

This whole thing consists of two pretty basic changes:
- A few lines of PHP in your theme’s
functions.php
file that tell the editor you wish to load a custom stylesheet for editor styles - Said custom stylesheet
Right then, enough pre-waffle! Let’s get on with making the WordPress editor look like the front end, shall we?
Step 1: Crack open the functions.php file
OK I was lying, just a little more waffling. If you’re using a WordPress theme that you don’t develop yourself, it’s probably best that you setup a child theme before making any changes to your main theme. </pre-waffle>
Fire up your favorite text editor and open up the theme’s functions.php
file that’s usually located in the root of the theme folder. Let’s drop in the following lines at the end of the file:
// Gutenberg custom stylesheet
add_theme_support('editor-styles');
add_editor_style( 'editor-style.css' ); // make sure path reflects where the file is located
What this little snippet of code does is tell WordPress to add support for a custom stylesheet to be used with Gutenberg, then points to where that stylesheet (that we’re calling editor-style.css
) is located. WordPress has solid documentation for the add_theme_support
function if you want to dig into it a little more.
Step 2: CSS tricks (see what I did there?!)
Now we’re getting right into our wheelhouse: writing CSS!
We’ve added editor-styles
support to our theme, so the next thing to do is to add the CSS goodness to the stylesheet we defined in functions.php
so our styles correctly load up in Gutenberg.
There are thousands of WordPress themes out there, so I couldn’t possibly write a stylesheet that makes the editor exactly like each one. Instead, I will show you an example based off of the theme I use on my website. This should give you an idea of how to build the stylesheet
for your site. I’ll also include a template at the end, which should get you started.
OK let’s create a new file called editor-style.css
and place it in the root directory of the theme (or again, the child theme if you’re customizing a third-party theme).
Writing CSS for the block editor isn’t quite as simple as using standard CSS elements. For example, if we were to use the following in our editor stylesheet it wouldn’t apply the text size to <h2>
elements in the post.
h2 {
font-size: 1.75em;
}
Instead of elements, our stylesheet needs to target Block Editor blocks. This way, we know the formatting should be as accurate as possible. That means <h2>
elements needs to be scoped to the .rich-text.block-editor-rich-text__editable
class to style things up.

h2.rich-text.block-editor-rich-text__editable {
font-size: 1.75em;
}
I just so happened to make a baseline CSS file that styles common block editor elements following this pattern. Feel free to snag it over at GitHub and swap out the styles so they complement your theme.
I could go on building the stylesheet here, but I think the template gives you an idea of what you need to populate within your own stylesheet. A good starting point is to go through the stylesheet for your front-end and copy the elements from there, but you will likely need to change some of the element classes so that they apply to the Block Editor window.
If in doubt, play around with elements in your browser’s DevTools to work out what classes apply to which elements. The template linked above should capture most of the elements though.
The results
First of all, let’s take a look at what the WordPress editor looks like without a custom stylesheet:

Let’s compare that to the front end of my test site:

Things are pretty different, right? Here we still have a simple design, but I’m using gradients all over, to the max! There’s also a custom font, button styling, and a blockquote. Even the containers aren’t exactly square edges.
Love it or hate it, I think you will agree this is a big departure from the default Gutenberg editor UI. See why I have to have a separate tab open to preview my posts?
Now let’s load up our custom styles and check things out:

Well would you look at that! The editor UI now looks pretty much exactly the same as the front end of my website. The content width, fonts, colors and various elements are all the same as the front end. I even have the fancy background against the post title!
Ipso facto — no more previews in another tab. Cool, huh?
Making the WordPress editor look like your front end is a nice convenience. When I’m editing a post, flipping between tabs to see what the posts looks like on the front end ruins my mojo, so I prefer not to do it.
These couple of quick steps should be able to do the same for you, too!
Check out how we have it for building landing pages at CodePen:
This is really great. Would be very great if themes of the future would do just that. Let the backend editor make an accurate preview. Really nice work!
Wow pretty close!
This is one of those things that feels great when you get a chance to do it but can be hard to sell to management/clients without being able to show them. Hopefully this article can be used to back up devs’ arguments when they try to get extra time for styling the editor!
So you have to develop two style sheets, one for front end one for back end. Double work nightmare. I prefer to disable Gutenberg and use classic editor. Advanced custom fields for anything clever. Preview and test in the draft or preview. Nothing wrong with that. If you want a visual editor why not use divi or elementor, or another cms that offers that.
This is great and super simple. Wanted to do this to my theme but thought it requires a lot of backend work.
I’m thinking the same thing. If my theme grows big enough this might be a good alternative to ditch elementor altogether especially after seeing the images posted in another comment in this article.
I use different SASS files for different theme parts. That makes it super easy to include the ones needed in the editor.css. Literally no manual work needed to have the proper styles on both frontend and in the editor.
It’s a shame the implementation prevents the use of REM units. It would be much easier to use.
Did not work for max-width. I was able to change the size of h2, but could not divine the right tags to use the full width of the editing area after a good deal of experimentation. I tried copying in the whole stylesheet for style-editor.css, changed all instances of max-width. Nothing. I’ve been able to do this in the past with other similar function codes and files, but twentytwentyone is not cooperating.
I feel you saved my life.
I just updated my blogs to WordPress 5.8 (while I was about to publish a post ♀️), and the way I had it (with a Child Theme for twenty twenty without touching the functions file) stopped working.
Thank goodness I came here!
BTW, do you have any idea why did it stop working? I was only using the editor-style-block.css from twenty twenty… and it worked like a charm, ’till today.
You’re the best!
Thank you!