How to Widen the WordPress Admin Menu

Widening the WordPress admin menu can make wp-admin considerably easier to use when long menu labels, translated strings or plugin-generated navigation no longer fit comfortably inside the default sidebar.

The standard expanded WordPress administration menu is approximately:

160px

wide.

That is enough for ordinary labels such as:

Posts
Pages
Media
Users
Settings

but it can become restrictive when a site contains items such as:

Customer Management
Advanced Product Configuration
Marketing Automations
Membership Management
Translation Management

or when translated labels are significantly longer than their English equivalents.

However, widening the WordPress admin menu correctly involves more than changing:

#adminmenu {
    width: 220px;
}

The sidebar is made from several related elements, and the main administration content is positioned according to the expected menu width. WordPress also has a folded sidebar state and responsive breakpoints that should continue to work.

A complete customization therefore needs to consider:

• #adminmenu;
• #adminmenuwrap;
• #adminmenuback;
• #wpcontent;
• #wpfooter;
• submenu positioning;
• the folded admin state;
• the 960px auto-fold breakpoint;
• the 782px mobile administration breakpoint;
• third-party panels that assume the default 160px width.

This guide explains how to widen the WordPress admin menu safely, which Core layout elements need to move together, why simple CSS snippets often break plugin panels, how to preserve WordPress responsive behavior and when a wider sidebar is actually the right solution.

How the WordPress admin sidebar is structured

The WordPress administration area is not built from a single sidebar element.

Core uses several related containers.

The primary navigation list is:

#adminmenu

while its surrounding elements include:

#adminmenuwrap
#adminmenuback

The main administration content is contained inside:

#wpcontent

and the administration footer uses:

#wpfooter

The current WordPress Core administration stylesheet can be inspected directly in wp-admin/css/common.css.

The relationship can be simplified as:

Sidebar
├── #adminmenuback
├── #adminmenuwrap
└── #adminmenu

Content
└── #wpcontent

Footer
└── #wpfooter

Changing only one of those elements produces an incomplete layout.

The default expanded width is approximately 160px

In the classic expanded administration layout, WordPress reserves approximately:

160px

for the left navigation.

The main work area is correspondingly offset from the sidebar.

Conceptually:

┌────────────────┬──────────────────────────────┐
│                │                              │
│   Admin menu   │        Main content          │
│     160px      │                              │
│                │                              │
└────────────────┴──────────────────────────────┘

If you increase the sidebar to:

220px

but leave the content offset at:

160px

the additional 60px can overlap the administration content.

The folded sidebar is different

WordPress can also display a compact administration menu of approximately:

36px

wide.

That state is used when the user manually collapses the menu and as part of WordPress’s responsive behavior.

A custom width intended for the expanded sidebar should not automatically turn:

36px

into:

220px

when WordPress is deliberately using its compact interface.

For the responsive states themselves, read WordPress Admin Menu Responsive Breakpoints, Explained.

Why would you widen the WordPress admin menu?

A wider sidebar is most useful when the current width creates an actual usability problem.

One of the most common examples is long menu labels.

A plugin might register:

Marketing Automation

instead of:

Marketing

At the default width, the longer label may:

• wrap onto multiple lines;
• make menu items unusually tall;
• look visually inconsistent;
• make scanning slower;
• crowd notification counters;
• create awkward submenu positioning.

Translated WordPress installations often need more room

A label that fits easily in English may become substantially longer after translation.

The sidebar width itself does not dynamically expand according to the active language.

A wider menu can therefore be particularly useful on multilingual or localized administration interfaces.

Plugin-heavy sites create longer navigation systems

A site using WooCommerce, SEO tools, page builders, analytics tools, membership plugins and custom development can accumulate many top-level menu entries.

The problem is not only the number of entries.

The labels themselves may have been created independently by multiple plugin developers, each assuming the default width would somehow accommodate their preferred wording.

Sometimes increasing the width slightly is enough to make the whole interface easier to scan.

A wider menu is not always the solution

If the site contains:

35 top-level menu items

then the primary problem may be information architecture rather than width.

In that situation, consider reorganizing or reducing the menu instead.

TheOneWP Admin Menu Organizer can reorganize, rename and restructure WordPress administration navigation and apply role-aware visibility rules.

A wider sidebar should improve readable navigation, not become a larger container for an already chaotic menu.

How to widen the menu with CSS

Suppose you want to change the expanded WordPress admin menu from:

160px

to:

220px

A basic implementation needs to resize the menu containers and move the work area accordingly.

For example:

@media screen and (min-width: 961px) {

    #adminmenuback,
    #adminmenuwrap,
    #adminmenu {
        width: 220px;
    }

    #wpcontent,
    #wpfooter {
        margin-left: 220px;
    }

}

The important part is that the sidebar and the content offset use the same width.

Conceptually:

Sidebar width
=
Content starting position

Why use min-width: 961px?

The current WordPress breakpoint definitions identify:

960px

as the point where the administration sidebar auto-folds.

You can inspect the current shared breakpoint definitions in the official WordPress Gutenberg breakpoint source.

The relevant values include:

960px
→ admin sidebar auto folds

782px
→ mobile-oriented admin state

By applying the custom expanded width only at:

min-width: 961px

you allow WordPress’s normal compact and mobile behavior to take over below the desktop range.

Do not simply override the width at every viewport

This is risky:

#adminmenu,
#adminmenuwrap,
#adminmenuback {
    width: 240px !important;
}

because it can also interfere with:

• the responsive folded state;
• mobile administration;
• touch navigation;
• submenu positioning;
• Core media-query rules.

A custom desktop width should normally stop applying when WordPress itself decides that the permanent expanded sidebar no longer fits.

Submenus need to follow the new sidebar width

Changing the three primary sidebar widths is only part of the job.

Folded and flyout submenus can also rely on positioning related to the sidebar.

WordPress submenu elements use classes such as:

.wp-submenu

and their positioning differs depending on whether the main menu is expanded or folded.

When the menu is expanded, submenus normally appear as part of the left navigation hierarchy.

When it is folded, they can appear as flyout panels.

Your custom width therefore needs to preserve:

expanded layout
→ wider persistent navigation

folded layout
→ normal compact WordPress behavior

rather than widening both indiscriminately.

Test plugin-created submenus too

Core menu items are usually only the beginning.

Plugins can add:

• their own submenu containers;
• custom counters;
• badges;
• additional icons;
• CSS targeting the normal sidebar width.

After widening the menu, open every major submenu and verify that labels, arrows and flyout panels still align correctly.

The real problem: other plugins may assume 160px

The most difficult part of widening wp-admin is often not WordPress Core.

It is third-party code.

Some plugins position administration elements with values such as:

left: 160px;

or:

margin-left: 160px;

because they assume the WordPress sidebar will never change.

Examples can include:

• developer toolbars;
• debug panels;
• fixed plugin headers;
• sticky navigation;
• bottom drawers;
• notification panels;
• fullscreen plugin applications.

This issue is covered in detail in Why WordPress Plugins Hardcode 160px into their Panels.

What happens after widening the sidebar?

Suppose you change WordPress to:

220px

but another plugin still uses:

left: 160px;

Its panel may begin:

60px inside the wider menu

instead of beside it.

The result can be:

• overlapping controls;
• hidden content;
• broken click targets;
• incorrect stacking;
• visual gaps;
• panels appearing under the sidebar.

Search your own admin CSS for width assumptions

If you maintain custom plugins or agency code, search for values such as:

160px
36px

alongside properties such as:

left
right
margin-left
padding-left
width
calc()

Do not assume every occurrence is related to the WordPress sidebar, but inspect the ones used inside wp-admin carefully.

A cleaner implementation with a CSS custom property

If you control your own admin customization, avoid repeating the chosen width throughout the stylesheet.

For example:

:root {
    --my-admin-menu-width: 220px;
}

@media screen and (min-width: 961px) {

    #adminmenuback,
    #adminmenuwrap,
    #adminmenu {
        width: var(
            --my-admin-menu-width
        );
    }

    #wpcontent,
    #wpfooter {
        margin-left: var(
            --my-admin-menu-width
        );
    }

}

This creates one source of truth:

--my-admin-menu-width

instead of scattering:

220px

through many selectors.

Use calc() for components that depend on remaining width

If you have your own fixed administration component, you can derive its dimensions from the same variable.

For example:

.my-admin-panel {
    inset-inline-start:
        var(--my-admin-menu-width);

    width:
        calc(
            100vw -
            var(--my-admin-menu-width)
        );
}

Using one width definition reduces the risk that:

sidebar = 220px

content = 210px

plugin header = 240px

quietly becomes three different interpretations of the same layout.

Prefer logical CSS properties when possible

WordPress supports languages that use right-to-left layouts.

Hardcoding:

margin-left
left

assumes the sidebar always originates from the physical left side.

For your own plugin interfaces, CSS logical properties can make direction-aware layouts easier to maintain.

Examples include:

margin-inline-start
padding-inline-start
inset-inline-start

MDN’s CSS Logical Properties documentation explains how these properties adapt to writing direction.

You should still test against WordPress Core’s existing physical-property CSS because Core itself may use conventional left/right rules in specific administration styles.

How to load the customization correctly

Do not edit:

wp-admin/css/common.css

directly.

A WordPress update would replace the modification.

Instead, load your own administration stylesheet through:

admin_enqueue_scripts

The official admin_enqueue_scripts documentation identifies it as the appropriate hook for enqueuing styles and scripts inside wp-admin.

A simple plugin implementation could use:

function myplugin_admin_menu_width() {

    wp_enqueue_style(
        'myplugin-admin-menu',
        plugins_url(
            'admin-menu.css',
            __FILE__
        ),
        array(),
        '1.0.0'
    );
}

add_action(
    'admin_enqueue_scripts',
    'myplugin_admin_menu_width'
);

You can also add inline CSS to an enqueued stylesheet

If the width comes from a saved setting rather than a static file, WordPress provides:

wp_add_inline_style()

The official wp_add_inline_style() documentation explains how additional CSS can be attached to a stylesheet that is already enqueued.

For example:

function myplugin_admin_menu_width() {

    wp_enqueue_style(
        'myplugin-admin',
        plugins_url(
            'admin.css',
            __FILE__
        ),
        array(),
        '1.0.0'
    );

    $width = 220;

    $css = sprintf(
        '@media screen and (min-width: 961px) {
            #adminmenuback,
            #adminmenuwrap,
            #adminmenu {
                width: %1$dpx;
            }

            #wpcontent,
            #wpfooter {
                margin-left: %1$dpx;
            }
        }',
        $width
    );

    wp_add_inline_style(
        'myplugin-admin',
        $css
    );
}

add_action(
    'admin_enqueue_scripts',
    'myplugin_admin_menu_width'
);

Validate configurable width values

If administrators can enter a custom value, do not insert arbitrary unsanitized text into CSS.

For a simple pixel setting, normalize it to an integer:

$width = absint(
    get_option(
        'my_admin_menu_width',
        200
    )
);

You can also enforce reasonable limits:

$width = max(
    160,
    min(
        320,
        $width
    )
);

This prevents a typo such as:

2200px

from turning wp-admin into an exercise in horizontal archaeology.

Do not forget responsive behavior

The previous guide in this cluster covers this in detail, but it matters enough to repeat the practical rule:

Above 960px
→ custom expanded width may apply

960px and below
→ let WordPress use its folded behavior

782px and below
→ let WordPress use its mobile administration behavior

Read WordPress Admin Menu Responsive Breakpoints, Explained for the complete explanation.

Why 961px is a sensible minimum for a custom desktop width

The official WordPress Gutenberg breakpoint source defines:

$break-large: 960px;

with the explicit comment:

admin sidebar auto folds

Applying a wider sidebar below that point works against the reason Core folds it in the first place.

If WordPress determines that 160px is already too expensive at that viewport width, forcing a 240px permanent sidebar is unlikely to improve the work area.

The 782px state is even more important

At and below:

782px

WordPress enters a more mobile-oriented administration mode.

The navigation interaction, Toolbar dimensions and available work area all change.

Do not force the desktop sidebar width into that layout.

How wide should the admin menu actually be?

There is no universal ideal width.

A practical range for many installations might be somewhere around:

180px
200px
220px
240px

but the correct value should be based on the actual interface.

Look at:

• the longest top-level label;
• the longest submenu label;
• the active language;
• plugin notification counters;
• available monitor width;
• the amount of horizontal space required by content screens.

Widen only enough to solve the problem

If the longest label fits comfortably at:

190px

there is little reason to use:

300px

just because the monitor is wide enough.

Every extra pixel reserved for navigation reduces the horizontal space available to:

• list tables;
• editors;
• settings forms;
• plugin dashboards;
• WooCommerce screens;
• analytics interfaces.

Do not solve font-size problems only with width

If the menu text is too small, widening the menu is not the same as improving typography.

Likewise, if menu items are difficult to tap, width is not a replacement for appropriate vertical padding.

These are separate variables:

Width
→ horizontal room

Font size
→ text legibility

Padding
→ target size and density

A coherent administration design considers all three rather than compensating for one exclusively through another.

Custom Menu Width in TheOneWP

TheOneWP Custom Menu Width provides a dedicated control for changing the WordPress administration sidebar width without manually maintaining the entire CSS implementation.

The verified module supports width values using:

• pixels;
• em;
• rem;
• percentages.

The configured width is scoped to:

min-width: 961px

so the normal WordPress folded and mobile states remain active below the desktop breakpoint.

It changes more than #adminmenu

The module applies the width consistently to the sidebar structure and repositions the main administration content.

That addresses the fundamental relationship:

new sidebar width
=
new content offset

rather than changing only the visible menu element.

It also handles common third-party width assumptions

The more unusual problem occurs when another plugin contains something equivalent to:

left: 160px;

The verified Custom Menu Width implementation includes a companion script that detects fixed or absolute elements aligned to WordPress’s normal 160px sidebar boundary and can reposition matching elements to the configured width.

This is useful for panels that are created dynamically after page load.

The module uses a:

MutationObserver

to detect later DOM changes.

MDN documents MutationObserver as the browser API for observing changes to the DOM tree.

Automatic compensation is still a heuristic

No generic system can guarantee compatibility with every administration plugin.

A third-party panel might use:

159px
calc(160px + 12px)
transform
CSS Grid
JavaScript positioning

or another completely different layout technique.

Always test important administration extensions after changing the menu width.

Compatibility problems to look for

After widening the sidebar, open the administration screens used most often and look specifically for horizontal alignment problems.

Fixed plugin headers

A plugin may create:

position: fixed;
left: 160px;
right: 0;

Its header will overlap the widened navigation until the left offset is updated.

Bottom developer panels

Debugging and development tools can create fixed panels spanning the bottom of wp-admin.

If they start at the old sidebar boundary, part of the panel can disappear beneath the menu.

Full-height plugin applications

Some administration tools build almost complete application shells inside wp-admin.

These may independently calculate:

• left offset;
• width;
• viewport height;
• Toolbar offset.

They deserve explicit testing.

Sticky notices and action bars

A custom action bar using:

position: sticky

may behave correctly because it participates in the existing content flow.

A fixed action bar with a manual left coordinate is more likely to require adjustment.

Z-index problems

Changing widths can expose stacking problems that were previously hidden.

Check whether:

• the sidebar background remains behind menu items;
• plugin panels render above or below the intended layers;
• submenus remain clickable;
• fixed overlays do not cover navigation.

Widening the menu versus keeping it expanded

These are two separate customizations.

A wider menu answers:

How wide should the expanded sidebar be?

Keeping the menu expanded answers:

When should WordPress be allowed to collapse it?

You can have:

220px expanded menu
↓
normal auto-fold at 960px

which is usually a sensible combination.

Or you could attempt:

220px menu
↓
force expanded at 850px

which leaves considerably less room for the main interface and needs much more testing.

For that separate decision, see How to Keep the WordPress Admin Menu Expanded.

Testing a wider WordPress admin menu

Do not test only the Dashboard at full-screen desktop width.

A proper test should cover the interface states and screens most likely to expose width assumptions.

Test breakpoint boundaries

Check at least:

1440px
1200px
1080px
1000px
961px
960px
900px
783px
782px
768px
480px
390px

Pay particular attention to:

961px → 960px

because the custom width should stop controlling the expanded layout as Core enters the auto-fold range.

Test manual collapse on desktop

At a wide viewport, manually use:

Collapse menu

and verify that the compact menu still uses the intended Core behavior rather than retaining the custom expanded width.

Test long labels

Use the actual longest labels available on the installation.

Check:

• normal items;
• active items;
• hover states;
• submenus;
• notification badges;
• translated strings.

Test common administration screens

At minimum, inspect:

• Dashboard;
• Posts;
• Pages;
• Media;
• Users;
• Settings;
• WooCommerce if installed;
• major plugin administration applications;
• the Block Editor;
• custom post type screens.

Test fixed and dynamically inserted panels

Open tools that add interfaces after the initial page render.

A menu-width customization that looks correct immediately after loading can still fail when a JavaScript-created panel appears later.

Test browser zoom

Test practical zoom levels such as:

125%
150%
200%

because zoom reduces the effective CSS viewport and may trigger WordPress’s responsive states earlier than expected.

The WCAG guidance on Reflow provides useful context for interfaces that need to remain usable at reduced effective widths.

Common mistakes when widening wp-admin

• Changing only #adminmenu.
• Forgetting #adminmenuwrap.
• Forgetting #adminmenuback.
• Leaving #wpcontent at the original 160px offset.
• Leaving #wpfooter at the original offset.
• Applying the custom width below WordPress’s 960px auto-fold breakpoint.
• Breaking the 36px folded menu.
• Forcing a desktop sidebar width into the mobile admin layout.
• Editing WordPress Core CSS files directly.
• Using excessive !important declarations without understanding Core state classes.
• Ignoring third-party panels positioned at 160px.
• Assuming every plugin uses normal document flow.
• Testing only the Dashboard.
• Ignoring RTL interfaces.
• Ignoring browser zoom.
• Using an extremely wide menu when reorganizing navigation would solve the underlying problem better.

A practical implementation checklist

• Measure the longest administration menu labels.
• Choose the smallest width that solves the readability problem.
• Apply the custom width only to the expanded desktop state.
• Resize #adminmenu, #adminmenuwrap and #adminmenuback together.
• Move #wpcontent and #wpfooter by the same amount.
• Preserve the folded menu state.
• Preserve WordPress’s 960px auto-fold behavior.
• Preserve the 782px mobile administration state.
• Load custom CSS through admin_enqueue_scripts.
• Keep configurable width values sanitized and bounded.
• Use one CSS custom property when you control several related components.
• Prefer logical properties for your own direction-aware layouts where practical.
• Search custom plugin code for hardcoded 160px offsets.
• Test third-party fixed panels.
• Test dynamically inserted administration components.
• Test manual menu collapse.
• Test breakpoint boundaries.
• Test browser zoom.
• Test translated labels.
• Reorganize the menu instead if width is not the real problem.

Related guides

• WordPress Admin Menu Responsive Breakpoints, Explained
• Why WordPress Plugins Hardcode 160px into their Panels
• How to Keep the WordPress Admin Menu Expanded
• Reducing WordPress Admin Confusion for Clients
• Standardizing the WordPress Admin for Teams
• Decluttering the WordPress Admin Dashboard

Final recommendation

Widening the WordPress admin menu is straightforward only if you treat the sidebar as part of the complete wp-admin layout rather than as an isolated 160px element.

The basic relationship is:

Sidebar width
↓
menu background
menu wrapper
menu list
content offset
footer offset
third-party fixed elements

All of those pieces need to remain aligned.

For most sites, the safest implementation is to choose a modest desktop width, apply it only above WordPress’s 960px auto-fold breakpoint and leave Core’s compact and mobile administration states unchanged.

Do not edit Core files and do not assume that changing #adminmenu alone is sufficient. Load your customization through the normal administration asset system, test the major WordPress screens and pay special attention to plugins that position fixed elements relative to the traditional 160px sidebar.

If the problem is primarily long labels or translated navigation, TheOneWP Custom Menu Width provides a dedicated width setting, respects WordPress’s responsive breakpoint by applying the custom size only from 961px upward and includes compensation for common third-party panels that remain anchored to the original sidebar boundary.

If the menu is difficult to use because it contains too many entries rather than because the labels are cramped, widening it further is treating the symptom. In that case, restructure the navigation with Admin Menu Organizer instead.

The goal is not to make the WordPress sidebar as wide as possible. It is to give the navigation enough room to remain readable while preserving as much space as possible for the work administrators actually came to wp-admin to perform.