Reference guide · wordpress · Published 2026-08-16 · 3 min read
WordPress user roles and capabilities explained
Understand WordPress roles and capabilities, the six default roles, what each can do, and how to grant targeted capabilities safely.
- ·The six default roles
- ·Capabilities under the hood
- ·Assign and customise safely
The six default roles
WordPress ships six built-in roles: Super Admin, Administrator, Editor, Author, Contributor and Subscriber. The first two differ on a normal install only in that Super Admin is reserved for the network admin in a WordPress Multisite network. On a single site, the Administrator holds the full capability set.
| Role | Typical job | What it can do |
|---|---|---|
| Super Admin | Network owner | Everything across the whole Multisite network |
| Administrator | Site owner | Full access, install and manage plugins and themes |
| Editor | Content manager | Publish and edit anyone's posts and pages, manage comments |
| Author | Regular writer | Write, edit and publish only their own posts |
| Contributor | Drafting | Write and edit their own drafts but not publish them |
| Subscriber | Read-only account | Read content and update only their own profile |
These defaults are the reason most "just give me access" requests do not need the administrator login. A content editor needs the Editor role, a writer needs Author, and someone doing drafts needs Contributor. Handing out Administrator, or worse sharing the single admin account, removes the boundaries between publishing and administration and is one of the largest login and access risks on an active site.
Capabilities under the hood
A role is simply a named collection of capabilities. WordPress stores the capabilities of the six roles in the database and maps each capability to a concrete action: edit_posts, publish_posts, delete_others_pages, manage_options, activate_plugins, and so on. When a user does an action, WordPress checks whether any role assigned to that user includes the matching capability. This design is why the same action can be allowed for an Editor and denied for an Author purely by the capability list.
Because multisite adds a level, the manage_network capability set is separate from the per-site capabilities and is only held by Super Admin. The Multisite overview shows how network-level control differs from per-site administration.
Assign and customise safely
- Choose the smallest role that completes the job. If a person only writes drafts, Contributor beats Author. If they manage the whole site's content, Editor beats Administrator. Default to the least access that works.
- Use separate accounts, never a shared login. Each person gets their own user, so activity and password resets are attributable. The account a plugin or REST access uses should be its own too, rather than reusing the admin.
- Create custom roles for unusual needs. When the defaults are too coarse, register a custom capability set with
add_role()or a plugin, granting only what the job needs instead of inventing a new all-powerful role. Audit it against the defaults before deploying. - Verify after delegation. Log in as the new role and attempt the tasks it should and should not allow. Confirm it cannot install plugins, edit themes, or delete others' content unless that is the intent, because a role that follows the capability list is safer than one assumed correct by name.
Delegation done this way keeps publishing separate from administration. If a user later reports a permissions error, the troubleshooting order walks the sequence, and confirming which role the user holds and which capability the failing action needs is usually the first thing that surfaces.