WordPress user roles and capabilities, explained

WordPress user roles and capabilities control what authenticated users are allowed to do inside a website.

The system is easy to misunderstand because WordPress exposes familiar labels such as:

Administrator
Editor
Author
Contributor
Subscriber

but those role names are not the actual permission checks that most WordPress code should rely on.

The underlying security model is based on capabilities.

A useful way to think about the system is:

Role
→ collection of capabilities

Capability
→ permission to perform a task

User
→ receives capabilities through roles
   and potentially user-specific rules

For example:

Editor
↓
edit_posts
edit_others_posts
publish_posts
moderate_comments
upload_files
...

WordPress then checks those capabilities when deciding whether the current user can perform a particular action.

The official WordPress Roles and Capabilities documentation describes roles as predefined collections of tasks called capabilities.

This guide explains how WordPress roles and capabilities actually work, what the default roles can do, the difference between primitive and meta capabilities, how permissions should be checked in custom code, how plugins can extend the system, and how to design a safer role structure for real WordPress sites.

What is a WordPress role?

A role is a named collection of capabilities.

For example:

Role:
Editor

Capabilities:
edit_posts
edit_others_posts
publish_posts
moderate_comments
manage_categories
upload_files
...

The official WordPress User Roles and Capabilities API documentation explains that capabilities are the individual permissions assigned to users or roles.

A role is not a permission by itself

This distinction is fundamental.

It is tempting to write logic such as:

if user role == editor
    allow action

But the actual requirement may be:

if user can edit other users' posts
    allow action

The second model is more flexible.

Roles describe responsibilities

The official WordPress documentation recommends thinking of roles as descriptions of user responsibilities rather than simply as levels in a hierarchy.

For example:

Editor
→ manages editorial content

Author
→ writes and publishes own content

Contributor
→ writes but cannot publish

Subscriber
→ basic authenticated user

What is a WordPress capability?

A capability represents permission to perform a particular class of action.

Examples include:

edit_posts
publish_posts
delete_posts
upload_files
moderate_comments
manage_categories
manage_options
install_plugins
edit_users

WordPress checks these capabilities throughout:

• wp-admin;
• REST API endpoints;
• content editing;
• plugin management;
• theme management;
• user management;
• custom plugin functionality.

Roles group capabilities together

Instead of individually assigning twenty permissions to every Editor, WordPress defines the Editor role once and associates the appropriate capabilities with it.

Then:

User A
→ Editor

User B
→ Editor

User C
→ Editor

all receive the capabilities associated with that role.

The default WordPress roles

WordPress provides the following standard roles:

• Administrator;
• Editor;
• Author;
• Contributor;
• Subscriber.

WordPress Multisite adds:

• Super Admin.

The official roles documentation maintains the current capability matrix for these roles.

Administrator

On a normal single-site WordPress installation, Administrator is the most powerful standard role.

Administrators can normally perform tasks such as:

• manage site settings;
• install and activate plugins;
• install and switch themes;
• manage users;
• edit any content;
• moderate comments;
• manage categories;
• upload files.

Important Administrator capabilities

Examples include:

manage_options
activate_plugins
install_plugins
edit_users
delete_users
edit_theme_options
publish_posts
edit_others_posts

Administrator should not be the default role for staff

Giving someone Administrator because:

"they might need something later"

creates unnecessary access.

An Administrator account can often:

• install executable plugin code;
• change critical configuration;
• manage other users;
• modify themes;
• affect security settings.

Administrator should therefore be reserved for people who actually need administrative control.

Editor

The Editor role is designed for users who manage content across the site.

Editors can typically:

• create posts;
• edit their own posts;
• edit posts created by others;
• publish posts;
• manage pages;
• moderate comments;
• manage categories;
• upload media.

They generally cannot:

• install plugins;
• change core site settings;
• manage themes;
• create Administrator accounts.

Editor is often appropriate for content managers

A person responsible for publishing content usually does not need:

install_plugins
manage_options
edit_users

just to manage articles and pages.

Author

An Author can typically:

• create their own posts;
• edit their own posts;
• publish their own posts;
• delete their own posts within the permissions available;
• upload files.

They cannot normally edit content belonging to other users.

Author is appropriate for independent publishers

This role works well when a user should be able to publish content but should not manage the broader editorial system.

Contributor

A Contributor can normally:

• write posts;
• edit their own unpublished posts;

but cannot publish them directly.

A typical workflow is:

Contributor writes
↓
Editor reviews
↓
Editor publishes

Contributor does not normally upload files

The default Contributor role lacks:

upload_files

which is an important practical distinction when designing an editorial workflow.

Subscriber

Subscriber is the most limited standard role.

Its primary capability is:

read

Subscribers can generally manage their own profile but do not receive normal editorial or administrative permissions.

Subscriber is useful as a basic authenticated account

It can serve as a foundation for:

• membership systems;
• customer accounts;
• private content;
• custom application logic.

Super Admin

Super Admin exists in WordPress Multisite.

This role can manage the wider network rather than only one individual site.

Network capabilities include examples such as:

manage_network
manage_sites
manage_network_users
manage_network_plugins
manage_network_themes
create_sites
delete_sites

Administrator and Super Admin are different in Multisite

On a Multisite network, a site Administrator does not automatically have every network-level permission.

For example, plugin installation may remain restricted to Super Administrators.

The official WordPress role matrix documents these differences explicitly.

Default roles are only a starting point

Plugins can:

• add roles;
• remove roles;
• add capabilities;
• remove capabilities;
• create entirely new permission systems on top of WordPress.

For example, WooCommerce commonly introduces roles such as:

Customer
Shop Manager

Membership plugins may create additional roles.

Learning platforms may create roles such as:

Student
Instructor

A role name tells you less than its capabilities

Suppose a site contains:

SEO Manager

You cannot safely assume what that role can do from its name.

It might contain:

edit_posts
publish_posts

or:

manage_options
edit_users
activate_plugins

depending on how the plugin or administrator configured it.

Always inspect the capability set

The actual authorization question is:

What capabilities does this user have?

not merely:

What is this role called?

Primitive capabilities

Many capabilities map directly to permissions assigned to roles.

Examples include:

edit_posts
edit_others_posts
publish_posts
upload_files
manage_options

These are often called primitive capabilities.

Meta capabilities

WordPress also has context-dependent capabilities.

Examples include:

edit_post
delete_post
read_post
edit_user

These are frequently called meta capabilities.

They describe an action involving a specific object.

edit_posts and edit_post are not identical

Consider:

edit_posts

This is a broad primitive capability.

Now consider:

edit_post, $post_id

This asks whether the user can edit one specific post.

WordPress maps meta capabilities to primitive capabilities

The Core function:

map_meta_cap()

performs this mapping.

The official map_meta_cap() documentation explains that meta capabilities are mapped to the primitive capabilities required for a particular user and object.

Example

Suppose User A wants to edit Post 42.

current_user_can(
    'edit_post',
    42
)

WordPress evaluates information such as:

• who owns Post 42;
• whether it is published;
• what post type it belongs to;
• which primitive capabilities the user has.

The required primitive capability can change with context

If the user owns the post, WordPress might require:

edit_posts

If another user owns it, WordPress may also need:

edit_others_posts

If the post is already published, another capability may become relevant:

edit_published_posts

This is why object-specific checks are powerful

Instead of manually rebuilding WordPress permission logic, developers can ask WordPress the meaningful question:

Can this user edit this specific post?

Use current_user_can() for permission checks

The standard function for checking the current user’s permissions is:

current_user_can()

The official current_user_can() documentation states that it returns whether the current user has the specified capability.

Basic example

if ( current_user_can( 'manage_options' ) ) {
    // User can manage site options.
}

Object-specific example

if ( current_user_can( 'edit_post', $post_id ) ) {
    // User can edit this specific post.
}

Capability checks are preferable to role checks

This is generally better:

if ( current_user_can( 'edit_posts' ) ) {
    // Allow editorial action.
}

than:

if ( user role == 'editor' ) {
    // Allow editorial action.
}

Why role checks are fragile

A custom role may also possess:

edit_posts

For example:

SEO Manager
Content Manager
Shop Manager
Custom Editor

If your code checks only:

editor

those legitimate users may be blocked even though they have the necessary capability.

The WordPress documentation explicitly discourages role checks for authorization

The current_user_can() documentation notes that checking roles instead of capabilities is discouraged because it can produce unreliable results.

Check permissions where the action actually happens

Hiding a button is not enough.

Consider:

if user cannot edit settings
    hide Save button

If the server-side request handler never verifies authorization, the user may still be able to send the request manually.

Authorization belongs on the server

A proper flow looks like:

Request received
↓
Verify authentication
↓
Verify capability
↓
Verify nonce where appropriate
↓
Validate input
↓
Perform action

Capability checks are not nonce checks

These solve different problems.

current_user_can()
→ is the user authorized?

nonce
→ is this request likely intentional
   and associated with the expected workflow?

Neither replaces the other.

Menu visibility is not authorization

WordPress administration menus are frequently shown or hidden according to capabilities.

However:

hidden menu
≠
access denied

If custom code merely removes a menu item but the underlying page does not perform a capability check, a user may still access the URL directly.

Always protect the underlying action

Interface customization can improve usability.

Authorization must be enforced separately.

This distinction is especially important when simplifying wp-admin with tools such as TheOneWP Admin Menu Organizer.

Roles are stored separately from users

WordPress stores role definitions and their capability sets as site configuration.

The official Plugin Handbook Roles and Capabilities documentation explains that role definitions are stored in the WordPress options system.

User role assignments use user metadata

Individual users have their assigned roles and capabilities represented through WordPress user metadata.

For the broader data model, see WordPress User Meta, Explained.

Users can have individual capabilities

A WordPress user can potentially receive capabilities directly rather than exclusively through a role.

This creates an important audit issue.

You may inspect a user and see:

Role:
Editor

but their effective permission set may contain additional capabilities.

Effective permissions matter more than the visible role label

A proper audit should therefore ask:

What can this user actually do?

not merely:

Which role appears in Users → All Users?

Plugins can modify capabilities dynamically

WordPress exposes filters and APIs that allow permission logic to change dynamically.

For example:

user_has_cap
map_meta_cap

can affect the effective result of capability checks.

This means permissions are not always static

A plugin could theoretically decide:

User has edit_posts
but only under condition X

or:

User receives extra capability
for this request

Audit complex permission systems at runtime

On highly customized sites, looking only at stored role definitions may not tell the full story.

Creating a custom role

WordPress provides:

add_role()

for creating custom roles.

The official add_role() documentation covers the native API.

Example custom role

function mysite_add_content_manager_role() {

    add_role(
        'content_manager',
        'Content Manager',
        array(
            'read'         => true,
            'edit_posts'   => true,
            'publish_posts' => true,
            'upload_files' => true,
        )
    );
}

add_action(
    'init',
    'mysite_add_content_manager_role'
);

Do not run role creation unnecessarily on every request

Roles are persistent.

In a plugin, role creation is often better associated with an activation or controlled setup process rather than repeatedly rewriting role definitions.

Adding a capability to an existing role

You can retrieve a role using:

get_role()

and then add a capability.

Example

$editor = get_role( 'editor' );

if ( $editor ) {
    $editor->add_cap( 'example_capability' );
}

Removing a capability

$editor = get_role( 'editor' );

if ( $editor ) {
    $editor->remove_cap( 'example_capability' );
}

Be careful modifying default roles

Changing:

Editor
Administrator
Author

changes the permissions of every user assigned to that role.

On a site with:

1 Editor

the impact may be small.

On a publication with:

250 Editors

one capability change may affect hundreds of accounts.

Custom roles can be cleaner than modifying Core roles

If one small group needs special permissions, consider:

Custom role
→ targeted capability set

instead of changing:

Editor
→ new capabilities for every Editor

Do not create custom roles without a reason

A site with:

Editor
Senior Editor
Junior Editor
Content Editor
SEO Editor
Blog Editor
Marketing Editor

can become harder to understand than the original permission problem.

Roles should correspond to real responsibilities

For the design decision, see Custom WordPress Roles vs. Combining Existing Ones.

Multiple roles are a separate concept

Native WordPress interfaces generally present one primary role assignment per user.

However, custom systems can combine permission sets from multiple roles.

For example:

User:
Editor
+
SEO Manager

could receive capabilities from both responsibility sets.

TheOneWP Multi Role Assignment

TheOneWP Multi Role Assignment supports assigning additional roles while preserving the site’s existing role definitions.

Its role capabilities participate in the user’s effective permission checks.

Multiple roles do not automatically mean better architecture

Use them when one person genuinely performs multiple existing responsibilities.

If almost every user needs the same combination:

Role A
+
Role B
+
Role C

a purpose-built custom role may be easier to understand.

Custom roles and multiple roles solve different problems

Multiple roles
→ combine existing responsibilities

Custom role
→ define a new responsibility model

The principle of least privilege

Role design should follow the principle of least privilege.

A user should receive:

the permissions required
to perform their responsibilities

rather than:

the broadest role
that avoids support requests

Example: content writer

The user needs to:

• write posts;
• upload images;
• submit content for review.

They do not need to:

• install plugins;
• manage users;
• change site settings;
• edit other authors’ content.

Administrator would be inappropriate.

Example: marketing manager

The user may need:

• Pages;
• Posts;
• media;
• selected SEO settings.

They may not need:

• plugin installation;
• user deletion;
• theme management;
• system configuration.

Example: external developer

A developer may temporarily need broader access during a project.

That does not mean the elevated access should remain indefinitely.

Temporary permission changes should have a review date.

Administrator accounts deserve particular scrutiny

A compromised Administrator can potentially change:

• plugins;
• themes;
• users;
• settings;
• security configuration.

This makes privilege and authentication security closely related.

See A WordPress Login Hardening Checklist.

Role permissions and authentication are different layers

A role answers:

What can the user do
after authentication?

Authentication answers:

Is this really the user?

You need both.

A low-privilege compromised account still matters

Even a Subscriber account can create problems depending on:

• membership functionality;
• private content;
• custom applications;
• stored personal information.

A high-privilege account creates greater potential impact

The risk roughly combines:

probability of compromise
×
permissions available after compromise

Audit user roles regularly

A site’s permission model changes over time.

Typical causes include:

• new employees;
• former employees;
• contractors;
• new plugins;
• new custom roles;
• temporary Administrator access;
• changing responsibilities.

For a complete process, see How to Audit User Roles on a WordPress Site.

Audit dormant accounts

Unused accounts can preserve old permissions indefinitely.

A user who left a project two years ago may still have:

Administrator

access unless someone explicitly removes it.

See Auditing Dormant WordPress User Accounts.

Do not delete users casually

A user may own:

• posts;
• pages;
• custom post type content;
• orders or application data;
• plugin-specific records.

When removing an account, decide what should happen to owned content.

Blocking login and deleting an account are different actions

Sometimes the requirement is:

preserve the user record
but stop authentication

rather than:

delete the entire account

TheOneWP Block User Login addresses that separate workflow.

Custom post types can define custom capabilities

WordPress permission architecture is not limited to Posts and Pages.

A custom post type can define its own capability model.

For example:

edit_books
publish_books
delete_books
edit_others_books

This allows domain-specific permissions

A site could create:

Book Editor

who can manage books without gaining permission to manage normal blog posts.

Do not use manage_options for every custom feature

A common plugin-development shortcut is:

current_user_can( 'manage_options' )

for every administration feature.

This effectively restricts the feature to high-privilege users and can make delegation difficult.

Create a meaningful capability when appropriate

If a plugin provides a specific business operation, a dedicated capability can make more sense:

manage_inventory
view_private_reports
approve_members
manage_bookings

Capability names should describe actions

Good capability design usually follows:

verb
+
resource

Examples:

edit_products
manage_events
approve_requests

REST API endpoints must check capabilities too

A REST endpoint can expose sensitive actions even if the wp-admin interface is perfectly restricted.

WordPress REST controllers typically use permission callbacks and capability checks.

The official WordPress REST API custom endpoint documentation explains the use of permission_callback when registering routes.

Example permission callback

register_rest_route(
    'example/v1',
    '/settings',
    array(
        'methods'  => 'POST',
        'callback' => 'example_update_settings',
        'permission_callback' => function () {
            return current_user_can( 'manage_options' );
        },
    )
);

REST security should use the same authorization model

The API should not invent a separate rule such as:

if user ID == 1
    allow

when WordPress already provides capability-based authorization.

Site Editor access is capability-based too

Modern block themes use the Site Editor for:

• templates;
• template parts;
• styles;
• navigation;
• site design.

The current official WordPress capabilities documentation identifies:

edit_theme_options

as the primary capability involved in Site Editor access.

But Site Editor functionality can require additional capabilities

Depending on the operation, users may also require permissions such as:

edit_posts
edit_pages
edit_others_posts
upload_files

One capability can grant more than the name suggests

This is important when customizing roles.

Giving:

edit_theme_options

solely because someone should change one design option can potentially expose broader theme-related administration.

Review the full implications of every capability you grant.

Plugin capabilities require ongoing maintenance

Suppose Plugin A creates:

manage_plugin_a

and you add it to a custom role.

Later the plugin is removed.

Your role may still contain obsolete permission configuration.

Role cleanup should accompany plugin cleanup

After removing major plugins, review:

• custom roles;
• plugin-specific capabilities;
• user assignments;
• menu rules;
• access restrictions.

Role Manager can make capability architecture visible

TheOneWP Role Manager provides an interface for inspecting and managing WordPress roles and their capabilities.

This is useful because a permission model is easier to maintain when administrators can clearly answer:

Which roles exist?

Which capabilities does each role have?

Which permissions were customized?

Do not change capabilities without understanding the consequences

Removing:

edit_others_posts

from Editors can fundamentally change the editorial workflow.

Adding:

manage_options

to Authors can expose broad site settings.

Back up or document permission changes

Before major role restructuring, record:

• existing roles;
• existing capabilities;
• which users have each role;
• custom plugin-created roles;
• business reason for each customization.

Test custom roles using representative accounts

Do not test everything while logged in as Administrator.

Create an account assigned to the role being tested.

Test both what the user should and should not be able to do

A permission test should include positive cases:

Can create required content
Can upload required media
Can access intended screen

and negative cases:

Cannot install plugins
Cannot edit other users
Cannot change protected settings
Cannot access restricted endpoint directly

Direct URL testing matters

If a menu item is hidden, manually test its administration URL.

If a button is removed, test the underlying request.

Authorization should remain enforced even without the normal interface.

Roles can also drive workflow features

Roles are often used for more than security.

They can control:

• login destinations;
• admin menus;
• notifications;
• frontend UI;
• content visibility;
• membership behavior.

Role-based login redirects

A site may send:

Administrator
→ Dashboard

Editor
→ Posts

Customer
→ Account page

For the wider workflow, see WordPress Login Redirects by Role, Explained.

Role targeting is useful outside authentication too

For example:

Show notification only to Editors

Show admin menu item only to Administrators

Show onboarding message only to Customers

See How to Target WordPress Users by Role.

Do not confuse role targeting with security authorization

A notification system can reasonably ask:

Is this user an Editor?

because the message is intended for that organizational group.

A sensitive action should usually ask:

Does this user have
the required capability?

Role labels are useful for audiences

Capabilities are better for permissions.

Common WordPress role mistakes

Giving everyone Administrator

This defeats the point of WordPress’s permission system.

Checking role names instead of capabilities

This can block valid custom roles or grant access based on brittle assumptions.

Hiding menus instead of enforcing permissions

Interface hiding is not access control.

Adding manage_options to every custom role

This can grant more access than intended.

Leaving temporary elevated permissions forever

Temporary Administrator access has a strange tendency to survive years unless somebody audits it.

Keeping obsolete plugin capabilities

Permission models should be reviewed when plugins are removed.

Creating too many nearly identical roles

Complexity makes auditing harder.

Changing a default role without realizing every assigned user is affected

Role-level changes are global to users assigned to that role.

Testing only what users can see

Test direct access and backend actions as well.

Ignoring Multisite differences

Administrator permissions differ between single-site and Multisite installations.

A practical role-design process

Step 1: list responsibilities

Write down what each type of user actually does.

For example:

Content Writer
- write posts
- edit own drafts
- upload media

Content Manager
- edit all posts
- publish content
- moderate comments

Site Administrator
- manage plugins
- manage users
- change settings

Step 2: map responsibilities to capabilities

Translate tasks into WordPress permissions.

write posts
→ edit_posts

publish posts
→ publish_posts

edit other authors
→ edit_others_posts

upload media
→ upload_files

change site settings
→ manage_options

Step 3: compare with existing roles

If a Core role already matches the requirements, use it.

Step 4: create a custom role only when needed

A custom role should solve a real mismatch.

Step 5: avoid unnecessary privilege

Do not add capabilities simply because they might someday be useful.

Step 6: test the result

Use real representative accounts.

Step 7: document the model

Record why custom permissions exist.

Step 8: audit periodically

User responsibilities change.

The permission architecture should change with them.

WordPress roles and capabilities audit checklist

• List all current WordPress roles.
• Identify which roles are Core roles.
• Identify plugin-created roles.
• Identify custom project roles.
• Inspect the capability set of each role.
• Identify users assigned to each role.
• Audit all Administrator accounts.
• Audit Multisite Super Administrators where applicable.
• Check whether Editors really need all current capabilities.
• Check whether Authors can do more than intended.
• Check Contributor workflows.
• Review Subscriber and membership accounts.
• Identify users with individual capabilities.
• Identify plugin-specific capabilities.
• Remove obsolete capabilities after plugin removal where appropriate.
• Review temporary elevated access.
• Review former staff and contractor accounts.
• Audit dormant users.
• Apply least privilege.
• Use capability checks instead of role-name checks for authorization.
• Use object-specific meta capability checks where appropriate.
• Use current_user_can() for current-user authorization.
• Check capabilities in backend request handlers.
• Check capabilities in REST API permission callbacks.
• Do not rely on hidden menu items for security.
• Do not rely on hidden buttons for security.
• Do not grant manage_options casually.
• Review Site Editor capabilities carefully.
• Test custom roles using dedicated test users.
• Test permitted actions.
• Test prohibited actions.
• Test direct administration URLs.
• Test REST endpoints.
• Review custom post type capabilities.
• Document custom roles.
• Document capability modifications.
• Re-audit after plugin installations.
• Re-audit after plugin removals.
• Re-audit after staff changes.
• Re-audit after major workflow changes.

TheOneWP tools for WordPress role management

Role Manager

Role Manager provides a structured interface for inspecting and managing roles and capability sets.

Multi Role Assignment

Multi Role Assignment supports users whose responsibilities intentionally span multiple existing roles.

Block User Login

Block User Login can preserve a user record while preventing authentication when access needs to be suspended.

Two-Factor Authentication

Two-Factor Authentication strengthens the authentication layer for accounts that retain sensitive capabilities.

Admin Menu Organizer

Admin Menu Organizer can simplify wp-admin navigation according to user roles, while actual security continues to rely on capability checks.

Use each layer for its actual purpose

Role Manager
→ define permission profiles

Multi Role Assignment
→ combine responsibilities

Block User Login
→ suspend authentication

Two-Factor Authentication
→ strengthen identity verification

Admin Menu Organizer
→ simplify interface visibility

Related guides

• How to Audit User Roles on a WordPress Site
• Custom WordPress Roles vs. Combining Existing Ones
• Auditing Dormant WordPress User Accounts
• WordPress User Meta, Explained
• A WordPress Login Hardening Checklist
• How to Target WordPress Users by Role

Final recommendation

WordPress roles and capabilities are easiest to understand when roles are treated as convenient permission packages rather than the security mechanism itself.

The core model is:

User
↓
Role
↓
Capabilities
↓
WordPress authorization check
↓
Allow or deny action

For object-specific actions, WordPress can add another layer:

Meta capability
↓
map_meta_cap()
↓
required primitive capabilities
↓
effective permission decision

This allows WordPress to answer questions such as:

Can this user edit posts?

Can this user edit this specific post?

Can this user edit another user's post?

Can this user manage site settings?

For developers, the most important rule is simple:

check capabilities
rather than assuming roles

Use:

current_user_can()

and object-specific capability checks where appropriate.

For administrators, the equivalent rule is:

assign the minimum permissions
required for the responsibility

A well-designed WordPress permission system should make it easy to explain why each role exists, what each role can do and which users genuinely require those permissions.

Once nobody can explain why a particular account still has Administrator access, the permission audit is already overdue.