The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →To hide the WordPress Admin Bar (also called the Toolbar) on the public-facing site, use WordPress’s supported visibility API rather than CSS or by unhooking internal callbacks. For every logged-in user, add this filter in a site-specific plugin or your active theme’s functions.php:
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
add_filter( 'show_admin_bar', '__return_false' );This removes the bar from front-end pages only. It does not remove dashboard navigation, change a user’s role, or revoke any capability. If administrators should keep the bar while regular users lose it, use a capability check instead:
As an Amazon Associate I earn from qualifying purchases.
Recommended Free Tools
add_action( 'after_setup_theme', function () {
if ( ! current_user_can( 'manage_options' ) ) {
show_admin_bar( false );
}
} );The function show_admin_bar() has been part of WordPress since version 3.1.0. The show_admin_bar filter is the recommended way to return false when the front-end Toolbar should be hidden.
What the Admin Bar is—and what hiding it changes
The Admin Bar is the dark Toolbar WordPress displays to logged-in users while they view the public site. Depending on the user’s permissions, it can contain links to WordPress information, post and page creation, user management, comment moderation, and update notices. It is a convenience layer, not the dashboard itself.
#1 Best Overall
Calling show_admin_bar( false ) or returning false from the show_admin_bar filter changes front-end visibility. It does not delete Toolbar menus, disable the /wp-admin/ area, or alter capabilities. A subscriber remains a subscriber, an editor remains an editor, and an administrator still has administrator privileges unless you separately change roles or capabilities.
WordPress calculates front-end visibility for each logged-in user. The user’s profile preference is part of that calculation, so a code-based rule and an individual “Show Toolbar when viewing site” setting can both matter. The dashboard Toolbar is a separate concern: WordPress does not provide this front-end filter as a way to turn off dashboard navigation.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCrashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteChoose the rule that matches your requirement
| Requirement | Recommended method | Front end | Dashboard | Targeting and maintenance |
|---|---|---|---|---|
| Hide the bar from every logged-in user | add_filter( 'show_admin_bar', '__return_false' ); |
Hidden for all users affected by the filter | Dashboard access and navigation remain available | Simple, but broad filters can conflict when placed in a shared public plugin |
| Keep it for administrators, hide it for everyone else | after_setup_theme plus current_user_can( 'manage_options' ) |
Hidden for users without the capability | Unchanged | Capability-based and adaptable when roles differ |
| Hide it from subscribers specifically | A conditional show_admin_bar( false ) callback |
Hidden for users matching the condition | Unchanged | Role-oriented; less flexible than a capability rule if your site adds custom roles |
| Let site owners configure rules without PHP | A maintained role-based Toolbar plugin | Depends on the plugin’s settings | Depends on the plugin; verify its scope | Settings are easier for non-developers, but introduce an additional dependency |
| Remove the bar with CSS only | Not recommended as the primary solution | May conceal pixels while markup and scripts still load | Does not address dashboard behavior | Can leave spacing, accessibility, and performance problems |
Use a capability test when the actual requirement is “non-admin users.” Capabilities describe what a user can do and continue to work when your site uses custom roles. A literal role-name test is appropriate only when that exact role is the business rule.
Method 1: hide the Toolbar for every logged-in user
Use the documented filter
Add the following line in a site-specific plugin or the active theme’s functions.php:
add_filter( 'show_admin_bar', '__return_false' );The filter runs when WordPress determines whether the front-end Toolbar should be displayed. Returning false is the documented approach for this purpose. It avoids trying to dismantle the Toolbar after WordPress has initialized it.
Where to place the code
- Site-specific plugin: Best when the rule belongs to the site rather than to its visual theme. The setting survives a theme change.
- Child theme
functions.php: Suitable when the rule is part of the theme’s front-end behavior. Use a child theme so a parent-theme update does not overwrite the file. - Temporary testing: Add the line in a controlled staging environment first, then test with accounts representing each permission level.
Do not paste PHP into a page, post, widget, or a CSS editor. Those locations cannot execute the callback as PHP and may expose code as text.
What users will experience
On a front-end page, the Toolbar no longer occupies its normal top position for users affected by the filter. The account can still sign in, visit permitted dashboard screens, create or edit content according to its capabilities, and receive ordinary WordPress responses. Only the front-end Toolbar display decision has changed.
Method 2: keep the bar for administrators and hide it for other users
Use a capability condition
This pattern leaves the Toolbar available to users who have the manage_options capability and hides it for everyone else:
add_action( 'after_setup_theme', function () {
if ( ! current_user_can( 'manage_options' ) ) {
show_admin_bar( false );
}
} );after_setup_theme is an early, reliable point for theme setup. The callback checks the current account, then calls the core function immediately for users who do not meet the capability test. Administrators normally have manage_options; if your installation deliberately assigns that capability differently, the result follows the capability assignment rather than the role label.
Why capability checks are usually better than role names
WordPress sites can have custom roles, membership roles, and plugins that add or remove capabilities. “Hide from non-admin users” is a permission requirement, so checking a capability expresses it directly. A role check can miss a custom role that should be treated like an administrator or accidentally include a role whose name happens to match your test.
When to choose a different capability
If your site has a defined editorial group, select a capability that accurately represents that group’s access rather than copying manage_options automatically. Document the decision for whoever maintains the site. The visibility rule should not be used to compensate for an incorrect role configuration.
Method 3: target subscribers or another specific group
Subscriber-specific example
WordPress.org support documentation shows this subscriber-oriented pattern:
function hide_admin_bar_for_subscribers() {
if ( current_user_can( 'subscriber' ) ) {
show_admin_bar( false );
}
}
add_action( 'after_setup_theme', 'hide_admin_bar_for_subscribers' );This targets accounts identified as subscribers by the condition. It is useful when the rule is explicitly “subscribers should not see the front-end Toolbar,” but it is narrower than the capability approach. On a site with custom roles or a requirement covering all non-administrators, prefer a capability test.
Multiple groups
For more than one group, write the business rule first: for example, “show the bar only to users who can manage options or edit published posts.” Then combine capability checks in one conditional. Avoid scattering several callbacks across different files, because the final visibility can become difficult to trace.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minuteadd_action( 'after_setup_theme', function () {
$may_keep_toolbar = current_user_can( 'manage_options' )
|| current_user_can( 'edit_published_posts' );
if ( ! $may_keep_toolbar ) {
show_admin_bar( false );
}
} );Test the resulting rule with an administrator, an editor, a subscriber, and any custom role that your site actually uses. The account’s capabilities—not the label shown in the Users screen—determine the outcome.
Understand the per-user Toolbar preference
Each user can open the profile screen and change Show Toolbar when viewing site. WordPress reads that preference when calculating front-end visibility. Consequently, an administrator may not see the Toolbar even when your code does not hide it, simply because that user disabled the preference.
Interpreting a mismatch
- Your code hides the bar for a group: A user preference cannot be used to override a rule that forces
show_admin_bar( false )for that account. - Your code allows the bar: The user’s profile setting can still leave it hidden.
- The setting is enabled but the bar is absent: Inspect the theme and other plugins before changing the visibility rule.
Ask the affected user to check the profile setting only after confirming that the account falls into the group intended to see the Toolbar. Changing the preference does not grant new permissions.
Front end versus dashboard: an essential boundary
The documented filter toggles the Toolbar on the front side of the website. It is not a supported way to remove dashboard navigation. WordPress explicitly distinguishes the front-end Toolbar from the admin-area interface; you cannot turn off the dashboard Toolbar by treating it as the same front-end display decision.
Rank #4
If your goal is to prevent users from opening dashboard screens, solve that separately with roles and capabilities, then test authorization. Hiding a link is not access control. A user who still has a capability may reach a screen through a direct URL, and a user without a capability should be denied regardless of whether a link is visible.
Why CSS-only hiding is an incomplete fix
A CSS rule such as hiding the Toolbar element can make it look gone, but it does not use WordPress’s visibility API. The Toolbar markup, styles, and scripts may still be generated. Themes often add top margins or body padding when the Toolbar is present, so concealing only the element can leave a blank strip. CSS also does nothing to dashboard behavior or permissions.
Use the PHP filter or show_admin_bar( false ) so WordPress makes the visibility decision before the front-end layout is rendered. If a design system still needs a visual adjustment, treat that as a separate, measured styling task after confirming that the core Toolbar is actually disabled.
No-code option: configure a role-based Toolbar plugin
If you cannot edit PHP, a WordPress.org plugin listing titled Hide Admin Bar Based on User Roles advertises controls for subscribers, WooCommerce customers, all users, and custom visibility by role, capability, device, page, or time. This can be appropriate for site owners who need settings screens rather than code.
Free tools Windows power users keep installed
One-click scans. No signup required.
Checks before activating one
- Confirm that the plugin is maintained for the WordPress version you run and that its author documents the front-end versus dashboard scope.
- Read whether its rules hide only the Toolbar or also attempt to restrict dashboard access.
- Check for interactions with membership, caching, optimization, and role-management plugins.
- Test with each relevant account type on a staging copy before enabling it on a live site.
- Keep a written record of the rule so the behavior remains understandable if the plugin is removed.
A settings-based plugin does not change the underlying principle: visibility is not permission control. If the plugin offers both features, configure authorization separately and verify it with direct-access tests.
Placement and conflict guidance for developers
Theme code versus a site plugin
Use theme code when the Toolbar decision is part of the presentation layer and should change with the theme. Use a site-specific plugin when the rule is a site policy that must remain after a redesign. A custom plugin also keeps policy code out of a theme file that designers may edit.
Best Value
Avoid a broad filter in shared public plugins
The official function reference cautions that a broadly scoped filter in a shared public plugin can conflict with other code. A plugin intended for many unrelated sites should not silently force the Toolbar off for every account. Scope the behavior to an explicit setting, a documented capability rule, or a site-specific integration.
Do not unhook _wp_admin_bar_init()
WordPress warns against unhooking the internal _wp_admin_bar_init() callback as a removal technique. That approach does not properly remove the Toolbar and can interfere with the normal initialization sequence. Use show_admin_bar( false ) or the show_admin_bar filter instead.
Test the change systematically
- Back up or use staging. A syntax error in a theme file can make the front end or dashboard unavailable. Keep a recovery route before editing PHP.
- Test while logged out. The Toolbar is a logged-in feature, so confirm that public visitors still receive the expected page layout.
- Test an administrator. Verify that the administrator sees the bar when your rule is intended to preserve it, and check the profile preference if it is missing.
- Test a regular account. Use a subscriber or the site’s ordinary member role and confirm that the bar disappears only where intended.
- Test the dashboard directly. Open the dashboard as the regular account and confirm that your visibility change did not alter legitimate access or create an unintended promise of access.
- Test representative templates. Check the home page, a post, a page, archive views, and any custom front-end templates. A theme can behave differently across templates.
- Clear relevant caches. Purge page, object, browser, and optimization caches only after confirming that the PHP rule is active. Cached HTML can make an old Toolbar state appear to persist.
- Check mobile and desktop. Responsive CSS or a device-specific plugin can make the bar appear absent even when WordPress still generates it.
Troubleshoot an unexpectedly missing or partly hidden Toolbar
The profile setting is enabled, but no Toolbar appears
WordPress Toolbar documentation identifies two common causes: the active theme may not call wp_footer(), or another plugin may have disabled the Toolbar. Inspect the theme’s footer template and confirm that it includes the standard footer hook before changing your visibility code. Then disable suspected plugins one at a time in staging to identify an override.
A blank strip remains at the top
Inspect theme margins, body padding, Toolbar-related classes, cached CSS, and optimization layers. A blank strip usually means the layout still reserves space even though the Toolbar is no longer visible. Remove only the CSS or spacing that your theme added; do not replace the supported visibility rule with a CSS-only solution.
Administrators lose the bar too
Check whether a global add_filter( 'show_admin_bar', '__return_false' ) line exists in a plugin, a parent theme, or a must-use plugin. Also check the administrator’s profile preference. If the requirement is “hide from non-admins,” replace the global rule with the capability-based callback and retest.
The bar appears for users who should not have it
Verify the actual capabilities of the account and look for code that later returns true from the same filter. Search active plugins and the theme for show_admin_bar and show_admin_bar(. A role-management plugin may have changed capabilities without changing the visible role label.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →The front end works, but editing PHP caused a fatal error
Restore the previous file through your host’s file manager, deployment system, or a working backup. If a site-specific plugin caused the error, deactivate it through the available recovery method, then correct the syntax in staging. Keep the callback small and avoid adding unrelated logic while diagnosing the problem.
Common mistakes to avoid
- Confusing hiding with security: Removing a Toolbar link does not revoke a capability or protect a dashboard URL.
- Using a role name for a capability requirement: Custom roles can make a literal role test incomplete.
- Editing a parent theme: An update can erase the change.
- Unhooking internal initialization: WordPress does not support that as the proper removal method.
- Assuming a missing bar proves your code worked: The user preference, missing
wp_footer(), another plugin, or cached output may be responsible. - Leaving broad policy code undocumented: Future maintainers may not know why administrators or members see different interfaces.
How to undo the change
For a global filter, remove or comment out the add_filter( 'show_admin_bar', '__return_false' ); line, then clear relevant caches. For a conditional callback, remove that callback or change its condition, and verify each account type again. Finally, check the user profile preference for any account that still does not see the Toolbar. Reversing visibility code does not restore a capability that was separately changed elsewhere.
Practical decision guide
- If nobody should see the front-end Toolbar, use the documented global filter.
- If administrators should keep it, use
current_user_can( 'manage_options' )(or another capability that accurately defines your privileged group) and callshow_admin_bar( false )for everyone else. - If the rule is specifically about subscribers, a subscriber condition can express that narrow requirement; revisit it if custom roles are introduced.
- If non-developers must manage several conditions, evaluate a maintained role-based plugin, checking its scope and compatibility first.
- If the objective is dashboard restriction, configure capabilities and authorization separately; do not rely on Toolbar visibility.
The Bottom Line
Use show_admin_bar( false ) or the show_admin_bar filter to hide WordPress’s front-end Toolbar. Apply a capability condition when administrators should retain it, respect each user’s “Show Toolbar when viewing site” preference, and treat dashboard permissions as a separate control.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
