What is the WordPress admin bar, and who sees it?

If you have ever logged into WordPress and noticed a dark horizontal bar across the top of the page, you have seen the WordPress admin bar.

More precisely, WordPress now calls it the Toolbar, although developers, plugins and site owners still commonly refer to it as the admin bar.

It can appear while you are:

• working inside the WordPress dashboard;
• viewing the public frontend while logged in;
• editing content;
• switching between the site and administration area.

The Toolbar provides shortcuts to actions and areas relevant to the current user, such as editing content, creating new posts, reviewing comments, opening profile settings or returning to the WordPress dashboard.

But not every user necessarily needs to see it on the frontend.

That distinction becomes particularly important on:

• membership sites;
• WooCommerce stores;
• client portals;
• learning platforms;
• community websites;
• sites with many non-administrative users.

This guide explains what the WordPress admin bar is, what it contains, who sees it, how frontend and backend behavior differ, how WordPress decides whether to display it and when hiding or customizing it makes sense.

What is the WordPress admin bar?

The WordPress admin bar is a horizontal navigation area displayed at the top of WordPress for logged-in users.

WordPress officially refers to it as the:

Toolbar

The official WordPress Toolbar documentation describes it as an area containing useful administration links and shortcuts.

Depending on the user, site configuration and installed plugins, it can provide quick access to things such as:

• the WordPress dashboard;
• site information;
• content creation;
• editing the current page or post;
• comments;
• updates;
• user profile options;
• plugin-specific actions.

Admin Bar vs. Toolbar: are they the same thing?

For practical purposes, yes.

The original interface was commonly called the:

Admin Bar

WordPress later standardized the user-facing name:

Toolbar

The official WP_Admin_Bar class documentation notes that the Toolbar replaced the Admin Bar terminology starting with WordPress 3.3.

However, the old terminology remains deeply embedded in WordPress development.

You will still encounter names such as:

WP_Admin_Bar

admin_bar_menu

show_admin_bar

is_admin_bar_showing

So when somebody says:

WordPress admin bar

and another person says:

WordPress Toolbar

they are normally talking about the same interface.

Where does the WordPress admin bar appear?

The Toolbar can appear in two different environments:

• the WordPress administration area;
• the public frontend of the website while a user is logged in.

These contexts look similar because the bar occupies the same general position, but they should not be treated as identical.

The Toolbar inside wp-admin

When you are working inside:

/wp-admin/

the Toolbar is part of the WordPress administration interface.

It normally appears across the top of administration screens and provides quick access to useful controls.

Modern WordPress integrates this Toolbar into the administration interface.

The standard user preference for showing or hiding the Toolbar while viewing the site does not function as a normal switch for removing the Toolbar from modern administration screens.

The official WordPress documentation explicitly notes that the Toolbar can no longer be hidden from the Administration Screens using the normal profile option.

The Toolbar on the frontend

The frontend is the public-facing portion of the WordPress site.

For example:

https://example.com/

https://example.com/about/

https://example.com/blog/article/

When a user is logged in, WordPress can display the Toolbar above that frontend content.

This creates a convenient bridge between:

viewing the website

and:

managing the website

An editor viewing a published article can therefore move directly to editing it without manually navigating through the dashboard.

Who sees the WordPress admin bar?

The simplest default rule is:

logged-out visitor
→
no Toolbar

logged-in user
→
Toolbar may appear

WordPress does not normally display the admin bar to anonymous visitors.

The Core is_admin_bar_showing() function checks whether a user is logged in before determining whether the frontend Toolbar should appear.

If the visitor is not authenticated, the function returns a state in which the admin bar is not shown.

Does every logged-in WordPress user see it?

By default, logged-in users can generally see the frontend Toolbar unless:

• their frontend Toolbar preference disables it;
• a plugin changes the behavior;
• a theme or custom code changes the behavior;
• another WordPress filter prevents it from appearing.

So:

logged in

does not always guarantee:

frontend Toolbar visible

WordPress stores a per-user frontend Toolbar preference

WordPress allows users to control whether the Toolbar appears while viewing the site.

The option is normally available under:

Users
→
Profile
→
Toolbar

with an option similar to:

Show Toolbar when viewing site

The official Toolbar documentation documents this profile preference.

The preference applies to the frontend

The important wording is:

when viewing site

This means the normal preference concerns the frontend Toolbar.

It should not be interpreted as:

remove every Toolbar
everywhere in WordPress

The administration Toolbar is integrated into modern WordPress administration screens.

How WordPress stores the preference

Internally, WordPress maintains a user preference associated with frontend Toolbar display.

Core’s private _get_admin_bar_pref() function reads the user’s relevant option and defaults to showing the Toolbar when no preference has been stored.

This means frontend Toolbar visibility can vary between users on the same website.

For example:

Administrator A
Toolbar visible

Administrator B
Toolbar hidden on frontend

Subscriber C
Toolbar visible

Subscriber D
Toolbar hidden

unless the site overrides those preferences globally or by role.

Does the user’s role determine whether the admin bar appears?

Not automatically in the simple sense of:

Administrator
→ visible

Subscriber
→ hidden

WordPress roles primarily control capabilities.

They do not inherently create a universal rule saying that only administrators receive the frontend Toolbar.

Therefore a Subscriber can potentially see a frontend Toolbar too.

What appears inside it, however, can differ because the user’s available actions depend on permissions and context.

A Subscriber can see an admin bar without being an administrator

This is an important distinction.

Seeing the Toolbar does not mean the user has administrative privileges.

Consider:

Subscriber
+
frontend Toolbar visible

This does not magically give the Subscriber:

• plugin installation access;
• theme editing access;
• user management privileges;
• site settings access;
• Administrator capabilities.

The Toolbar is an interface.

Capabilities remain the actual authorization layer.

The relationship between roles and permissions is covered in WordPress user roles and capabilities, explained.

The admin bar is not a security boundary

This deserves its own section because it is frequently misunderstood.

Hiding:

Edit Page

from the Toolbar does not secure the editing action.

Removing:

Dashboard

from the visible interface does not revoke dashboard capabilities.

Real authorization must still be enforced using the WordPress capability system.

For example, Core and plugins commonly use:

current_user_can()

to determine whether the current user is permitted to perform a particular action.

The official current_user_can() documentation describes the capability check WordPress developers should use when authorizing actions.

What appears inside the WordPress admin bar?

The exact contents vary.

A typical Toolbar may include some combination of:

• WordPress information;
• site name;
• dashboard shortcut;
• comments;
• New Content menu;
• Edit Page or Edit Post;
• profile access;
• logout;
• plugin-specific items.

The user’s permissions influence which actions are useful or available.

The WordPress logo menu

The left side of the Toolbar traditionally includes the WordPress logo.

Its menu can provide links related to:

• WordPress information;
• documentation;
• support;
• WordPress.org.

For administrators, developers and editors, these links may be useful.

For customers on a membership site, they may be completely irrelevant to the product experience.

The site-name menu

The Toolbar commonly provides the site name.

Depending on the current context, this helps users move between:

frontend
↕
dashboard

This is one of the main productivity benefits of the Toolbar for people who actively manage the website.

The New menu

Users with suitable permissions may see a:

+ New

menu.

It can provide shortcuts for creating content such as:

• posts;
• pages;
• media;
• users;
• custom content types added by plugins.

The exact entries depend on installed functionality and the current user’s capabilities.

The Edit Page or Edit Post shortcut

This is one of the most useful Toolbar features for editors.

Imagine viewing:

https://example.com/services/

while logged in.

If your account has permission to edit that page, WordPress can provide a Toolbar shortcut such as:

Edit Page

This removes several navigation steps from the editing workflow.

Plugins can add their own Toolbar items

The Toolbar is extensible.

Plugins may add shortcuts for:

• SEO tools;
• caching;
• page builders;
• analytics;
• forms;
• e-commerce;
• debugging;
• maintenance tools.

As more plugins add entries, the Toolbar can become significantly more crowded.

How developers modify the Toolbar

WordPress provides an API around the:

WP_Admin_Bar

object.

The WP_Admin_Bar class is Core’s implementation of the Toolbar API.

Developers commonly interact with it through hooks such as:

admin_bar_menu

The official admin_bar_menu hook allows plugins and themes to modify the Toolbar after WordPress has created its menu structure.

Toolbar nodes are individual menu items

Conceptually, the bar contains nodes such as:

WordPress logo
Site name
Comments
New
Edit
Profile

Plugins can:

• add nodes;
• remove nodes;
• modify existing nodes;
• add nested child items.

Removing one Toolbar item is different from hiding the whole bar

This distinction matters.

You may want to keep:

Toolbar
+
Edit Page
+
Profile

but remove:

WordPress logo
Comments
unnecessary plugin shortcut

That requires item-level customization rather than hiding the entire interface.

TheOneWP Disable Admin Bar Items is designed for that narrower use case.

When should you keep the WordPress admin bar?

The Toolbar is particularly useful for people who actively work on the website.

Examples include:

• administrators;
• editors;
• content managers;
• authors;
• developers;
• support staff.

These users may frequently switch between the frontend and backend.

For them:

frontend
→
Edit Page
→
make change
→
View Page

is a very efficient workflow.

When might you hide the frontend admin bar?

The calculation changes when logged-in users are customers rather than site operators.

Examples include:

• membership subscribers;
• students;
• community members;
• WooCommerce customers;
• client portal users;
• employees using a frontend application.

These users may not need WordPress-specific controls at all.

Membership sites are a common example

Imagine a paid member logging into a professional learning platform.

The site’s navigation says:

Dashboard
My Courses
Resources
Account

but WordPress also places a separate dark bar above it with:

WordPress logo
Site Name
Profile
other WordPress controls

That can make the experience feel less like one product and more like two interfaces layered on top of each other.

For this type of site, hiding the frontend Toolbar from ordinary members can improve usability.

See A WordPress membership site UX checklist for the broader member-facing experience.

WooCommerce customers often do not need it either

A customer expects to interact with:

My Account
Orders
Downloads
Addresses
Payment methods

They usually do not need a WordPress-oriented administration interface.

Again, the goal is UX cleanup, not security.

Should Authors see the admin bar?

Often, yes.

An Author who publishes content can benefit from shortcuts such as:

• Edit Post;
• New Post;
• profile;
• dashboard access.

But the right choice depends on the site’s workflow.

A frontend publishing system may intentionally hide most WordPress administration interfaces even from content contributors.

Should Editors see the admin bar?

Editors are one of the clearest cases for keeping it.

They frequently:

• review published pages;
• edit content;
• move between frontend and backend;
• manage posts;
• review comments.

Removing the Toolbar can create extra navigation work for them unless the site provides an equivalent custom interface.

Should Administrators see it?

In most traditional WordPress workflows, yes.

The Toolbar provides administrators with quick access to management functions and context-sensitive actions.

There is usually little UX reason to hide it from administrators unless the site has a highly customized management workflow.

Can users hide the frontend Toolbar themselves?

Yes, where the site has not overridden the behavior.

A user can normally navigate to their profile and disable:

Show Toolbar when viewing site

That changes their personal frontend preference.

Can a site override the user’s preference?

Yes.

WordPress exposes the:

show_admin_bar

filter.

The official show_admin_bar filter documentation identifies returning false as the recommended way to prevent the frontend Toolbar from being displayed.

For example:

add_filter( 'show_admin_bar', '__return_false' );

can hide it on the frontend.

WordPress also provides show_admin_bar()

Core includes:

show_admin_bar( $show )

The official show_admin_bar() function documentation describes it as a way to set the display status of the admin bar.

This can be useful when a plugin or theme needs programmatic control.

How to hide the frontend Toolbar conditionally

A site may decide:

Administrators
→ show

Editors
→ show

Members
→ hide

The actual implementation should normally be based on capabilities or an intentional role policy.

For example, developers can combine frontend Toolbar filtering with:

current_user_can()

to decide which users should retain it.

Role-based hiding and capability-based authorization are different

You might configure:

Subscriber
→ hide Toolbar

because Subscribers are customers.

That is a UX rule.

Separately, WordPress may enforce:

Subscriber
→ cannot edit pages

through capabilities.

That is an authorization rule.

Do not combine the two concepts mentally.

How TheOneWP Hide Admin Bar fits

TheOneWP Hide Admin Bar provides role-based control over admin-bar visibility.

This is useful when a site wants a centralized policy instead of relying entirely on each user’s personal frontend preference.

Typical examples include:

Administrators
→ keep Toolbar

Editors
→ keep Toolbar

Customers
→ hide Toolbar

Members
→ hide Toolbar

TheOneWP can distinguish frontend and backend behavior

The Hide Admin Bar feature can apply visibility rules to different contexts rather than assuming one setting should fit every workflow.

This matters because:

frontend Toolbar UX

and:

backend administration UX

are separate design questions.

A role may need WordPress administration access while not needing the same Toolbar treatment on the public frontend, or vice versa depending on the site’s architecture.

Custom roles need deliberate treatment

Membership and workflow plugins frequently create roles such as:

Premium Member

Instructor

Vendor

Course Manager

Support Agent

Do not assume those custom roles automatically deserve the same Toolbar behavior as a built-in role that happens to sound similar.

Decide based on what those users actually do.

Hiding the Toolbar does not block wp-admin

This is another critical distinction.

If you hide the frontend Toolbar from a user, that does not necessarily prevent them from requesting:

/wp-admin/

If their account has permission to access an administration screen, Toolbar visibility does not change that permission.

If they do not have permission, WordPress capabilities should enforce the restriction.

Hiding the Toolbar does not remove WordPress capabilities

Suppose an Editor can:

edit_pages

and you hide the admin bar.

The Editor does not suddenly lose:

edit_pages

The capability remains.

Only a navigation interface has changed.

Hiding the Toolbar is not login protection

It also does not:

• change the login URL;
• block brute-force attempts;
• enable two-factor authentication;
• prevent username enumeration;
• restrict REST API access;
• disable wp-admin;
• revoke user sessions.

Those problems require different controls.

Does the admin bar affect frontend layout?

It can.

When WordPress renders the frontend Toolbar, the page may need space at the top so the bar does not cover site content.

The exact effect depends on:

• theme CSS;
• fixed headers;
• sticky navigation;
• custom page builders;
• responsive breakpoints.

Fixed headers can conflict with the admin bar

A common problem looks like:

WordPress Toolbar
+
fixed site header
+
incorrect top offset
=
overlap

This is why a site can look correct while logged out but appear broken while an administrator is logged in.

Always test frontend layouts while logged in

Developers often test a page while authenticated because they are actively editing it.

But they should deliberately compare:

logged-in layout

with:

logged-out layout

Especially inspect:

• fixed headers;
• mobile menus;
• full-height hero sections;
• sticky banners;
• off-canvas navigation;
• top-positioned overlays.

Why can the frontend admin bar disappear unexpectedly?

If a logged-in user expects the Toolbar but does not see it, several explanations are possible.

The user disabled it

Check:

Users
→
Profile
→
Show Toolbar when viewing site

A plugin hides it

Security, membership, white-label or UX plugins may filter Toolbar visibility.

Custom theme code hides it

A theme may call:

show_admin_bar( false )

or filter:

show_admin_bar

The theme is missing an expected hook

The official WordPress Toolbar documentation notes that a missing wp_footer() call in a theme can be a reason the frontend Toolbar fails to appear correctly.

Why can the admin bar still appear after changing a setting?

The reverse problem can also occur.

Potential causes include:

• a plugin forcing it on;
• custom code overriding the user preference;
• role-based rules;
• cache confusion;
• testing a different account from the one whose preference was changed.

Always verify behavior with the specific affected user.

The Toolbar can differ between users

Do not inspect the bar as Administrator and assume every user sees the same thing.

Test representative accounts:

Administrator
Editor
Author
Subscriber
custom member
custom staff role

Plugins and capabilities may create significant differences in available nodes.

Multisite adds additional Toolbar items

On WordPress Multisite, the Toolbar can provide network-related navigation such as:

My Sites

and access to sites associated with the current account.

This makes the Toolbar even more important for network administrators and users who work across multiple sites.

Should you customize or completely remove the Toolbar?

Use the smallest change that solves the problem.

If the problem is:

members should not see WordPress controls

then hiding the frontend Toolbar for those roles can make sense.

If the problem is:

staff need the Toolbar
but several items are irrelevant

then removing selected nodes is usually more appropriate.

Hide Admin Bar vs. Disable Admin Bar Items

Hide Admin Bar

Use Hide Admin Bar when the entire Toolbar should disappear for selected users or contexts.

Disable Admin Bar Items

Use Disable Admin Bar Items when users still benefit from the Toolbar but some individual entries are unnecessary.

The difference is:

Hide Admin Bar
→
remove the interface

Disable Admin Bar Items
→
keep interface
+
remove selected controls

Do not remove useful shortcuts just to make WordPress look cleaner

Minimalism is useful only when it reduces real clutter.

If editors rely on:

Edit Page

twenty times per day, removing it creates friction.

If subscribers have no reason to see any WordPress Toolbar at all, keeping it creates friction.

The correct configuration depends on the role.

Admin bar UX for membership sites

A membership-site configuration might look like:

Administrator
Toolbar visible

Editor
Toolbar visible

Instructor
Toolbar visible or customized

Member
Toolbar hidden

This allows staff to retain productivity shortcuts without exposing WordPress-oriented navigation to customers.

For the larger design picture, see A WordPress membership site UX checklist.

Admin bar UX for client websites

An agency may give clients WordPress access while trying to simplify the backend.

Possible approaches include:

• keeping the Toolbar intact;
• removing developer-only items;
• keeping only common editing shortcuts;
• hiding the frontend Toolbar from specific client roles.

The important part is to preserve the controls the client actually needs.

Admin bar UX for WooCommerce sites

WooCommerce sites may contain two very different populations:

store staff
+
customers

Store staff can benefit from WordPress Toolbar shortcuts.

Customers typically interact through frontend account pages and may not benefit from WordPress-specific navigation.

This makes role-aware Toolbar design particularly valuable.

Admin bar UX for editorial teams

An editorial site may instead keep it visible for:

• Authors;
• Editors;
• Administrators.

because switching between published content and editing screens is part of the daily workflow.

The Toolbar should follow the job, not the title

Instead of asking:

Is this user an Editor?

ask:

Does this person need
Toolbar shortcuts to do their work?

A custom Instructor role may need editing shortcuts.

A custom Premium Member role probably does not.

How to audit the WordPress admin bar on your site

Use representative test accounts rather than checking only as Administrator.

1. Log in as Administrator

Record:

• frontend Toolbar visibility;
• backend Toolbar visibility;
• available nodes;
• plugin-added entries.

2. Log in as Editor

Check whether useful editorial actions remain available.

3. Log in as Author or Contributor

Verify that the Toolbar reflects actual content permissions.

4. Log in as Subscriber

Ask whether any visible Toolbar items provide meaningful value.

5. Test custom roles

Membership, LMS and marketplace plugins often introduce their own role models.

6. Check mobile behavior

The Toolbar changes shape on smaller screens.

Make sure it does not interfere with:

• site navigation;
• sticky headers;
• account menus;
• important frontend controls.

7. Test logged-out visitors

Confirm that layout assumptions do not depend on Toolbar spacing.

WordPress admin bar checklist

• Confirm whether the Toolbar is needed by each user type.
• Test the frontend while logged in.
• Test the frontend while logged out.
• Check the user’s “Show Toolbar when viewing site” preference.
• Do not assume the frontend preference removes the administration Toolbar.
• Do not assume only Administrators can see the frontend Toolbar.
• Check custom roles individually.
• Review plugin-added Toolbar items.
• Remove individual nodes when the full Toolbar remains useful.
• Hide the entire frontend Toolbar when it provides no user value.
• Keep useful editing shortcuts for staff where appropriate.
• Check fixed-header and Toolbar overlap.
• Test mobile layouts.
• Do not treat Toolbar visibility as access control.
• Use capabilities to enforce real permissions.
• Do not assume hiding the Toolbar blocks wp-admin.
• Check membership and customer roles separately from editorial roles.
• Verify behavior with representative test accounts.

Common WordPress admin bar misconceptions

“Only administrators see the admin bar”

Incorrect.

Other logged-in users can see the frontend Toolbar too.

“If someone sees the admin bar, they are an administrator”

Incorrect.

Toolbar visibility does not determine privileges.

“Hiding the admin bar secures wp-admin”

Incorrect.

It changes interface visibility, not authorization.

“The profile setting hides the Toolbar everywhere”

Incorrect.

The standard preference concerns showing the Toolbar while viewing the site.

“Removing Edit Page prevents someone from editing pages”

Incorrect.

The edit_pages capability and related permission checks determine whether the action is permitted.

“Every logged-in user sees exactly the same Toolbar”

Incorrect.

Capabilities, context and plugins can change the available items.

Related WordPress admin and access guides

• A WordPress membership site UX checklist
• WordPress user roles and capabilities, explained
• WordPress login redirects by role, explained
• How to target WordPress users by role
• Custom WordPress roles vs. combining existing ones
• How to audit user roles on a WordPress site
• Hide Admin Bar
• Disable Admin Bar Items
• Role Manager
• Redirect After Login
• Redirect After Logout

Final thoughts

The WordPress admin bar is a convenience layer, not a permission system.

Its job is to give logged-in users fast access to actions that are relevant to them.

For an editor, that can be extremely useful:

view page
↓
Edit Page
↓
make change
↓
return to frontend

For a customer or membership subscriber, the same interface may provide little value and make the website feel less cohesive.

The right question is therefore not:

Should WordPress have an admin bar?

It is:

Which users benefit from it,
in which context,
and which controls do they actually need?

Keep it where it improves the workflow.

Customize it where only some shortcuts are useful.

Hide it where it adds unnecessary WordPress-oriented interface to a member or customer experience.

And regardless of what is visible, continue using WordPress roles and capabilities as the real authorization layer underneath it.