Why WordPress Plugins Hardcode 160px into their Panels

If you inspect the CSS of enough WordPress plugins, sooner or later you will find rules containing a strangely familiar number:

160px

You might see it in:

margin-left: 160px;
left: 160px;
width: calc(100% - 160px);
padding-left: 160px;

At first this can look like an arbitrary design choice made independently by several plugin developers.

It is not.

The number comes directly from the traditional WordPress administration layout.

In the current WordPress Core administration CSS, the expanded left administration menu is still defined with:

width: 160px;

and the main administration content compensates for that menu using:

margin-left: 160px;

That historical layout assumption has influenced WordPress plugins for years. Developers building full-page interfaces, custom panels, fixed headers, sidebars and overlays often copied the same number into their own CSS so their interface lined up with Core.

The problem appears when that assumption stops being true.

The administration menu can:

• collapse;
• auto-collapse at responsive breakpoints;
• behave differently on mobile;
• be modified by plugins;
• be widened by custom administration interfaces;
• be affected by RTL layouts;
• change in future WordPress versions.

A plugin that assumes:

WordPress admin sidebar = always 160px

can therefore create:

• empty gaps;
• overlapping panels;
• misaligned fixed headers;
• broken responsive layouts;
• content hidden beneath the menu;
• horizontal scrolling;
• interfaces that fail when the menu width is customized.

This guide explains why WordPress uses 160px, why plugins copy that value, when hardcoding it is technically understandable, why it becomes fragile and how WordPress admin interfaces can be built more reliably.

Where does the WordPress 160px value come from?

The answer is visible directly in WordPress Core.

The current WordPress admin menu stylesheet defines:

#adminmenuback,
#adminmenuwrap,
#adminmenu,
#adminmenu .wp-submenu {
    width: 160px;
}

The submenu positioning also uses the same dimension:

#adminmenu .wp-submenu {
    left: 160px;
}

So in the traditional expanded administration layout:

admin menu width
=
160px

The content area also knows about the 160px menu

The current WordPress administration common stylesheet includes:

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

This produces the basic desktop layout:

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

The content does not normally sit underneath the menu because WordPress reserves the corresponding horizontal space.

This is not a recent convention

The 160px relationship has existed in WordPress administration CSS for many years.

Historical WordPress Core changes show the layout using:

#wpcontent,
#footer {
    margin-left: 160px;
}

as far back as the older administration architecture.

The WordPress Core Trac history for the admin layout shows the 160px content offset being introduced into that generation of the wp-admin CSS.

This long history explains why plugin developers started treating the number almost like an unofficial constant.

Why plugins started copying 160px

Imagine a plugin wants a custom fixed panel inside wp-admin.

The developer sees:

WordPress menu:
160px wide

so the plugin adds:

.my-plugin-panel {
    position: fixed;
    left: 160px;
    right: 0;
}

On the default desktop administration layout, that works.

The result lines up perfectly beside the WordPress menu.

Or a plugin may calculate its available width

.my-plugin-app {
    width: calc(100vw - 160px);
}

Again, with the standard expanded menu:

viewport
-
160px admin menu
=
remaining content width

It is easy to see why developers do it.

The problem is not that 160px is incorrect

For the normal expanded Core admin menu, 160px is currently correct.

The problem is assuming:

160px is universally true
for every wp-admin state.

It is not.

The WordPress admin menu has multiple width states

The administration menu does not remain expanded at 160px under every condition.

Core currently has a folded state using:

36px

The current WordPress admin menu CSS includes:

.folded #adminmenuback,
.folded #adminmenuwrap,
.folded #adminmenu,
.folded #adminmenu li.menu-top {
    width: 36px;
}

The main content responds to the folded state

Core also adjusts:

.folded #wpcontent,
.folded #wpfooter {
    margin-left: 36px;
}

So WordPress itself understands:

expanded
→ 160px

folded
→ 36px

A plugin that independently hardcodes:

left: 160px;

does not automatically follow that state.

This creates the classic empty-gap bug

Suppose the WordPress menu collapses to:

36px

but a plugin panel still begins at:

160px

The result is:

36px menu
+
124px empty gap
+
plugin interface

Visually:

┌───┬──────────────┬──────────────────────┐
│   │              │                      │
│36 │ empty space  │ Plugin panel         │
│px │   124px      │                      │
│   │              │                      │
└───┴──────────────┴──────────────────────┘

The reverse problem can also happen

If another system widens the administration menu to:

220px

but the plugin still assumes:

160px

then approximately:

60px

of the plugin interface can sit underneath the navigation.

This is why admin menu customization exposes badly designed plugin layouts

You may widen the WordPress menu correctly and find that:

• WordPress Core screens adapt;
• some plugins adapt;
• other plugins remain stuck at the old position.

That usually means the plugin has created its own independent layout assumption.

See How to Widen the WordPress Admin Menu for the broader menu-width problem.

WordPress itself is coupled to 160px too

It is important not to pretend this is only a plugin-development problem.

Core currently contains the explicit value in several places.

For example:

admin menu width:
160px

submenu offset:
160px

content margin:
160px

The difference is that WordPress also defines the corresponding alternate states.

Core knows when:

160px
→ 36px

and applies coordinated rules across the administration shell.

A plugin often copies only one piece of that system

That is where fragility appears.

For example:

.plugin-header {
    left: 160px;
}

without also implementing:

.folded .plugin-header {
    left: 36px;
}

or the corresponding responsive behavior.

The auto-fold breakpoint matters too

WordPress can automatically collapse the administration menu based on available viewport width.

The current Core stylesheet contains:

@media only screen and (max-width: 960px)

for the administration menu’s auto-fold behavior.

Within that state, WordPress adjusts the content offset and navigation width to:

36px

rather than 160px.

For the complete responsive behavior, see WordPress Admin Menu Responsive Breakpoints, Explained.

The mobile admin introduces another layout mode

At smaller viewport sizes, the wp-admin navigation no longer behaves like a conventional permanently visible desktop sidebar.

WordPress changes the navigation interaction and administration layout to accommodate narrow screens.

A plugin using:

width: calc(100vw - 160px);

without media-query handling may therefore create a panel narrower than the actual mobile viewport.

Example of fragile plugin CSS

.plugin-app {
    position: fixed;
    top: 32px;
    left: 160px;
    width: calc(100% - 160px);
    height: calc(100vh - 32px);
}

This contains several assumptions:

Admin menu always 160px
Admin bar always 32px
Desktop layout always active
Menu always expanded

None of those assumptions is universally reliable.

The Admin Bar has exactly the same class of problem

The WordPress Toolbar normally has one desktop height and another mobile height.

So hardcoding:

top: 32px;

can create the same type of responsive failure as hardcoding:

left: 160px;

Administrative interfaces often break because developers model wp-admin as a fixed rectangle instead of a responsive application shell.

Why do plugin developers hardcode these values anyway?

There are several practical reasons.

It is simple

This:

left: 160px;

requires almost no architecture.

It matches Core immediately

If development and testing happen with:

desktop browser
expanded menu
default WordPress admin

the result looks correct.

Plugin developers may test only the default state

A developer may never test:

• collapsed menu;
• custom menu widths;
• RTL;
• tablet;
• mobile;
• other administration customizations.

The WordPress admin does not expose a universal public CSS variable for menu width

Plugin developers cannot simply rely on something like:

var(--wp-admin-menu-width)

as a universally documented Core contract.

That makes integrations more awkward than they would be if the administration shell exposed explicit layout variables.

The 160px value is therefore understandable but brittle

There is an important distinction between:

using a Core dimension
because Core currently uses it

and:

assuming that dimension
can never change

A plugin page inside #wpcontent often does not need the 160px value at all

This is the most important architectural point.

WordPress already creates the administration shell:

#wpwrap
├── admin menu
└── #wpcontent
    └── plugin page

And WordPress already gives:

#wpcontent {
    margin-left: 160px;
}

in the expanded desktop state.

A normal plugin page should generally flow inside WordPress’s content area

For example:

<div class="wrap">
    <h1>My Plugin</h1>

    <div class="my-plugin-app">
        ...
    </div>
</div>

The plugin can then use:

.my-plugin-app {
    width: 100%;
}

rather than:

.my-plugin-app {
    width: calc(100vw - 160px);
    margin-left: 160px;
}

WordPress should own the outer administration geometry

A robust division of responsibility is:

WordPress Core
→ menu width
→ admin content offset
→ responsive shell

Plugin
→ layout inside its own content area

This avoids duplicating Core’s geometry.

Problems usually begin when plugins escape the normal content flow

Developers often use:

position: fixed;

because they want:

• full-screen plugin applications;
• fixed navigation;
• sticky toolbars;
• application-style dashboards;
• custom side panels.

Once an element is fixed relative to the viewport, it no longer naturally follows #wpcontent.

Then the developer has to account for WordPress’s chrome manually.

This is where 160px gets copied into plugin CSS

For example:

.my-plugin-fixed-header {
    position: fixed;
    top: 32px;
    left: 160px;
    right: 0;
}

The plugin is effectively rebuilding part of the WordPress shell.

A safer option is often positioning relative to the plugin container

Instead of:

position: fixed;

consider whether:

position: sticky;

can solve the requirement.

For example:

.my-plugin-toolbar {
    position: sticky;
    top: 32px;
    z-index: 10;
}

Because the element remains inside the normal administration content flow, its horizontal position can follow #wpcontent naturally.

Sticky positioning is not automatically the answer

It depends on:

• ancestor overflow;
• scroll container;
• Toolbar behavior;
• the plugin layout;
• responsive requirements.

But it can reduce the amount of WordPress shell geometry the plugin needs to reproduce.

If fixed positioning is unavoidable, support the folded state

A minimum implementation might account for:

expanded:
160px

folded:
36px

For example:

.my-plugin-shell {
    left: 160px;
}

.folded .my-plugin-shell {
    left: 36px;
}

But even this is still tied to Core implementation details.

Auto-fold must also be considered

At narrower desktop widths, WordPress can add behavior associated with:

auto-fold

So a plugin might need equivalent responsive handling.

Hardcoded geometry begins multiplying quickly:

expanded
folded
auto-fold
mobile
RTL
custom width

This is precisely why depending on the normal WordPress content flow is preferable when possible.

Do not assume the folded state is always user-controlled

The WordPress administration header assigns classes associated with menu state.

The current WordPress admin header source handles administration body classes including:

folded
auto-fold

The layout can therefore change because of both user preference and viewport behavior.

Plugins should understand the body classes before inventing their own state detection

Useful Core state already exists in the document.

Inspect:

<body class="wp-admin ... folded ...">

or:

<body class="wp-admin ... auto-fold ...">

rather than independently guessing the state solely from viewport width.

Why custom admin menu widths expose plugin bugs

Suppose you intentionally widen the menu from:

160px

to:

240px

because your administration menu contains longer labels.

Core-related CSS can be adjusted coherently:

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

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

But a plugin may still contain:

.plugin-panel {
    left: 160px;
}

The plugin therefore starts:

80px

too far left.

The plugin is not responding to the actual administration layout

It is responding to:

the administration layout
the plugin developer expected

Those are not the same thing.

This is why widening the menu can appear to “break plugins”

The menu modification often exposes a dependency that was already present.

The plugin effectively says:

I expect the WordPress menu
to remain exactly 160px forever.

Changing the menu simply reveals that assumption.

See the menu-width guide before changing Core dimensions

How to Resize the WordPress Admin Menu explains the broader relationship between the navigation width and administration content positioning.

How to Widen the WordPress Admin Menu covers the specific case where more horizontal space is needed for navigation labels.

Long plugin menu labels are one reason 160px can feel restrictive

The WordPress menu was not designed around every possible modern plugin label.

Third-party items may have names such as:

Advanced Marketing Automation

Product Feed Management

Security & Compliance Dashboard

inside a:

160px

sidebar.

The text may:

• wrap;
• increase item height;
• create visual density;
• become difficult to scan.

Menu width and menu spacing are different problems

Increasing:

width

changes horizontal room.

Changing:

padding
line-height
item spacing

changes vertical rhythm.

See How to Adjust WordPress Admin Menu Spacing for that separate problem.

Do not solve a 160px integration problem with enormous z-index values

If a panel is underneath the administration menu because its horizontal position is wrong, adding:

z-index: 999999999;

does not fix the layout.

It merely makes the incorrectly positioned element overlap something else more aggressively.

Position and stacking are different systems

left / right / width
→ geometry

z-index
→ stacking order

Fix the geometry first.

Do not use JavaScript for a problem CSS already expresses

You sometimes see plugin code like:

const menu = document.querySelector('#adminmenuwrap');

const width = menu.offsetWidth;

document.querySelector('.plugin-panel').style.left =
    width + 'px';

This can work, but it introduces:

• initial layout shifts;
• resize handling;
• menu-state synchronization;
• additional JavaScript;
• possible timing problems.

Use JavaScript measurement only when the layout genuinely requires runtime geometry

If the interface can remain inside the normal Core content container, CSS flow is usually simpler and more reliable.

If runtime measurement is necessary, respond to changes

A one-time measurement on:

DOMContentLoaded

may become stale when:

• the menu collapses;
• the viewport changes;
• the admin interface changes dynamically.

A modern implementation might use:

ResizeObserver

when actual element dimensions must be observed.

The MDN ResizeObserver documentation explains how applications can react when an element’s rendered dimensions change.

But runtime measurement should be the exception

Do not replace:

normal document flow

with:

JavaScript continuously measuring WordPress

unless the application really needs it.

CSS custom properties can make custom admin systems more maintainable

If you control the complete administration customization layer, define your own variable rather than repeating:

160px

through dozens of selectors.

For example:

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

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

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

Your own custom panels can then use the same variable:

.custom-admin-panel {
    left: var(--custom-admin-menu-width);
}

This creates one source of truth

Instead of:

menu.css      → 220px
panel.css     → 220px
header.css    → 220px
dashboard.css → 220px

you have:

--custom-admin-menu-width
→ 220px

Remember to define alternate states too

For example:

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

body.folded {
    --custom-admin-menu-width: 36px;
}

Again, this is appropriate when you control the administration customization layer. It is not a new public WordPress Core API.

Plugin authors should scope admin styles carefully

A separate but related problem is plugins loading custom layout CSS throughout all of wp-admin.

WordPress provides:

admin_enqueue_scripts

for loading administration assets.

The official admin_enqueue_scripts documentation explains that the hook provides the current page’s $hook_suffix, allowing plugins to load scripts and styles only where they are needed.

A plugin should avoid globally changing wp-admin unless that is intentional

For example:

function myplugin_admin_assets( $hook_suffix ) {

    if ( 'toplevel_page_myplugin' !== $hook_suffix ) {
        return;
    }

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

add_action(
    'admin_enqueue_scripts',
    'myplugin_admin_assets'
);

This limits the plugin’s custom layout rules to its own administration screen.

Global selectors make 160px problems worse

A plugin should be especially cautious with rules such as:

#wpcontent {
    margin-left: 160px !important;
}

or:

#adminmenu {
    width: 160px !important;
}

These override Core layout behavior instead of simply styling the plugin page.

The !important flag does not make an assumption more correct

It simply makes competing styles harder to fix.

RTL layouts need separate consideration

WordPress supports right-to-left administration interfaces.

A plugin that assumes:

left sidebar
→ always left: 160px

may fail when the administration direction changes.

Logical CSS properties can sometimes reduce this dependence.

Prefer logical properties where they fit the layout

Instead of thinking only in:

margin-left
padding-left
left

modern CSS provides:

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

The MDN CSS logical properties documentation explains how these properties adapt to writing direction.

That does not remove the width dependency by itself

You can still write a fragile rule such as:

inset-inline-start: 160px;

but at least the directional assumption is no longer hardcoded separately.

How to find whether a plugin hardcodes 160px

Search its CSS and JavaScript files for:

160px
160
calc(100% - 160px)
calc(100vw - 160px)
left:160
margin-left:160

Do not assume every occurrence is related to the admin menu

A plugin can legitimately use:

width: 160px;

for an image, button, card or other unrelated element.

Inspect the selector and context.

Selectors that deserve attention include

.plugin-wrapper
.plugin-app
.plugin-sidebar
.plugin-header
.plugin-content
.plugin-modal
.plugin-fixed-panel

especially when combined with:

position: fixed;
position: absolute;

Inspect the browser’s computed styles

Browser developer tools can answer:

• which rule creates the offset;
• which stylesheet owns it;
• whether the value is 160px;
• whether a media query changes it;
• whether !important is involved.

Test with the WordPress menu collapsed

If the plugin interface remains positioned at 160px while Core moves to 36px, you have identified a fixed-width assumption.

Test around the auto-fold breakpoint

The current Core menu begins auto-fold behavior at:

960px

Test widths around that boundary rather than checking only:

1920px desktop

375px phone

Intermediate widths are often where these layout assumptions become visible.

Test manual menu collapse separately

A manually folded menu and a responsive auto-folded menu can produce similar dimensions but arise from different administration states.

See How to Keep the WordPress Admin Menu Expanded for the broader menu-state behavior.

How should plugin authors build full-page admin applications?

Start by asking whether the application truly needs to escape the standard WordPress content layout.

Normal settings page

Prefer:

WordPress admin shell
↓
#wpcontent
↓
.wrap
↓
plugin interface

Complex application

If the plugin behaves more like:

• a visual builder;
• a reporting platform;
• a workflow application;
• a custom dashboard;

then custom shell behavior may be justified.

Even full-screen applications should model WordPress states explicitly

At minimum, consider:

• expanded admin menu;
• folded admin menu;
• auto-fold state;
• mobile navigation;
• Admin Bar height;
• RTL;
• browser zoom;
• accessibility text scaling.

Do not assume browser zoom preserves your neat pixel arithmetic

Administration users may use:

• browser zoom;
• larger text;
• OS accessibility scaling;
• custom fonts.

A rigid application shell can become much more fragile under those conditions.

Hardcoded pixels are not inherently bad

This distinction matters.

CSS often legitimately uses fixed values.

For example:

border-width: 1px;
icon width: 20px;
focus outline: 2px;

The problem is not:

pixel unit used

The problem is:

external layout dependency
copied as an immutable assumption

160px is an implementation dependency

If your component works only while:

#adminmenu width === 160px

then the component depends on another system’s geometry.

That dependency should either be:

• avoided;
• centralized;
• observed;
• explicitly supported across states.

Why this matters for customized WordPress backends

Agencies increasingly build WordPress admin environments tailored to:

• clients;
• editorial teams;
• ecommerce staff;
• internal applications;
• white-label deployments.

These interfaces may change:

• menu width;
• menu item spacing;
• branding;
• available navigation;
• collapsed-state behavior.

A plugin that assumes the default shell can resist those customizations

This is not necessarily malicious or poorly coded software.

It often reflects the fact that the plugin was designed against the standard wp-admin geometry.

But it does mean deeper administration customization requires compatibility testing.

TheOneWP Admin Menu Organizer

TheOneWP Admin Menu Organizer is designed for restructuring WordPress administration navigation.

When building a customized backend, menu organization and menu geometry should still be treated as separate concerns.

Changing:

which items appear
their order
role visibility

is different from changing:

how wide the administration shell is

Test third-party panels whenever you change admin geometry

If your administration customization changes:

160px
→ 200px
or
160px
→ 240px

test plugin screens individually.

Pay special attention to plugins with:

• fixed headers;
• full-height interfaces;
• React or Vue admin applications;
• custom navigation;
• off-canvas panels;
• full-screen builders.

A practical debugging process

1. Open the affected plugin page.
2. Inspect the misaligned element.
3. Find its computed left, margin-left or width.
4. Identify the stylesheet creating the rule.
5. Search for 160px assumptions.
6. Collapse the WordPress menu.
7. Test around 960px viewport width.
8. Test mobile administration.
9. Test the custom menu width.
10. Check whether the plugin can remain inside #wpcontent instead.

Do not immediately patch the plugin globally

A tempting fix is:

.plugin-panel {
    left: 240px !important;
}

That fixes:

expanded custom desktop state

but may break:

folded menu
auto-fold
mobile

A compatibility override needs state-aware rules

If an override really is necessary, it may need a structure similar to:

.plugin-panel {
    left: 240px;
}

.folded .plugin-panel {
    left: 36px;
}

@media only screen and (max-width: 960px) {
    .auto-fold .plugin-panel {
        left: 36px;
    }
}

and separate mobile handling where required.

That still creates maintenance responsibility

You now depend on:

• the plugin’s selector remaining unchanged;
• WordPress’s classes remaining compatible;
• your custom menu dimensions;
• the plugin’s future releases.

Document the override.

Do not edit the plugin’s distributed CSS directly

Direct edits will normally disappear during the next plugin update.

Prefer a controlled administration stylesheet or compatibility layer loaded after the plugin’s CSS.

Load compatibility CSS only where necessary

The WordPress admin_enqueue_scripts hook can scope that stylesheet to affected administration screens instead of injecting it globally.

WordPress admin layout checklist for plugin developers

• Do not assume the administration menu always remains 160px wide.
• Understand the 36px folded menu state.
• Test WordPress auto-fold behavior.
• Test around the 960px breakpoint.
• Test mobile wp-admin.
• Test RTL administration.
• Prefer normal flow inside #wpcontent.
• Avoid recreating Core content offsets unnecessarily.
• Prefer position: sticky over fixed positioning where appropriate.
• If fixed positioning is required, model Core states explicitly.
• Do not calculate every admin page as 100vw - 160px.
• Do not override #wpcontent globally from a single plugin page.
• Scope administration styles with admin_enqueue_scripts.
• Use the supplied $hook_suffix where appropriate.
• Do not rely on enormous z-index values to fix geometry.
• Use logical CSS properties where direction matters.
• Consider CSS custom properties for administration shells you control.
• Centralize custom menu width values.
• Test menu collapse after custom width changes.
• Test third-party plugin panels after modifying wp-admin geometry.
• Inspect computed styles before writing compatibility overrides.
• Document plugin-specific admin CSS patches.
• Retest compatibility after WordPress updates.
• Retest compatibility after plugin updates.

Related guides

• How to Widen the WordPress Admin Menu
• How to Resize the WordPress Admin Menu
• WordPress Admin Menu Responsive Breakpoints, Explained
• How to Adjust WordPress Admin Menu Spacing
• How to Keep the WordPress Admin Menu Expanded
• How to Reorganize the WordPress Admin Menu

Final recommendation

WordPress plugins hardcode 160px because 160px is not an invented number. It is the current width of the traditional expanded WordPress administration menu and the corresponding offset used by the main wp-admin content area.

The relationship is essentially:

Admin menu:
160px

Main content:
margin-left: 160px

That makes:

left: 160px;

look perfectly reasonable when a plugin builds a custom administration panel.

The mistake is treating that number as a permanent universal property of wp-admin.

WordPress itself already has multiple administration states:

expanded
→ 160px

folded
→ 36px

auto-fold
→ responsive change

mobile
→ different navigation model

Custom administration systems can introduce additional dimensions.

Whenever possible, plugins should therefore allow WordPress to control the outer administration geometry and build their interface inside the existing #wpcontent area.

When a plugin truly needs a fixed or full-screen administration application, menu width must be treated as a variable layout dependency rather than an eternal 160px constant.

That distinction is what separates an interface that merely matches the default WordPress screenshot from one that continues behaving correctly when the administration environment actually changes.