What each WordPress user role can do, how capabilities work, and how to assign the least access that still gets the job done.
Topics Login & access Beginner guides
Updated Published
WordPress does not give every account the same power. A role is a named bundle of capabilities: the concrete permissions that decide whether someone can publish a post, install a plugin, or only update their profile.
Get roles wrong and you invite accidents and takeovers. Get them right and most people never touch settings they should not see.
publish_posts or manage_options.WordPress checks capabilities in code (current_user_can( 'edit_others_posts' )), not the role name. Roles are just convenient packages. Plugins and custom code can add or remove capabilities from a role, or invent new roles entirely.
On a normal single site you get five built-in roles. Multisite adds a sixth: Super Admin.
Lowest default access. Subscribers can log in, manage their own profile, and (depending on theme and settings) leave comments. They can open the dashboard, but it is mostly their profile screen. They cannot create posts or pages, upload media, or change settings.
Typical use: membership sites, newsletters, or “account required” areas where people need a login but not editorial tools.
Contributors can write and edit their own drafts, then submit them for review. They cannot publish. They also lack upload_files, so they cannot add images from the Media Library on their own. That friction is intentional: guest writers draft, editors publish.
Authors write, publish, edit, and delete their own posts. They can upload media. They still cannot edit other people’s posts, manage pages, moderate the full comment queue, or change site settings.
Good fit for regular columnists who own their content end to end.
Editors manage the content side of the site: posts and pages (including other people’s), categories and tags, comments, and media. They cannot install plugins or themes, create users with higher access, or change core settings that require manage_options.
For most content teams, Editor is the right ceiling. Reserve Administrator for people who maintain the software.
On a single site, Administrator is full control: plugins, themes, settings, users, and everything Editors can do. Compromising an administrator account is effectively owning the site.
Keep this role rare. Pair every administrator with two-factor authentication and a unique password. Broader login hardening: WordPress login security guide.
On a Multisite network, Super Admin sits above site Administrators. Network-level tasks (creating sites, managing network users, installing network plugins/themes) belong here. A site Administrator on Multisite is powerful on their site but not across the whole network.
| Role | Publish own posts | Upload media | Edit others’ content | Manage pages | Install plugins / change settings |
|---|---|---|---|---|---|
| Subscriber | No | No | No | No | No |
| Contributor | No (submit for review) | No | No | No | No |
| Author | Yes | Yes | No | No | No |
| Editor | Yes | Yes | Yes | Yes | No |
| Administrator | Yes | Yes | Yes | Yes | Yes |
| Super Admin | Network-wide control (Multisite) |
Exact capability lists live in the WordPress Roles and Capabilities handbook. Plugins can change the defaults above.
Default role for new registrations (when registration is open) is under Settings → General. Leaving that on Administrator is a classic mistake. Subscriber is the safe default for open signup.
Default roles cover blogs and simple editorial teams. Shops, membership products, and agencies often need more.
WooCommerce adds Shop Manager and Customer. Membership, LMS, and SEO plugins often add their own. After you install something that touches access, open Users and confirm the new roles match what you expect. Capability creep after a plugin update is a real failure mode.
Useful when defaults almost fit:
For testing “what does this role see?”, User Switching lets an administrator jump into another account without sharing passwords. Use it on staging when you can.
WordPress stores role capabilities in the database. add_cap() and remove_cap() change them permanently until you reverse the change. Prefer a small plugin that runs the change once on activation, not a theme functions.php snippet you forget about.
Example (run once, then remove or guard so it does not become mystery tech debt):
function sn_grant_editor_theme_options() {
$role = get_role( 'editor' );
if ( $role ) {
// Also unlocks Customizer and menus, not only widgets.
$role->add_cap( 'edit_theme_options' );
}
}
add_action( 'admin_init', 'sn_grant_editor_theme_options' );Giving Editors edit_theme_options is broader than “let them tweak widgets.” Back up first, test on staging, and document why the exception exists.
These map to least privilege: give the lowest role that still works.
Privilege mistakes are how small access problems become full site takeovers. See also privilege escalation.
Assign roles on purpose, review them when people or plugins change, and keep Administrator for the people who maintain the site. That is most of the win.
Found this useful? Share it.
