WordPress Editor vs. Administrator Role: A Complete Technical Guide

WordPress ships with a granular role-based access control (RBAC) system built directly into its core. Of all the default roles, Administrator and Editor are the two most consequential — and the most frequently misassigned. The Administrator holds unrestricted capability over every WordPress object, while the Editor operates with broad content authority but zero access to infrastructure-level controls such as themes, plugins, or site settings.

Getting this distinction wrong is not a minor inconvenience. Granting a content writer Administrator access on a production site is a direct attack surface: one compromised account can install a malicious plugin, exfiltrate the database, or lock out every other user. This guide gives you the technical depth to make the right call every time.

How WordPress Roles and Capabilities Actually Work

Before comparing the two roles, it is worth understanding the underlying architecture. WordPress does not store roles as a fixed property of a user account. Instead, it stores a serialized array of capabilities in the wp_usermeta table under the key wp_capabilities (where wp_ is your table prefix). Each role is simply a named bundle of capabilities registered in the WP_Roles class.

When a user attempts an action — publishing a post, deleting a plugin, editing another user's profile — WordPress calls current_user_can(), which resolves the user's stored capabilities against the requested primitive. This means capabilities are additive and, critically, they can be customized per-user independent of their role using plugins like Members or User Role Editor.

The practical implication: if you need a user who can do *almost* everything an Editor can do but also manage one specific plugin, you do not need to escalate them to Administrator. You can grant a single additional capability. Understanding this prevents the most common over-provisioning mistake in WordPress team management.

Administrator Role: Full Capability Breakdown

The Administrator role maps to virtually every primitive capability WordPress exposes. On a single-site installation, this includes but is not limited to:

Core site management capabilities:

manage_options — read and write all settings via wp-admin/options-general.php, including site URL, admin email, permalink structure, and timezone
install_plugins, activate_plugins, update_plugins, delete_plugins — full plugin lifecycle control
install_themes, switch_themes, edit_themes, delete_themes — full theme lifecycle control, including direct file editing via the built-in theme editor (a significant attack vector)
edit_files — access to the built-in code editor for both themes and plugins (this capability is disabled when DISALLOW_FILE_EDIT is set to true in wp-config.php)

User management capabilities:

create_users, edit_users, delete_users, promote_users, list_users — full authority over every user account on the site, including the ability to demote or delete other Administrators
remove_users — remove users from a Multisite network

Content capabilities:

edit_others_posts, edit_published_posts, delete_others_posts, delete_published_posts, delete_private_posts

Advanced capabilities:

import — import content via the WordPress importer (can be used to inject arbitrary content at scale)
export — export the entire site's content as an XML file, including all user data
update_core — trigger WordPress core updates
manage_categories, moderate_comments, unfiltered_html — post raw HTML including <script> tags without sanitization

The unfiltered_html capability deserves special attention. On a standard single-site install, both Administrators and Editors receive it. On WordPress Multisite, only Super Admins retain it. This is a meaningful security boundary: without unfiltered_html, the wp_kses_post() filter strips JavaScript and other potentially dangerous markup from saved content.
When to Assign the Administrator Role

The person who owns the hosting account and is responsible for the site's technical integrity
A vetted developer or DevOps engineer performing theme development, plugin configuration, or server-side integration work
A migration specialist during a one-time import/export operation (consider revoking the role afterward)

Critical operational note: Never assign Administrator to a shared or generic account. Each Administrator must be a named individual with a unique, strong password and two-factor authentication enabled. If you are running WordPress on a VPS Hosting environment, pair WordPress-level Administrator hygiene with OS-level user separation — your web server process should never run as root, and your WordPress file ownership should be distinct from your web server user.
Editor Role: Capability Breakdown
The Editor role is purpose-built for content operations. It grants extensive authority over posts, pages, media, comments, and taxonomy — but deliberately excludes every infrastructure-level capability.
Content capabilities an Editor holds:

edit_posts, edit_others_posts, edit_published_posts, edit_private_posts

What an Editor explicitly cannot do:

• Access wp-admin/options-general.php or any settings screen
• Install, activate, deactivate, or delete plugins or themes
• View or modify any user account other than their own profile
• Run WordPress core updates
• Access the built-in theme or plugin file editors
• Change permalink structures, which would break all existing URLs site-wide
• Export or import site data

When to Assign the Editor Role

• A managing editor or content director who owns the editorial calendar and approves drafts from multiple contributors
• An SEO specialist who needs to publish, schedule, and optimize posts but has no business touching plugin settings
• A social media or marketing manager responsible for keeping the blog active
• A client who needs to update their own pages without the risk of accidentally breaking the site

Administrator vs. Editor: Side-by-Side Comparison

Security Implications of Role Misassignment

The Over-Privileged Editor Problem

A common pattern in agencies: a content writer is given Administrator access because "it's easier." This creates several concrete risks:

1. Plugin installation as a code execution vector. Any Administrator can install a plugin. A plugin is PHP code that executes on your server. A compromised Administrator account equals remote code execution.
2. Credential harvesting via export. The WordPress export tool produces an XML file containing all post content, comments, and author metadata. An Administrator can trigger this silently.
3. Privilege escalation persistence. An attacker who gains Administrator access can create a new Administrator account, then delete the evidence — locking out the legitimate owner.
4. unfiltered_html abuse. Even without plugin access, an Administrator can inject <script> tags directly into post content, enabling stored XSS attacks against site visitors.

Hardening the Administrator Role

Beyond role assignment, apply these WordPress-level controls on any production site:

Add the following to wp-config.php to disable the built-in file editor:

define( 'DISALLOW_FILE_EDIT', true );
define( 'DISALLOW_FILE_MODS', true ); // Also blocks plugin/theme installation

Restrict the WordPress admin area by IP at the server level. For Nginx:

location /wp-admin/ {
    allow 203.0.113.0/24;
    deny all;
}

For Apache, add to .htaccess:

<Files "wp-login.php">
    Require ip 203.0.113.0/24
</Files>

Enforce strong passwords and two-factor authentication using a plugin such as WP 2FA or Wordfence Login Security. If your site runs on a Dedicated Server, consider placing the WordPress admin behind a VPN or SSH tunnel rather than exposing it to the public internet at all.

Protecting the Editor Role from Abuse

The Editor role is significantly safer than Administrator, but it is not without risk:

• An Editor with unfiltered_html can inject tracking pixels, affiliate redirects, or malicious scripts into post content. On Multisite, this capability is stripped — a strong argument for running a Multisite network when you have many content contributors.
• An Editor can permanently delete any post or page, including those they did not author. There is no built-in recycle bin for pages. Use a revision or backup strategy to mitigate this.
• An Editor can approve comments, including those containing spam links, which affects your site's SEO and reputation.

WordPress Multisite: How Roles Change

On a WordPress Multisite network, the role hierarchy gains an additional tier: Super Administrator. The Super Admin sits above all site-level Administrators and controls network-wide settings, plugin activation across all sites, and user creation at the network level.

On Multisite, a site-level Administrator loses several capabilities that exist on single-site installs, including the ability to install plugins (only Super Admins can do that network-wide) and the unfiltered_html capability. This makes Multisite a more defensible architecture for agencies managing client sites or publishers managing multiple editorial properties.

If you are building a multi-tenant publishing platform, a VPS with cPanel can simplify the server-side management layer while WordPress Multisite handles the application-layer role separation.

Custom Roles: When Neither Administrator nor Editor Fits

WordPress's add_role() and add_cap() functions allow you to define roles with precisely the capabilities your workflow requires. For example, a Senior Editor who can do everything an Editor can do plus manage users (but not plugins) can be created programmatically:

add_role(
    'senior_editor',
    'Senior Editor',
    array(
        // Inherit all standard Editor capabilities
        'read'                   => true,
        'edit_posts'             => true,
        'edit_others_posts'      => true,
        'edit_published_posts'   => true,
        'publish_posts'          => true,
        'delete_posts'           => true,
        'delete_others_posts'    => true,
        'delete_published_posts' => true,
        'edit_pages'             => true,
        'edit_others_pages'      => true,
        'edit_published_pages'   => true,
        'publish_pages'          => true,
        'delete_pages'           => true,
        'manage_categories'      => true,
        'moderate_comments'      => true,
        'upload_files'           => true,
        // Extended capability
        'list_users'             => true,
        'edit_users'             => true,
    )
);

Place this code in a site-specific plugin (not a theme's functions.php) so the role persists across theme changes. Roles are stored in the database after the first registration, so add_role() only needs to run once — wrap it in a plugin activation hook using register_activation_hook().

Practical Role Assignment Decision Matrix

Use this checklist before assigning any role:

Assign Administrator only if the user:

• Owns the site or has a contractual responsibility for its technical operation
• Needs to install, configure, or update plugins and themes
• Must manage other user accounts or change user roles
• Requires access to WordPress settings, permalink structure, or site URL
• Has two-factor authentication enabled and uses a unique, non-shared account
• Understands that DISALLOW_FILE_MODS will be set to true in production

Assign Editor if the user:

• Is responsible for content quality, publishing schedules, or editorial review
• Needs to manage posts and pages authored by other team members
• Should be able to moderate comments and manage media
• Does not need — and should not have — access to any plugin, theme, or settings screen
• May be a client, freelancer, or contractor whose account security you cannot fully control

Consider a custom role if:

• The built-in Editor is too restrictive (e.g., the user needs list_users for an editorial workflow plugin)
• The built-in Administrator is too permissive (e.g., a developer who needs plugin access but must not touch user accounts)
• You are running a Multisite network with differentiated responsibilities across sites

For teams managing WordPress alongside transactional email, consider pairing your role strategy with a dedicated Email Hosting setup so that WordPress notification emails (password resets, new user registrations, comment alerts) route through a reliable, authenticated mail server rather than the hosting server's default sendmail — a common deliverability failure point that affects every role's workflow.

If your WordPress site handles e-commerce, membership, or any user data, ensure your SSL Certificates are current and properly configured. An expired certificate does not just affect SEO — it breaks the browser security context that protects Administrator login credentials in transit.

Key Technical Takeaways

• WordPress capabilities are stored per-user in wp_usermeta, not hardcoded — they can be customized without changing a user's displayed role.
• DISALLOW_FILE_EDIT and DISALLOW_FILE_MODS in wp-config.php are non-negotiable on any production site with multiple Administrators.
• The unfiltered_html capability exists for both Administrators and Editors on single-site installs. Multisite strips it from everyone below Super Admin.
• An Editor can permanently delete any post or page, including other users' content. Implement a backup or revision strategy before granting this role to anyone outside your core team.
• Never use a shared Administrator account. One account per person, two-factor authentication mandatory, and audit logs enabled via a plugin such as WP Activity Log.
• Custom roles via add_role() are the correct solution when neither default role fits — do not over-provision to compensate for a missing capability.
• On Multisite, site-level Administrators cannot install plugins. This is a feature, not a limitation — it is the correct architecture for managed multi-tenant environments.

Frequently Asked Questions

Can an Editor delete another user's posts in WordPress?

Yes. The Editor role includes delete_others_posts and delete_others_pages. An Editor can permanently delete any post or page on the site, regardless of who authored it. There is no built-in confirmation step or recycle bin for pages, so this action is irreversible without a backup.

What is the difference between Administrator and Super Administrator in WordPress?

On a single-site WordPress install, Administrator is the highest role. On a WordPress Multisite network, Super Administrator sits above all site-level Administrators and controls network-wide settings, plugin installation across all sites, and the ability to add or remove sites from the network. A site-level Administrator on Multisite cannot install plugins or use unfiltered_html.

Can I give an Editor access to one specific plugin's settings without making them an Administrator?

Yes. Use add_cap() to grant a specific capability to an individual user, or create a custom role that includes the Editor's default capabilities plus the specific capability the plugin registers. Most well-coded plugins use current_user_can( 'manage_options' ) or a custom capability for their settings pages — check the plugin's source to identify the exact capability required.

Is it safe to have multiple Administrators on a WordPress site?

It depends entirely on your operational controls. Multiple Administrators multiply the attack surface — each account is a potential entry point. If multiple Administrators are necessary, enforce two-factor authentication for all of them, restrict /wp-admin/ access by IP at the server level, set DISALLOW_FILE_MODS to true, and use an activity log plugin to audit all administrative actions.

How do I audit which capabilities a specific WordPress user actually has?

Query the database directly or use a plugin like Members or User Role Editor. For a programmatic check, use get_user_meta( $user_id, $wpdb->prefix . 'capabilities', true ) in a custom script or the WordPress CLI:

wp user get <user_id> --field=roles
wp user list-caps <user_id>

The wp user list-caps command outputs every capability the user holds, including any that were granted individually outside their assigned role — which is the most reliable way to audit over-provisioned accounts.