WordPress Screen Options, Explained

WordPress Screen Options are the controls that let individual users customize what they see on many administration screens.

They appear in the Screen Options tab near the top-right area of many wp-admin pages and can control things such as:

• which columns appear in list tables;
• which Dashboard widgets are visible;
• which editing panels are displayed;
• how many items appear per page;
• certain screen-specific layout preferences.

The important detail is that Screen Options are generally about presentation for the current user.

They usually do not:

• remove a feature from WordPress;
• remove a user’s capability;
• disable a plugin;
• change what other users see;
• delete a Dashboard widget permanently;
• prevent direct access to an administration screen.

A useful mental model is:

Screen Options
→ personal administration preferences

Capabilities
→ authorization

Hooks and configuration
→ actual interface structure

Confusing those layers is one of the reasons WordPress administration customizations sometimes behave differently from what site owners expect.

This guide explains how WordPress Screen Options work, what they can control, where their preferences are stored, how they interact with list tables and Dashboard widgets, what developers can add to them and when a permanent administration change is more appropriate.

What are WordPress Screen Options?

The official WordPress Administration Screens documentation describes Screen Options as controls that allow a user to decide which fields or modules are presented in the work area of a particular administration screen.

The exact controls depend on where you are in wp-admin.

That means Screen Options on:

Posts
≠
Users
≠
Dashboard
≠
Pages
≠
Comments

There is no single global Screen Options configuration that applies identically everywhere.

Screen Options are contextual

WordPress builds the Screen Options panel from information associated with the current administration screen.

The Core WP_Screen::show_screen_options() method determines whether the Screen Options tab should be displayed for the current screen.

Core considers information such as:

• registered columns;
• meta boxes;
• per-page settings;
• other screen-specific options.

So a screen with nothing configurable may not show the tab at all.

Screen Options on Posts and Pages

One of the clearest examples is the Posts list screen.

The official Posts screen documentation explains that Screen Options can control which columns are displayed and how many posts appear per page.

A typical Posts table may contain columns such as:

Title
Author
Categories
Tags
Comments
Date

Depending on installed plugins and customizations, additional columns may appear for:

• SEO scores;
• featured images;
• custom metadata;
• languages;
• workflow status;
• plugin-specific information.

A user can often hide columns they do not need.

Hiding a column does not remove the column

Suppose a plugin adds:

SEO Score

to the Posts list.

If a user disables that column through Screen Options, WordPress may stop rendering it for that user.

But the column can still:

• remain registered;
• appear for other users;
• return when the preference is changed;
• remain part of the plugin’s administration integration.

Screen Options therefore provide:

visibility preference

rather than:

feature removal

This distinction is explored further in WordPress Screen Options vs. Custom Columns.

Items per page are also commonly user-specific

On list screens, Screen Options can often control the number of items shown per page.

For example:

20 posts per page
50 posts per page
100 posts per page

The same pattern applies to screens such as:

• Pages;
• Users;
• Comments;
• custom post types;
• plugin list tables that support the standard WordPress mechanism.

The official Users screen documentation confirms that the number of users displayed per page can be controlled through Screen Options.

More rows are not automatically better

Changing:

20 items per page

to:

500 items per page

can create a noticeably heavier administration request.

The page may need to:

• query more objects;
• load more metadata;
• render more rows;
• run more plugin column callbacks;
• generate more HTML.

This becomes especially important on screens where plugins add expensive custom columns.

Screen Options can therefore influence administration performance indirectly.

Dashboard Screen Options work differently

On the main Dashboard, Screen Options primarily control Dashboard widgets.

The official WordPress Dashboard documentation explains that the Screen Options panel contains checkboxes for available Dashboard widgets.

A user might see widgets such as:

At a Glance
Activity
Quick Draft
WordPress Events and News

plus widgets added by plugins.

Unchecking a widget hides it from that user’s Dashboard.

The widget still exists

This is crucial.

Suppose an administrator unchecks:

WordPress Events and News

The result is essentially:

User A
→ widget hidden

User B
→ widget may remain visible

The widget has not been unregistered from WordPress.

This is why Screen Options are useful for personal customization but are not always sufficient when an agency or organization wants a standardized Dashboard.

For that distinction, see WordPress Screen Options vs. Permanent Widget Removal.

Screen Options versus permanent Dashboard cleanup

There are two fundamentally different goals.

Goal one:

I personally do not want to see this widget.

Screen Options are ideal.

Goal two:

Nobody on this site needs this widget.

A site-wide removal is usually more appropriate.

WordPress developers can remove Dashboard widgets using:

remove_meta_box()

during the appropriate Dashboard setup process.

The official remove_meta_box() documentation covers this mechanism.

TheOneWP Disable Dashboard Widgets provides a site-wide way to disable selected Dashboard widgets instead of asking each user to hide them individually.

Screen Options can expose editing panels too

Some WordPress editing screens use Screen Options to expose optional panels or modules.

Historically, this has included things such as:

• Custom Fields;
• Discussion;
• Author;
• Slug;
• page attributes;
• plugin-generated meta boxes.

The official Pages Add New screen documentation explains that Screen Options can expose modules hidden from the editing interface.

The exact options depend on:

• WordPress version;
• editor type;
• post type;
• registered meta boxes;
• installed plugins.

Classic and block-based screens do not always behave identically

WordPress administration has evolved significantly around the Block Editor.

Some traditional wp-admin screens still use the classic Screen Options infrastructure directly, while modern JavaScript-driven interfaces can expose preferences through different controls.

Do not assume every administration screen must present the same classic hanging Screen Options tab.

The principle remains similar:

user-specific view preferences

but the interface used to manage those preferences can vary.

WordPress stores many Screen Options as user preferences

Screen Options are frequently stored on a per-user basis.

This is why two administrators can log into the same WordPress installation and see different columns.

WordPress Core’s get_hidden_columns() function retrieves hidden columns for a screen using a user option.

Conceptually:

User 12
Posts screen
→ Author hidden
→ Tags hidden

User 18
Posts screen
→ Author visible
→ Tags visible

The site configuration has not changed.

The users have different presentation preferences.

User options are different from ordinary site options

Do not confuse:

get_option()

with:

get_user_option()

Site options generally represent configuration shared by the site.

User options represent preferences associated with an individual account.

Screen Options frequently belong to the second category.

This explains why changing Screen Options on one account does not fix another account

An administrator may carefully configure:

Dashboard widgets
Posts columns
Pages columns
Users per page

then log into another account and discover a different interface.

Nothing is malfunctioning.

The settings belong to the individual user.

Screen Options are not roles or capabilities

Hiding a column, panel or widget through Screen Options does not change a user’s permissions.

For example, hiding:

Author

from a posts list does not change whether the user can edit another author’s posts.

Hiding:

Plugins

would not be a Screen Options capability decision anyway, but the same principle applies throughout wp-admin:

visibility
≠
authorization

For authorization, WordPress uses capabilities.

See WordPress User Roles and Capabilities, Explained for the permission model.

Screen Options are also not a security feature

Never rely on a hidden administration element to protect an operation.

Security-sensitive code should use:

current_user_can()

and appropriate capability checks.

The official current_user_can() reference documents the supported permission-checking mechanism.

Custom columns can integrate with Screen Options

Developers can add columns to WordPress list tables using filters such as:

manage_posts_columns
manage_pages_columns
manage_users_columns

manage_{$post_type}_posts_columns

The official manage_posts_columns documentation explains how column headings for the Posts list table can be filtered.

Properly registered columns can participate in the familiar WordPress list-table interface and may appear among the user’s Screen Options.

Optional columns should remain optional

If a plugin places a critical action only inside a custom column, but the user can hide that column through Screen Options, the workflow can disappear.

For example:

Custom column:
[Approve Customer]

If the entire column is hideable, a user may lose access to the only obvious approval action.

Important actions should not depend exclusively on an optional presentation element.

Use columns primarily for information and contextual actions

Good custom columns might display:

• featured images;
• external IDs;
• workflow status;
• last login;
• registration dates;
• custom taxonomy information.

The broader WordPress list-table architecture is explained in WordPress Admin List Tables Explained.

Developers can register custom Screen Options

WordPress provides:

add_screen_option()

for registering and configuring an option on the current administration screen.

The official add_screen_option() documentation shows that the function obtains the current WP_Screen object and registers the requested option with it.

A common use case is a custom:

per_page

setting.

Example: add a per-page Screen Option

function myplugin_screen_options() {

    add_screen_option(
        'per_page',
        array(
            'label'   => 'Items per page',
            'default' => 20,
            'option'  => 'myplugin_items_per_page',
        )
    );
}

This must be registered at the correct point in the administration screen lifecycle.

get_current_screen() identifies the current administration context

WordPress provides:

get_current_screen()

for retrieving the current WP_Screen object inside the administration area.

The official get_current_screen() documentation connects this API to Screen Options, contextual Help and other screen-aware functionality.

A developer might inspect:

$screen->id
$screen->base
$screen->post_type
$screen->taxonomy

to determine which administration screen is active.

Per-page preferences are saved for the current user

WordPress Core’s:

set_screen_options()

handles the saving of supported Screen Options such as the number of rows displayed on list screens.

The official set_screen_options() reference shows that WordPress validates the request, checks the Screen Options nonce and saves the corresponding user preference.

This reinforces the underlying model:

Screen Options
→ user-specific administration state

Screen Options can be extended through filters

Developers can customize how certain Screen Options are saved through the:

set-screen-option

filter and related screen-specific hooks.

This is useful for custom administration screens that need their own per-user preferences.

Do not store global application configuration in Screen Options

Suppose a plugin needs a setting such as:

Enable automatic invoice generation

That should not normally be a Screen Option.

It changes application behavior for the site.

It belongs in a configuration system such as the WordPress Options API.

Compare:

Screen Option:
Show 50 invoices per page

Site setting:
Automatically generate invoices

One changes presentation.

The other changes behavior.

Screen Options versus site settings

A useful distinction is:

Does this setting change
how I personally see this screen?

→ Screen Option may be appropriate.


Does this setting change
how the site actually behaves?

→ Site setting is more appropriate.

Screen Options versus Screen Preferences in modern interfaces

WordPress increasingly contains JavaScript-driven administration interfaces.

Some modern screens may expose user interface preferences somewhere other than the traditional Screen Options panel.

When developing new interfaces, focus on the conceptual distinction rather than reproducing the exact visual tab everywhere:

personal view preference
versus
site configuration

Why Screen Options are useful for large content sites

A Posts list on a simple blog might need:

Title
Author
Categories
Date

A complex publishing site might also expose:

SEO score
Workflow status
Language
Featured image
Last modified
External ID
Content owner

Showing every available column to every user can make the interface difficult to scan.

Screen Options let users keep the information relevant to their work.

Different roles can benefit from different views

An editor may prefer:

Title
Author
Workflow status
Last modified

An SEO specialist might prefer:

Title
SEO title
Meta description status
Canonical status

An administrator may want:

Title
Author
Date
Technical status
Plugin-specific data

User-specific Screen Options support those different working styles without requiring separate administration screens.

But team standardization may require something stronger

There is a tension between:

personal customization

and:

consistent team interface

If every employee needs to see:

Workflow Status

because internal documentation depends on that column, allowing it to disappear can create support problems.

In those situations, a team-wide administration configuration may be more appropriate than relying solely on Screen Options.

See Standardizing the WordPress Admin for Teams for the broader workflow.

Screen Options can become confusing on plugin-heavy sites

Plugins can add:

• custom columns;
• meta boxes;
• Dashboard widgets;
• custom list-table settings;
• additional administration panels.

The Screen Options panel can therefore grow along with the rest of wp-admin.

A user opening it may eventually encounter a long list of options whose purpose is unclear.

More configurable does not automatically mean easier

An administration interface containing:

18 optional columns
12 Dashboard widgets
9 editing panels

may technically be flexible while still being operationally difficult.

The better question is:

Which information is actually useful
for this workflow?

Screen Options can help diagnose a “missing field”

A common WordPress support problem is:

The field disappeared.

Before assuming a plugin is broken, check Screen Options.

The field may simply be hidden for the current user.

This can happen with:

• editing panels;
• list-table columns;
• Dashboard widgets;
• screen-specific modules.

Check whether the problem affects one user or everyone

This is a useful diagnostic shortcut.

If:

User A
→ field missing

User B
→ field visible

then investigate:

• Screen Options;
• user preferences;
• role differences;
• plugin role-based behavior.

If the field is missing for every user, investigate whether it has actually been:

• unregistered;
• disabled;
• removed by code;
• removed by a plugin;
• changed by an update.

Resetting Screen Options can require resetting user preferences

Because many Screen Options belong to the user, reinstalling a plugin or changing a site-wide setting may not reset them automatically.

For example, a user who previously hid a custom column may continue to have that column hidden after the plugin is updated.

Developers should be cautious about forcibly resetting user preferences during upgrades unless there is a clear migration reason.

Do not overwrite preferences on every request

A poorly designed plugin might try to enforce:

column X must always be visible

by rewriting the user option on every administration request.

That defeats the purpose of Screen Options and can create a frustrating interface where users make a change and WordPress immediately reverses it.

If a field must not be optional, design the administration screen accordingly rather than pretending it is a user preference.

Screen Options and custom columns should respect performance

A hidden column may not always eliminate every cost associated with the underlying feature.

The exact behavior depends on how the plugin implements the column.

A badly designed plugin might still:

• run expensive queries;
• load metadata;
• prepare data;

before checking whether the column is actually required.

Developers should avoid expensive per-row work where possible.

Admin list tables can magnify inefficient custom columns

Imagine:

100 posts displayed
×
5 custom columns
×
1 database query per column per post

That can produce:

500 additional queries

for one administration request.

Changing Screen Options to display fewer columns may reduce rendering complexity, but the plugin architecture still needs to be efficient.

Items-per-page settings can amplify inefficient code

If a page is reasonably fast at:

20 items

but becomes very slow at:

200 items

investigate:

• N+1 database queries;
• expensive metadata loading;
• remote API requests inside columns;
• unnecessary object loading;
• inefficient custom sorting.

Do not assume the correct solution is simply preventing the user from increasing the page size.

Screen Options can also affect administration documentation

Suppose an internal manual says:

Click the SEO Score column.

A user may respond:

I do not have an SEO Score column.

because they previously disabled it through Screen Options.

Documentation for larger teams should account for this.

For example:

If the column is not visible:
Screen Options
→ enable SEO Score

Use Screen Options when personalization is desirable

Good use cases include:

• hiding optional columns;
• adjusting list-table page size;
• hiding personally irrelevant Dashboard widgets;
• showing optional editing panels;
• simplifying a user’s working screen.

Use permanent removal when the component should not exist for the audience

A stronger administration change is appropriate when:

• a Dashboard widget has no value to anyone;
• a plugin panel should never appear for a certain role;
• an interface component causes confusion across the organization;
• a menu item needs role-based control;
• a feature has actually been disabled.

That difference can be summarized as:

User preference
→ Screen Options

Organizational interface policy
→ administration configuration

Security restriction
→ capability / authorization

TheOneWP and Screen Options

Several TheOneWP modules address administration consistency at a different layer from ordinary Screen Options.

Disable Dashboard Widgets can permanently remove selected Dashboard widgets from the site interface instead of requiring every user to hide them individually.

Dashboard Columns can establish a consistent Dashboard column configuration where a shared team layout is preferable to individual variation.

The purpose is not to replace WordPress Screen Options entirely.

It is to distinguish:

personal preference
from
site-wide administration policy

A practical Screen Options troubleshooting workflow

1. Confirm which administration screen is affected.
2. Open Screen Options.
3. Check whether the missing field, widget or column is listed.
4. Enable it temporarily.
5. Check whether the issue affects only one user.
6. Compare with another account where appropriate.
7. Check the user’s role and capabilities.
8. Identify whether a plugin added the component.
9. Determine whether the component was hidden or actually removed.
10. Only modify code or plugin configuration after identifying the correct layer.

Screen Options checklist for site administrators

• Remember that Screen Options are contextual to the current screen.
• Check Screen Options when a column or panel appears to be missing.
• Remember that different users can have different preferences.
• Use Screen Options for personal interface cleanup.
• Adjust items per page carefully on large datasets.
• Avoid displaying unnecessary columns.
• Do not treat hidden elements as disabled features.
• Do not treat Screen Options as access control.
• Use role and capability controls for authorization.
• Use permanent widget removal when nobody needs the widget.
• Account for Screen Options in internal documentation.
• Test administration screens with different users.

Screen Options checklist for developers

• Use get_current_screen() when administration behavior depends on the current screen.
• Use add_screen_option() for appropriate custom screen preferences.
• Use standard WordPress list-table hooks where possible.
• Allow non-critical columns to integrate naturally with Screen Options.
• Do not place essential actions only inside optional columns.
• Do not overwrite user preferences on every request.
• Keep per-page limits reasonable.
• Do not perform unnecessary work for hidden columns.
• Avoid expensive queries inside per-row column callbacks.
• Use capabilities for security-sensitive actions.
• Remember that a presentation preference is not site configuration.
• Test custom screens with multiple users and roles.

Related guides

• WordPress Screen Options vs. Custom Columns
• WordPress Screen Options vs. Permanent Widget Removal
• WordPress Admin List Tables Explained
• Decluttering the WordPress Admin Dashboard
• Standardizing the WordPress Admin for Teams
• WordPress User Roles and Capabilities, Explained

Final recommendation

WordPress Screen Options are best understood as user-specific controls over the presentation of an administration screen.

They can let users choose:

which columns appear
which widgets appear
which panels appear
how many records appear per page

but they normally do not determine:

what the user is authorized to do
what features exist on the site
what every other user sees

Use Screen Options when personal flexibility is useful. Use permanent administration configuration when an interface element should be standardized or removed for an entire audience. Use WordPress capabilities when actual access must be restricted.

That three-layer distinction keeps WordPress administration customization predictable:

Screen Options
→ personal presentation

Admin customization
→ shared interface

Capabilities
→ security and authorization

Once those responsibilities remain separate, Screen Options become what they were intended to be: a useful way for each user to simplify complex administration screens without turning personal preferences into site-wide behavior.