You navigate to the WordPress dashboard, click “Add New User,” and pause. The dropdown menu presents you with a list: Administrator, Editor, Author, Contributor, Subscriber. What’s the actual difference? And which one is safe to assign?

As a WordPress consultant, I spend a lot of time auditing infrastructure and cleaning up site architectures. I can tell you firsthand that improper role assignment is one of the most common ways sites get accidentally broken or maliciously compromised. Giving a contractor “Administrator” access because it was easier than figuring out the right role is the WordPress equivalent of giving someone the master keys to your building when they only need to water the plants.

In this guide, we are going to break down how WordPress handles user roles, how to assign them correctly, and how to write clean, performance-minded code to create your own.

The Philosophy: Scope of Trust, Not Seniority

The biggest mistake site owners make is treating WordPress roles like a corporate hierarchy. They give the CEO the “Administrator” role because it sounds like the highest rank, and they give the new hire “Subscriber.”

WordPress roles are not about seniority. They are about scope of trust and operational necessity.

This boils down to a core security concept known as the Principle of Least Privilege: a user should only have the bare minimum access rights necessary to perform their specific job.

The Default WordPress Roles Demystified

Out of the box, a standard WordPress installation ships with five primary user roles. Here is exactly what they can and cannot do.

1. Administrator

The Administrator has the keys to the kingdom.

• Capabilities: They can do everything. Publish posts, delete pages, install or delete plugins, change the core theme, alter deep database settings, and delete other users.
• Who gets it: Only the absolute core technical owners of the site. Your lead developer, your server administrator, and perhaps the primary business owner.
• The Risk: An Administrator can install a rogue plugin, break your caching layers, or accidentally wipe your database. Hand this role out very sparingly.

2. Editor

The Editor is the master of your content, but they are locked out of the site’s infrastructure.

• Capabilities: Publish, edit, and delete any post or page on the site, regardless of who wrote it. They can moderate comments, manage categories, and upload media files.
• Who gets it: Your Content Manager, Marketing Director, or Lead Editor.

3. Author

The Author is the master of their own domain.

• Capabilities: Write, edit, publish, and delete their own posts. They can also upload files to the media library.
• Limitations: They cannot touch posts written by other people, and they cannot create or edit Pages (like your Homepage or Contact page).
• Who gets it: Trusted staff writers or regular columnists who are authorized to publish directly to the live site.

4. Contributor

The Contributor is perfect for external freelancers.

• Capabilities: They can write and edit their own posts.
• Limitations: They cannot publish their posts. A Contributor must submit their draft for review, and an Editor or Administrator must click “Publish.” Standard Contributors also cannot upload files to the Media Library.
• Who gets it: Freelance writers, guest bloggers, or new employees whose work requires editorial oversight.

5. Subscriber

The Subscriber is the lowest tier of access.

• Capabilities: Log into the site, read content, and manage their own user profile (like changing their password).
• Limitations: Everything else. They cannot write posts or see the backend dashboard beyond their profile page.
• Who gets it: Customers, clients, or newsletter subscribers.

Under the Hood: Capabilities and Code

Now let’s look at how WordPress handles this system beneath the surface.

A “Role” in WordPress is just a labeled bucket. The actual permissions inside that bucket are called Capabilities.

Capabilities are granular, specific permissions. Examples include:

• edit_posts
• publish_posts
• edit_others_posts
• update_plugins
• unfiltered_html

When a user tries to click the “Update Plugin” button, WordPress doesn’t ask, “Is this user an Administrator?” Instead, the system asks, “Does this user’s current role possess the update_plugins capability?”

Where Roles Live in the Database

WordPress stores these roles and capabilities in the database within the wp_options table, under the wp_user_roles option. It stores them as a serialized array—a structured string of data mapping out exactly which roles have which capabilities.

Because this data is saved directly in the database, it is persistent.

Creating Custom Roles: The Clean Implementation

The default roles rarely fit a growing business perfectly.

Let’s say you have a “Content Manager.” You want them to be able to edit and publish all Posts and Pages. However, you don’t want them messing with your plugin configurations, and you don’t want them managing other users.

We can programmatically create a custom role using the add_role() function. Here is a clean example of registering that exact role:

add_role(
    'content_manager',
    'Content Manager',
    [
        'read'                   => true,
        'edit_posts'             => true,
        'edit_others_posts'      => true,
        'publish_posts'          => true,
        'edit_pages'             => true,
        'edit_others_pages'      => true,
        'publish_pages'          => true,
        'upload_files'           => true,
        'manage_categories'      => true,
    ]
);

The init Hook Performance Trap

If you are writing custom code for this, there is a massive performance bottleneck you must avoid.

Because add_role() writes data directly to your wp_options table, you should never place this function loosely inside the init hook without a logical guard rail.

If you do, WordPress will execute a database write to recreate this role on every single page load. If your site gets 5,000 visitors a day, your server is rewriting the user roles array to the database 5,000 times a day. This causes unnecessary database bloat and slows down response times.

The Fix: You only need to run add_role() once. Best practice is to place role creation inside a plugin activation hook (register_activation_hook) or run it once via WP-CLI.

(If you prefer a no-code approach, plugins like User Role Editor or Members provide excellent, visual UI wrappers for these same database modifications).

Your Practical Action Plan

If you manage a team or maintain client sites, take five minutes today to run a quick permission audit.

1. Log into your WordPress Dashboard.
2. Click on Users -> All Users.
3. Look at the top filters or sort by the Role column.

If you see more than two or three Administrators, you have a security vulnerability. Does your graphic designer really need Admin access to upload a logo? Does the SEO agency you hired two years ago still have the keys to the server? Downgrade or delete those accounts immediately.

Map your company hierarchy to actual capabilities. When in doubt, ask yourself: “What is the absolute minimum level of access this person needs to do their job today?” Getting your WordPress user roles right creates a secure, streamlined environment. It allows your team to do their best work without the looming fear of accidentally bringing down the entire website.

Ready to dive deeper into custom permissions? Check out the technical companion to this post: Extending Role Capabilities in WordPress, where we cover how to modify existing roles without rewriting the whole array.

First, we’ll take a look at the default roles WordPress has to offer.

Note: If you’re looking for a quick solution involving no coding/development, please download the User Role Editor plugin.

Default WordPress Roles and Capabilities

By default, a typical WordPress installation has five default user roles:

1. Administrator
2. Editor
3. Author
4. Contributor
5. Subscriber

To understand each role, I’ve provided a summary of each.

Administrator

The Administrator role is the most powerful role in the WordPress ecosystem. Administrators have the ability to:

• Add, edit, and delete all content types and users
• Add, edit, and delete plugins and themes
• Update the WordPress Core
• Completely control the website

Smaller sites usually delegate this role to the owner of the website or to a dedicated developer/webmaster who deploys regular updates and manages technical operations for the website. Anyone who does not require this level of capabilities should be assigned a different role.

Editor

Editors control and manage the content aspects of a WordPress website. Editors have the ability to:

• Add, edit, puslish, and delete all content types
• Moderate, edit, and delete comments on posts
• Create categories
• Add categories
• Create and add tags

Editors do not have capabilities to change site settings or perform technical changes like updating plugins, updating themes, or adding/removing other users.

Author

Authors manage and produce their own content on a WordPress site. Authors have the ability to:

• Add, edit, publish, and delete their own posts
• Add categories
• Create and add tags

Unlike Editors, Authors can only view comments on their posts, but they cannot moderate, approve, or delete them.

Contributor

Contributors create their own content on a WordPress site. Contributors have the ability to:

• Add and edit their own posts
• Create and add tags

Like Authors, Contributors can only view comments on their posts, but they cannot moderate, approve, or delete them.

Subscriber

The Subscriber role is the most restricted role. The only capabilities this role has is the ability to update their own user profile information and to change their login password. This role is useful for websites that have a subscription model where users must login to read content or leave comments.

Extending Current Role Capabilities

Sometimes, the base roles and capabilities aren’t enough and an existing role needs to be extended. In a recent project, I needed to give the Subscriber role the ability to read private posts and pages on a site. Instead of adding a plugin to do this, I decided to extend the roles using the get_role() and add_cap() WordPress functions.

There’s a number of approaches to solving this problem, so I’ll provide two different examples with their pros and cons.

Extending Roles in functions.php

This is probably the quickest and simplest solution for extending capabilities on a role; a function is created that where the Subscriber role is retrieved via get_role() and stored in a variable. The role then gets the read_private_posts and read_private_pages capabilities added to it via add_cap(). Overall, this approach is pretty simple and straightforward. This approach is also the one I see floating around the internet as the defacto solution. Below is an example.

// Make private posts and pages available to subscribers
function subs_read_private_content(){
    $subRole = get_role( 'subscriber' );
    $subRole->add_cap( 'read_private_posts' );
    $subRole->add_cap( 'read_private_pages' );
}
add_action( 'init', 'subs_read_private_content' );

Caveats

• This method will write to the database even if the capability has been registered.
• This method will fire on every page load, compromising performance.

Extending Roles Using a Custom Plugin

A more robust and performance friendly approach to this problem requires a bit of extra work, but makes up for the performance caveats in the previous example. In this example, we’ll create a simple plugin that extends the capabilities of the Subscriber role.

When writing a plugin, the register_activation_hook() function is used to trigger the code when the plugin is activated, meaning it will only fire once. It must be taken into account, though, that the capabilities should be disabled/removed when the plugin is deactivated, so the register_deactivation_hook() needs to be used to remove the capabilities when the plugin is deactivated.

<?php

/**
 * Plugin Name: Allow Subscribers to Read Private Content
 * Plugin URI: https://brettwidmann.com
 * Description: A plugin that allows subscribers to read private posts and pages
 * Version: 1.0
 * Author: Brett Widmann
 * Author URI: https://brettwidmann.com
 */

register_activation_hook(__FILE__, function()
{
    // Make private posts and pages available to subscribers
    $subRole = get_role( 'subscriber' );
    $subRole->add_cap( 'read_private_posts' );
    $subRole->add_cap( 'read_private_pages' );
});

register_deactivation_hook(__FILE__, function()
{
    // Make private posts and pages unavailable to subscribers
    $subRole = get_role( 'subscriber' );
    $subRole->remove_cap( 'read_private_posts' );
    $subRole->remove_cap( 'read_private_pages' );
});

Caveats

• This solution depends on activation/deactivation of the plugin
• What happens if the plugin is live in production, but an update to the plugin is pushed?

Conclusion

While WordPress has multiple approaches to solving problems, the relationship between what needs to be achieved and the database always needs to be taken into consideration, especially when writing plugins and themes.

Along with writing clean and effective code, please document any changes and overrides so that other developers who may inherit your site in the future can understand the how and why your changes were made (or better yet, a reminder for yourself).

Did I miss something? Feel free to leave a comment below or contact me if you have any questions.