by Chris Coyier & Jeff Starr

WordPress Default CSS Styles

Posted by on

WordPress gives us full control over the presentation of our websites. We specify which classes and attributes to use in our template files, and then apply CSS using our theme’s custom stylesheet. Behind the scenes, WordPress generates its own classes and IDs, and applies them to specific HTML elements in theme files and database content. Having these default hooks available makes it super-easy to custom-style your theme’s blockquotes, post images, widget items, and much more.

In addition to generating default classes for your site’s “front-end” (public-facing) pages, WordPress also employs a default set of CSS attributes for the Admin, or “back-end” pages. If you’ve ever delved into the convoluted CSS stylings of the WordPress Admin, you will understand why we focus exclusively on front-end attributes in this article. The goal is to include all classes and IDs generated for database content, theme template files, and default widget items.

Fortunately, most (if not all) of your WP CSS work happens at the “theme” or “post” level. And when you do need to style the Admin, it’s usually easiest to just do it en bloc via plugin. You can also do it the old-fashioned way.

Different Types of Default WordPress Styles

In this DiW post, we assemble and dissect as many of the default front-end WordPress CSS attributes that we could find. It turns out there are many more automatically generated classes and IDs than you probably realize, including those for more commonly styled elements such as the following:

  • Images included via WordPress’ WYSIWYG Post Editor
  • Image captions and galleries included via the WYSIWYG Post Editor
  • The body_class() and post_class() template tags
  • WordPress’ automatic “smilies”
  • WordPress’ default widgets

Some of these features are used quite frequently, while others not so much. It’s a good idea to cover your bases for these items, especially when producing publicly available themes. By including some basic styles for key CSS attributes, you ensure a more complete and rewarding experience for your theme’s users (and their users as well).

Fortunately, not all of WordPress’ default CSS attributes require explicit styling. Many default classes and IDs are generated and included as a matter of convenience. Conversely, there some core styles that are essential for public themes. So to organize things, we have two somewhat arbitrary types of default attributes, “essential” or “optional” – and here they are now:

Essential WordPress Styles

These are default WordPress attributes that should be styled with CSS:

Optional WordPress Styles

These are default WordPress attributes that should be styled only when needed:

For each of these sections, we’ll review the associated functionality and then present the default CSS styles generated and output by WordPress. It is ultimately up to you to decide the best approach for dealing with these default styles. If nothing else, it is wise to provide styles for WordPress’ WYSIWYG Editor items and perhaps widgets, if enabled. This is functionality that users typically employ while working with their site.

For all of these CSS attributes, we are merely presenting the selectors devoid of any preset styles. Only the styles for the WYSIWYG Editor are included, mostly because they are styled according to the WordPress Codex. Everything else is entirely up to you.

[ ^ ] WordPress CSS – WYSIWYG Editor Styles

When you are working with WordPress’ WYSIWYG Editor in the Edit Post screen, WordPress applies context-specific CSS attributes to certain elements when they are included in your post. For example, when inserting images, you can specify whether the images are floated left, right, or even centered. To do this, WordPress applies classes such as alignleft, alignright, or aligncenter. Without defining styles for WordPress’ default hooks, images and other elements may not display as intended.

Thus, at a bare minimum, if you are building a theme that will be used by the general public, it is wise to include the following basic styles for the items attributed via the WYSIWYG Editor:

/* == WordPress WYSIWYG Editor Styles == */

.entry-content img {
	margin: 0 0 1.5em 0;
.alignleft, img.alignleft {
	margin-right: 1.5em;
	display: inline;
	float: left;
.alignright, img.alignright {
	margin-left: 1.5em;
	display: inline;
	float: right;
.aligncenter, img.aligncenter {
	margin-right: auto;
	margin-left: auto;
	display: block;
	clear: both;
.alignnone, img.alignnone {
	/* not sure about this one */
.wp-caption {
	margin-bottom: 1.5em;
	text-align: center;
	padding-top: 5px;
.wp-caption img {
	border: 0 none;
	padding: 0;
	margin: 0;
.wp-caption p.wp-caption-text {
	line-height: 1.5;
	font-size: 10px;
	margin: 0;
.wp-smiley {
	margin: 0 !important;
	max-height: 1em;
blockquote.left {
	margin-right: 20px;
	text-align: right;
	margin-left: 0;
	width: 33%;
	float: left;
blockquote.right {
	margin-left: 20px;
	text-align: left;
	margin-right: 0;
	width: 33%;
	float: right;
.gallery dl {}
.gallery dt {}
.gallery dd {}
.gallery dl a {}
.gallery dl img {}
.gallery-caption {}

.size-full {}
.size-large {}
.size-medium {}
.size-thumbnail {}

Lots of good stuff there, but no predefined styles for some of the Gallery items, such as .gallery dl and .size-thumbnail, as seen near the end of the list. Also, if you are using reset styles for margins and padding, you can strip out quite a few rules from this default set.

Quick Tip: an easy way to ensure that everything is looking great is to simply create a test post in which you include each of the WYSIWYG items. Then include this set of default styles and fine-tune as desired.

As with most everything else WordPress-related, for more information on these default WordPress styles, check out the Codex. The default selectors above basically define CSS styles for images, captions, galleries, blockquotes, and smilies &ndash: in other words, all of the items that you can include using WordPress’ built-in WYSIWYG Editor.

[ ^ ] WordPress CSS – Miscellaneous Styles

After styling the essentials, you may also want to keep an eye out for these miscellaneous WordPress classes:

/* == WordPress CSS - Miscellaneous Styles == */

/* category links */
 li.categories {}  
 li.cat-item {}
 li.cat-item-{id} {}
 li.current-cat {}
 li.current-cat-parent {}
 ul.children {}

/* blogroll links */
.linkcat {}
.blogroll {}

/* read-more links */
.more-link {}

Not all of them are going to be used in every theme, but they are used quite commonly, especially the .read-more class, which is frequently used for archive, category and tag pages. It may be wise to anticipate their presence to ensure that nothing is going to break your theme’s design. Also, for more information on the category-links template tag, visit the WP Codex: wp_list_categories.

[ ^ ] WP CSS – Page Listings

If you are using WordPress’ built-in page-listing functionality provided by the wp_list_pages() and wp_page_menu() template tags, there are a variety of items that should be styled. These may look like a lot of work, but once you get the pattern down, it goes pretty quickly. Hopefully the following list will prove a useful reference during your next page-list styling session:

/* == WP CSS - Page Listings == */

.pagenav {}               /* outermost list item */
.page_item {}             /* any page item */
.page-item-{id} {}        /* specific page id */
.current_page_item {}     /* current page */
.current_page_parent {}   /* parent of current page */
.current_page_ancestor {} /* any ancestor of current page */

.pagenav ul,
.pagenav .current_page_item ul,
.pagenav .current_page_ancestor ul,
.pagenav .current_page_ancestor .current_page_item ul,
.pagenav .current_page_ancestor .current_page_ancestor ul,
.pagenav .current_page_ancestor .current_page_ancestor .current_page_item ul,
.pagenav .current_page_ancestor .current_page_ancestor .current_page_ancestor ul {}

.pagenav  ul ul,
.pagenav .current_page_item ul ul,
.pagenav .current_page_ancestor ul ul,
.pagenav .current_page_ancestor .current_page_item ul ul,
.pagenav .current_page_ancestor .current_page_ancestor ul ul {}
.pagenav .current_page_ancestor .current_page_ancestor .current_page_item ul ul, 
.pagenav .current_page_ancestor .current_page_ancestor .current_page_ancestor ul ul {}

Again, the easiest way to understand this spaghetti is to create a list by including wp_list_pages() in a theme template file, and define a big red border (or whatever) for each declaration block. Check the results and you should quickly recognize the pattern. For more information on the template tags used to generate these rules, go to Codex:

You may also want to check out some delicious recipes for WordPress page navigation, which provide everything you need to create the perfect page navigation menus for your website. </hype>

[ ^ ] WordPress CSS – Default WordPress Widgets

There are literally thousands of widgets available to WordPress users, but there is a handful of very common widgets that are frequently used with widgetized themes. If you are planning on widgetizing your theme, you should include some styles for some of the more popular widgets. Many of the widgets included with the retiring Kubrick theme have become very common, if not expected:

[ Kubrick Widgets ]

As the theme designer, you will decide which (if any) widgets to include in your theme, so you will know exactly which styles to apply. Here are the generic rules for some of the more common WordPress widgets:

/* == WordPress CSS - Default WordPress Widgets == */

.widget {}

/* links widget */
.widget_links {}
.widget_links ul {}
.widget_links ul li {}
.widget_links ul li a {}

/* meta widget */
.widget_meta {}
.widget_meta ul {}
.widget_meta ul li {}
.widget_meta ul li a {}

/* pages widget */
.widget_pages {}
.widget_pages ul {}
.widget_pages ul li {}
.widget_pages ul li a {}

/* recent-posts widget */
.widget_recent_entries {}
.widget_recent_entries ul {}
.widget_recent_entries ul li {}
.widget_recent_entries ul li a {}

/* archives widget */
.widget_archive {}
.widget_archive ul {}
.widget_archive ul li {} 
.widget_archive ul li a {}
.widget_archive select {}
.widget_archive option {}

/* tag-cloud widget */
.widget_links {}
.widget_links li:after {}
.widget_links li:before {}
.widget_tag_cloud {}
.widget_tag_cloud a {}
.widget_tag_cloud a:after {}
.widget_tag_cloud a:before {}

/* calendar widget */
.widget_calendar {}
#calendar_wrap {}
#calendar_wrap th {}
#calendar_wrap td {}
#wp-calendar tr td {}
#wp-calendar caption {}
#wp-calendar a {}
#wp-calendar #today {}
#wp-calendar #prev {}
#wp-calendar #next {}
#wp-calendar #next a {}
#wp-calendar #prev a {}

/* category widget */
.widget_categories {}
.widget_categories ul {}
.widget_categories ul li {} 
.widget_categories ul ul.children {}
.widget_categories a {}
.widget_categories select{}
.widget_categories select#cat {}
.widget_categories select.postform {}
.widget_categories option {}
.widget_categories .level-0 {}
.widget_categories .level-1 {}
.widget_categories .level-2 {}
.widget_categories .level-3 {}

/* recent-comments widget */
.recentcomments {}
#recentcomments {}
#recentcomments li {}
#recentcomments li a {}
.widget_recent_comments {}

/* search widget */
#searchform {}
.widget_search {}
.screen-reader-text {}

/* text widget */
.textwidget {}
.widget_text {}
.textwidget p {}

That’s obviously a lot of work for any designer, but there are many similar elements that would probably look best with matching styles. For example, instead of multiple declarations for list elements such as .widget_archive ul li, .widget_pages ul li, and .widget_recent_entries ul li, we can simplify by combining them into a single declaration, for example:

.widget_pages ul li,
.widget_archive ul li,
.widget_recent_entries ul li {}

In other words, when it comes to styling widgets, there’s a lot of repetition that may be consolidated and streamlined in your stylesheet. As you apply styles for WordPress’ default widgets, keep an eye out for exploitable selector patterns and similar styles that may be combined to save time and effort.

[ ^ ] WordPress CSS – Comment Styles

Styling comments is the bane of WordPress theme designers, especially when threaded/nested comments are enabled. The deeper they go, the more time you’re going to spend with them, but thankfully WordPress makes things a little easier by providing plenty of precise CSS hooks. Of course, if threaded comments are disabled, there is no need to bother with most of these classes. But when they are used, many of the following selectors should define style:

/* == WP CSS - Comment Styles == */

.commentlist .reply {}
.commentlist .reply a {}

.commentlist .alt {}
.commentlist .odd {}
.commentlist .even {}
.commentlist .thread-alt {}
.commentlist .thread-odd {}
.commentlist .thread-even {}
.commentlist li ul.children .alt {}
.commentlist li ul.children .odd {}
.commentlist li ul.children .even {}

.commentlist .vcard {}
.commentlist .vcard cite.fn {}
.commentlist .vcard span.says {}
.commentlist .vcard img.photo {}
.commentlist .vcard img.avatar {}
.commentlist .vcard cite.fn a.url {}

.commentlist .comment-meta {} 
.commentlist .comment-meta a {}
.commentlist .commentmetadata {}
.commentlist .commentmetadata a {}

.commentlist .parent {}
.commentlist .comment {}
.commentlist .children {}
.commentlist .pingback {}
.commentlist .bypostauthor {}
.commentlist .comment-author {}
.commentlist .comment-author-admin {}

.commentlist {}
.commentlist li {}
.commentlist li p {}
.commentlist li ul {}
.commentlist li ul.children li {}
.commentlist li ul.children li.alt {}
.commentlist li ul.children li.byuser {}
.commentlist li ul.children li.comment {}
.commentlist li ul.children li.depth-{id} {}
.commentlist li ul.children li.bypostauthor {}
.commentlist li ul.children li.comment-author-admin {}

#cancel-comment-reply {}
#cancel-comment-reply a {}

These are all of the classes and IDs that I could find, and they all seem to be pretty self-explanatory, especially after using them a few times. Even so, consider the collection a work in progress. As new information is discovered, the list will continue to improve (hypothetically speaking). Many of these selectors target markup elements generated via WordPress’ built-in wp_list_comments() template tag. Even when using a custom callback function for your comments loop, many of these CSS classes will be available for your styling convenience.

[ ^ ] WordPress CSS – body_class()

As of version 2.5, WordPress provides the body_class() template tag, which is included in the <body> element of your theme’s markup. When included, this tag outputs a variety of context-dependent class names that facilitate styling different types of page views. We talk more about body_class() here and here, but for now, let’s look at the different classes WordPress generates for this powerful tag:

/* == WP CSS - body_class() == */

.rtl {}
.home {}
.blog {}
.archive {}
.date {}
.search {}
.paged {}
.attachment {}
.error404 {}
.single postid-(id) {}
.attachmentid-(id) {}
.attachment-(mime-type) {}
.author {}
.author-(user_nicename) {}
.category {}
.category-(slug) {}
.tag {}
.tag-(slug) {}
.page-parent {}
.page-child parent-pageid-(id) {}
.page-template page-template-(template file name) {}
.search-results {}
.search-no-results {}
.logged-in {}
.paged-(page number) {}
.single-paged-(page number) {}
.page-paged-(page number) {}
.category-paged-(page number) {}
.tag-paged-(page number) {}
.date-paged-(page number) {}
.author-paged-(page number) {}
.search-paged-(page number) {}

As you can see, these classes enable us to easily target elements on any specific type of page. For example, if you want to customize the presentation of your search results, you could define your styles using the .search-results class. This flexibility offers greater control over the granular construction of your WordPress theme. For more information on the body_class() tag, check out the WordPress Codex.

[ ^ ] WordPress CSS – post_class()

As with body_class(), the post_class() template tag outputs a variety of context-dependent class names for your posts. The post_class() tag makes it easy to target and style specific posts and post-types, as well as posts from specific categories or tags. Here are the different class names automatically generated by post_class():

/* == WP CSS - post_class() == */

.post-id {}
.post {}
.page {}
.attachment {}
.sticky {}
.hentry {}
.category-misc {}
.category-example {}
.tag-news {}
.tag-wordpress {}
.tag-markup {}

Again, these classes seem pretty self-explanatory, but if anyone happens to know the definition of the .hentry class, it would be nice to know – I couldn’t find anything, and sadly didn’t take time to test. Basically, these classes enable you to define styles for specific types of posts, attachments, stickies, categories and tags. You can also include your own classes to post_class(), and even include current category IDs. For more information on the post_class() tag, check out the WordPress Codex.

Call for updates

So what’s missing? Notice any errors? I did my best to research everything and organize everything as accurately as possible, but this turned out to be a bit more insane than I had planned, and so there is definitely room for improvement. If you see anything that is inaccurate or incomplete, please advise in the comments. It would be great to fine-tune a complete reference for all of WordPress’ default CSS styles and hooks all in one place.

27 Responses

  1. Wow , that`s alot of work .

    Awesome job Jeff , definitely it`s very useful thanks

  2. Fantastic list, though, considering WordPress uses a hooks and filters plugin system, the title of this post might be a tad misleading :)

    That said, it’s a very, very good post into WordPress default CSS !

    • That’s a good point. Do you think I should rename the article to just “WordPress Default CSS Styles”? It would seem to make more sense..

  3. How can the admin style and author be different including replies ?

    I have this:

    background-color: #4d535f;
    color: white;


    The problem comes in the replies, admin comments become authors color.

    Is there a way to have admin comments in a specific color, no matter the depth of it ?


    • curtismchale May 24, 2010

      You could just make it more specific by adding li.bypostauthor or the id from the main comment list.

      • Not working adding li, can you please post an example of how it should be ?

        The idea is that the admin has its color always, when he is an author, when he replies, when he just comment, always the same color.

        And authors their own color as well.


  4. Good job putting this article together. I’m hoping to make good use of it soon :D

  5. Thanks Jeff, good article. This list is very deceiving though because most of these will be handled by the cascading effect in CSS. The widgets are definitely a gotcha though! I will start paying way more attention to those.
    thanks again

  6. Great! This post needs to be in my reference of WordPress :). Thanks for sharing Jeff!

  7. This is so valuable! Thank you!

    I had just last started to create my own from-scratch base framework, and it had occurred to me to create a base.css that would include classes just such as these – the things that are always going to be generated. This is beautiful.

  8. very useful, thanks for taking the time to do it.

  9. comment_class() would be a nice addition to this as well

    - Phil

  10. Great article, thank you Jeff. Been looking like that.

  11. .hentry is required for hAtom compliance.

    line #322

  12. Thanks for doing this.

    You could also add .wp-post-image class for images that you get via the get_the_post_thumbnail() function.

  13. Thanks for this site! Particularly for the Guide of Page Navigation, that was my entrance here.

  14. WebmistressM June 17, 2010

    Any chance some additions/subtractions have been done from 2.9.2 to WordPress 3?

  15. Thank you! I wonder why you can’t find this info on the official wordpress site? At least I couldn’t find it there.

  16. Yikes! I just deleted some of the style.css code for twentyten… Under Menu section for #access. Can someone please email the original default code for this section? Thanks a kazillion.

  17. How about putting it all together into a css file? so we can download it all as one file

  18. Thanks for rounding up all this info… a lot of work!

    However, I wasn’t able to find the two blockquote styles in the list of generated styles here. Are these in fact part of WP or are they simply styles that you recommend one includes in a theme?

    Also, the styles here for floated blockquotes might be better suited for pull quotes. From an excellent article on blockquotes and pull quotes on Smashing Magazine:

    Pull quotes are short excerpts from the presented text. They are used to pull a text passage out of the reader’s flow and give it a more dominant position in the post or the article….blockquote[s] (actually block quotations) are also set off from the main text as a distinct paragraph or block. However, they refer to some external citation which isn’t already mentioned in the article. Block quotations are usually placed within the reader’s flow.”

    Thanks again!

Comments are closed. Contact us with any critical information. Thank you!

Code is poetry