How to Resize the WordPress Admin Menu

Resizing the WordPress admin menu can make the backend easier to read, more comfortable to navigate and better suited to custom dashboards, client websites and heavily customized WordPress installations.

The default WordPress administration menu uses dimensions designed to work reasonably well across a wide range of installations. That makes sense for Core, but it does not mean those dimensions are ideal for every website.

A site with long custom post type names may need a wider menu. A backend designed for touch interaction may need taller menu items. A client dashboard may benefit from larger labels, while a compact internal tool may need slightly tighter spacing.

Resizing the menu therefore involves more than changing one CSS value.

You may need to control:

• the overall sidebar width;
• menu item height and vertical spacing;
• menu label font size;
• icon dimensions and alignment;
• submenu positioning;
• the position of the main admin content;
• the collapsed menu state;
• responsive behavior on smaller screens.

These elements are connected. Increasing the sidebar width without adjusting the content area can create overlap. Increasing the font size without changing line height can make labels cramped. Enlarging menu items without checking responsive behavior can make the mobile administration experience worse rather than better.

This guide explains how the WordPress admin menu is structured, how to resize it safely with CSS, how width and spacing affect the rest of wp-admin, how responsive breakpoints change the menu and how to build a more maintainable resizing strategy.

How the WordPress admin menu is structured

The left administration navigation is generated by WordPress Core and populated with menu entries from Core, themes and plugins.

Plugins can register their own top-level and submenu pages through WordPress APIs. The official admin_menu hook documentation explains the point in the administration lifecycle where menu and submenu entries can be added.

From a styling perspective, several elements are especially important:

• #adminmenuback provides the menu background area;
• #adminmenuwrap wraps the navigation;
• #adminmenu contains the actual menu list;
• #wpcontent contains the main administration content;
• #wpfooter contains the admin footer;
• .wp-menu-image contains menu icons;
• .wp-menu-name contains menu labels;
• .wp-submenu contains submenu items.

The important point is that the menu does not exist independently from the rest of the administration layout.

If you change:

#adminmenuwrap {
    width: 220px;
}

but leave the rest of the administration layout expecting the original width, the main content does not automatically understand your new design.

A proper resize therefore treats the sidebar and the content offset as one system.

If your objective is specifically to increase horizontal room for long labels, see How to Widen the WordPress Admin Menu. This guide takes the broader approach and covers width, height, typography and spacing together.

Loading custom admin CSS correctly

Before changing dimensions, the CSS needs to be loaded in the correct WordPress context.

Frontend styles should normally be enqueued through wp_enqueue_scripts, but administration styles belong to a different hook.

WordPress provides:

admin_enqueue_scripts

for scripts and styles used in wp-admin.

The official admin_enqueue_scripts documentation explicitly identifies it as the proper hook for administration scripts and styles. It also provides the current admin page hook suffix, allowing assets to be restricted to particular screens when appropriate.

A plugin can load an administration stylesheet like this:

function myplugin_admin_styles() {
    wp_enqueue_style(
        'myplugin-admin',
        plugin_dir_url( __FILE__ ) . 'assets/admin.css',
        array(),
        '1.0.0'
    );
}

add_action(
    'admin_enqueue_scripts',
    'myplugin_admin_styles'
);

Your menu-related CSS can then live in:

assets/admin.css

rather than being printed repeatedly into administration pages.

The official wp_enqueue_style() documentation covers the stylesheet enqueue API itself.

Using the administration enqueue system also keeps backend styles separate from frontend theme CSS. That separation matters because the public theme and wp-admin are different styling environments.

If the wider asset-loading model is unfamiliar, wp_enqueue_scripts Explained covers WordPress handles, dependencies, versions and stylesheet loading in more detail. The hook used for the frontend is different, but the underlying enqueue architecture is closely related.

Changing the width of the WordPress admin menu

Suppose you want to increase the desktop menu width to 220px.

A basic implementation could start with:

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

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

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

The key detail is that both sides of the layout are updated.

The navigation becomes wider, and the main administration content moves accordingly.

Why changing only #adminmenu is not enough

This:

#adminmenu {
    width: 220px;
}

changes only one part of the system.

The background, wrapper and content positioning can still use their original dimensions.

The result may include:

• menu content extending outside its background;
• the main admin area overlapping the navigation;
• submenu positioning problems;
• inconsistent hover backgrounds;
• visual gaps between the menu and content.

This is why menu resizing should be treated as a layout modification rather than a cosmetic change to one element.

For installations where width is the primary problem, How to Widen the WordPress Admin Menu explores that dimension in more detail.

Do not make the sidebar unnecessarily wide

A wider menu can improve readability, but every extra pixel reduces the horizontal space available to administration content.

This matters on screens containing:

• wide list tables;
• WooCommerce order information;
• analytics interfaces;
• custom plugin dashboards;
• settings tables;
• metabox-heavy editing screens.

A 300px sidebar may look impressive on a large monitor while becoming an expensive use of space on a laptop.

Resize the menu according to actual content rather than simply making it larger.

Changing menu item height, padding and spacing

Width is only one form of resizing.

Vertical dimensions can have an equally large effect on how the administration interface feels.

A compact menu fits more entries on screen, while a more spacious menu can improve readability and pointer or touch interaction.

For example:

#adminmenu .wp-menu-name {
    padding-top: 10px;
    padding-bottom: 10px;
}

can create more vertical room around menu labels.

However, the exact WordPress menu structure contains several interacting elements, so increasing only one padding value can create alignment problems between labels, icons and menu rows.

A more deliberate customization might coordinate the clickable menu item and icon:

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

    #adminmenu a.menu-top {
        min-height: 44px;
        display: flex;
        align-items: center;
    }

    #adminmenu .wp-menu-image {
        display: flex;
        align-items: center;
        justify-content: center;
        min-height: 44px;
    }
}

The objective is not merely to create empty space. The icon and label should remain visually centered within the new row height.

If vertical spacing is your main concern, How to Adjust WordPress Admin Menu Spacing covers the spacing problem specifically.

Larger targets can also help interfaces used from tablets and touch devices. Making the WordPress Admin Touch-Friendly explains why target size, spacing and hover-dependent interactions need different consideration when the user is not navigating with a mouse.

Spacing and density should reflect the number of menu items

A WordPress installation with eight top-level menu entries can comfortably use generous vertical spacing.

An installation containing twenty-five entries from plugins, custom post types and internal tools has a different constraint.

Increasing every row to 56px may create excessive scrolling.

Before increasing menu height dramatically, consider whether some entries should be removed, reorganized or restricted.

How to Reorganize the WordPress Admin Menu explains how menu structure itself can be improved, while How to Hide WordPress Admin Menu Items by Role covers reducing unnecessary navigation for particular users.

That is often better than attempting to make an overloaded navigation comfortable through CSS alone.

Resizing menu text and icons

A physically larger menu does not necessarily become more readable if its text remains too small.

For example:

#adminmenu .wp-menu-name {
    font-size: 15px;
    line-height: 1.4;
}

can make labels more prominent without dramatically changing the entire interface.

Relative CSS units can also be useful:

#adminmenu .wp-menu-name {
    font-size: 0.9375rem;
}

The distinction between px, em and rem becomes relevant when deciding whether menu dimensions should remain fixed or scale with typography. See px vs. em vs. rem: CSS Units Explained for the underlying CSS behavior.

Font size and row height should be adjusted together

Consider this customization:

#adminmenu .wp-menu-name {
    font-size: 18px;
}

If the surrounding row dimensions remain optimized for smaller text, labels may look crowded even though they are technically larger.

A better approach is to evaluate:

• font size;
• line height;
• horizontal padding;
• vertical padding;
• icon alignment;
• available width.

as a group.

This broader readability problem is covered in Making the WordPress Admin More Readable.

If you want to change the typeface rather than only its size, see How to Change the WordPress Admin Font.

Be careful when resizing Dashicons

Many WordPress administration menu entries use Dashicons.

The official WordPress Dashicons resource documents the icon set available to developers.

Icons and text need to remain visually balanced.

If labels become much larger while icons retain their original visual scale, the navigation can look inconsistent. But aggressively overriding icon dimensions can also interfere with alignment expected by Core or plugins.

Make small changes and test menu items using both Core and plugin-provided icons.

Submenus must be tested when the menu size changes

Top-level menu entries are only part of the navigation.

Many entries contain submenus:

• Posts;
• Media;
• Pages;
• Appearance;
• Plugins;
• Users;
• Tools;
• Settings;
• custom plugin menus.

A width customization therefore needs to account for .wp-submenu behavior.

If the sidebar becomes significantly wider but fly-out submenu positioning still assumes Core’s normal geometry, submenu panels can appear detached or overlap unexpected areas.

Likewise, increasing submenu font size can make long labels wrap.

A basic typography adjustment might be:

#adminmenu .wp-submenu a {
    font-size: 14px;
    line-height: 1.4;
}

but you should test:

• the currently active submenu;
• hovered submenus;
• collapsed navigation;
• long translated labels;
• plugin-created menu items;
• keyboard navigation.

Do not solve wrapping by blindly preventing it

A rule such as:

#adminmenu .wp-submenu a {
    white-space: nowrap;
}

may prevent wrapping, but it can simply move the problem elsewhere by creating an excessively wide submenu.

If labels routinely do not fit, reconsider the menu width, typography and naming together.

Menu organization is particularly important on client installations where dozens of technical plugin entries provide little value to the person actually managing content. Reducing WordPress Admin Confusion for Clients discusses that broader simplification strategy.

The collapsed admin menu is a separate layout state

WordPress allows desktop users to collapse the administration menu.

When collapsed, the interface is no longer simply a narrower version of your expanded sidebar.

Labels disappear from the primary navigation and icons become the main visual controls.

That means a rule intended for the expanded state can produce unwanted results when the folded state is active.

For example, a broad rule such as:

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

can fight against WordPress’s collapsed layout if it is applied regardless of body state.

When building a custom width, scope desktop-expanded rules appropriately rather than assuming the menu always has one geometry.

For installations where the menu should remain expanded rather than preserving both states, see How to Keep the WordPress Admin Menu Expanded.

Test manual and automatic collapsing separately

There are two related but different scenarios:

• the user manually collapses the desktop navigation;
• WordPress changes the menu layout because the available viewport becomes smaller.

A customization that works in the first scenario is not automatically safe in the second.

This distinction is important enough that WordPress Admin Menu Responsive Breakpoints, Explained covers the responsive behavior separately.

Responsive behavior is the most important part to preserve

Hard-coding a custom desktop menu width without respecting WordPress’s responsive behavior is one of the easiest ways to break wp-admin.

A desktop rule such as:

#wpcontent {
    margin-left: 220px;
}

must not continue forcing the same offset when WordPress switches to its smaller-screen navigation model.

This is why desktop-specific customizations should usually be protected by an appropriate media query.

For example:

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

    body:not(.folded) #adminmenuback,
    body:not(.folded) #adminmenuwrap,
    body:not(.folded) #adminmenu {
        width: 220px;
    }

    body:not(.folded) #wpcontent,
    body:not(.folded) #wpfooter {
        margin-left: 220px;
    }
}

The exact breakpoint and selectors used by a customization should be tested against the WordPress version and administration behavior you support rather than copied permanently from an old snippet.

WordPress Core itself contains responsive administration CSS, and Core can change implementation details over time.

For that reason, WordPress Admin Menu Responsive Breakpoints, Explained should be considered companion reading when building a custom admin layout.

Do not shrink the mobile menu simply because the desktop menu is compact

Desktop and touch interfaces have different requirements.

A compact 34px-high navigation row may feel efficient with a mouse. On a touchscreen, the same density can make selecting adjacent items unnecessarily difficult.

Responsive customization should therefore be intentional rather than proportional.

You may choose:

• compact spacing on large desktop screens;
• moderate spacing on laptops;
• larger interaction targets on touch-oriented layouts.

Making the WordPress Admin Touch-Friendly explores these interaction differences in greater depth.

A maintainable WordPress admin menu resize

A good implementation should separate the different responsibilities rather than hiding dozens of unrelated overrides inside one large selector.

For example:

:root {
    --custom-admin-menu-width: 220px;
    --custom-admin-menu-font-size: 15px;
    --custom-admin-menu-row-height: 44px;
}

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

    body:not(.folded) #adminmenuback,
    body:not(.folded) #adminmenuwrap,
    body:not(.folded) #adminmenu {
        width: var(--custom-admin-menu-width);
    }

    body:not(.folded) #wpcontent,
    body:not(.folded) #wpfooter {
        margin-left: var(--custom-admin-menu-width);
    }
}

#adminmenu a.menu-top {
    min-height: var(--custom-admin-menu-row-height);
}

#adminmenu .wp-menu-name {
    font-size: var(--custom-admin-menu-font-size);
    line-height: 1.4;
}

#adminmenu .wp-menu-image {
    min-height: var(--custom-admin-menu-row-height);
    display: flex;
    align-items: center;
    justify-content: center;
}

CSS custom properties make the relationship between values easier to see and maintain.

Instead of hunting through the stylesheet for every occurrence of 220px, the width has one conceptual source.

Separate width, typography and spacing controls

A maintainable customization should let you change:

• menu width;
• menu font size;
• menu row height or padding;

independently.

This matters because they solve different problems.

A menu may need to be wider without needing larger text. Another installation may have enough horizontal space but need more readable labels. A touch-oriented dashboard may need larger rows while keeping the existing width.

TheOneWP provides separate controls for these concerns through Custom Menu Width, Custom Menu Item Padding and Custom Admin Menu Font Size, allowing menu dimensions to be adjusted without maintaining custom CSS for each property.

If the problem is not size but the structure and order of menu entries, Admin Menu Organizer addresses that separate part of the administration experience.

Do not edit WordPress Core CSS files

Never make this customization by editing stylesheets directly inside wp-admin.

Core files belong to WordPress itself and can be replaced during updates.

Custom administration styling should live in a plugin, site-specific plugin or another controlled customization layer and should be loaded using the appropriate administration hooks.

This keeps the modification separate from WordPress Core and makes it easier to test when WordPress changes its administration interface.

Testing a resized WordPress admin menu

A menu that looks correct on the Dashboard is not necessarily finished.

The WordPress administration area contains many different screen types, and plugins can add their own layouts.

After resizing the menu, test at least:

• Dashboard;
• Posts and Pages list tables;
• the post editor;
• Media Library;
• Comments;
• Appearance screens;
• Plugins;
• Users;
• Tools;
• Settings;
• custom post type screens;
• WooCommerce screens if installed;
• plugin settings pages;
• expanded navigation;
• collapsed navigation;
• submenu hover states;
• keyboard navigation;
• desktop, laptop, tablet and mobile widths.

Test long and translated menu labels

English labels are not representative of every WordPress installation.

A menu width that comfortably fits an English label may not fit its equivalent in another language.

Test:

• long plugin names;
• custom post type labels;
• translated Core labels;
• submenu labels;
• notification counters.

Do not optimize the entire sidebar around the shortest possible content.

Test list tables after changing the sidebar width

A wider sidebar leaves less room for the main content area.

That can expose problems on Posts, Pages, Users, Comments and other administration list tables.

If you are heavily customizing those screens too, WordPress Admin List Tables, Explained provides useful background on how those interfaces are structured.

For custom data columns specifically, see How to Customize WordPress Admin List Columns. Wider menus and additional table columns both consume horizontal space, so the two customizations should be tested together.

Test the backend as the actual user role

Administrators often see many more navigation items than editors, authors or custom roles.

A menu designed while logged in as an administrator may therefore behave very differently for another user.

If different teams need intentionally different administration environments, Standardizing the WordPress Admin for Teams covers the broader problem of creating consistent backend workflows.

Common WordPress admin menu resizing mistakes

Changing only the menu width

If the sidebar changes but #wpcontent does not, the layout can overlap.

Treat the sidebar and main content offset as connected dimensions.

Applying desktop dimensions to mobile

A fixed desktop margin or sidebar width can break WordPress’s responsive administration layout.

Scope desktop customizations carefully and test every responsive state.

Making text larger without increasing available space

Larger labels can wrap, collide with icons or make the menu look more crowded.

Typography, width and row spacing need to be evaluated together.

Making every menu item excessively tall

Larger targets can improve interaction, but excessive vertical spacing creates unnecessary scrolling on installations with many entries.

Remove or reorganize unnecessary items before compensating for menu clutter with size alone.

Ignoring the folded state

The collapsed navigation has different geometry from the normal expanded sidebar.

Global width overrides can accidentally destroy that behavior.

Using !important everywhere

Administration CSS can involve specificity conflicts, but filling the stylesheet with !important declarations makes future maintenance more difficult.

Use appropriately scoped selectors first and reserve !important for cases where the cascade genuinely requires it.

Editing Core files

Changes inside WordPress Core are fragile and can disappear after updates.

Keep custom backend styling outside Core.

Resizing when the real problem is menu clutter

If the menu contains too many irrelevant entries, making it wider or taller treats the symptom rather than the cause.

Use How to Reorganize the WordPress Admin Menu and How to Hide WordPress Admin Menu Items by Role to simplify the navigation itself.

Related guides

• How to Widen the WordPress Admin Menu
• How to Adjust WordPress Admin Menu Spacing
• WordPress Admin Menu Responsive Breakpoints, Explained
• Making the WordPress Admin Touch-Friendly
• Making the WordPress Admin More Readable
• How to Reorganize the WordPress Admin Menu

Final thoughts

Resizing the WordPress admin menu is not simply a matter of changing width.

The sidebar is part of a larger administration layout, so width, content offsets, menu item height, typography, icons, submenus, collapsed states and responsive behavior all need to remain coordinated.

If the objective is more horizontal room, increase the sidebar width and update the corresponding desktop content offset. If readability is the problem, consider font size and line height. If the interface feels cramped, adjust menu item spacing. If touch interaction is difficult, increase usable target sizes without blindly carrying desktop assumptions onto smaller screens.

Most importantly, keep these concerns separate.

A useful admin customization system should allow you to control:

• width for available horizontal space;
• font size for readability;
• padding or row height for density and interaction;
• menu organization for information architecture;
• responsive behavior for smaller screens.

That approach is easier to maintain than one large collection of CSS overrides attempting to redesign every menu state simultaneously.

For manual implementations, load administration styles through WordPress’s admin_enqueue_scripts system, keep the customization outside Core and test both expanded and collapsed states across multiple screen sizes.

For a settings-based approach, TheOneWP separates these responsibilities through Custom Menu Width, Custom Menu Item Padding, Custom Admin Menu Font Size and Admin Menu Organizer.

The result should not simply be a bigger WordPress menu. It should be an administration navigation that uses its available space more effectively and remains readable, responsive and predictable for the people who actually use it.