How to Remove Dashicons from the WordPress Front End

Dashicons is the official WordPress administration icon font.

It is heavily associated with the WordPress backend, but Dashicons can also appear on the public frontend.

When that happens, a browser may need to load:

dashicons.css
+
Dashicons font resource

If your public-facing theme and plugins do not use those icons, removing Dashicons from the frontend can eliminate an unnecessary stylesheet and font dependency.

But there is an important qualification:

Dashicons loaded
≠
Dashicons safe to remove

WordPress Core, the admin toolbar, your theme and plugins can all depend on the same registered stylesheet.

This means the correct process is:

audit
↓
identify dependencies
↓
remove only where unnecessary
↓
test
↓
measure

This guide explains how to remove Dashicons from the WordPress frontend safely, why logged-in users require special treatment, when wp_dequeue_style() is preferable to wp_deregister_style(), how dependencies can cause Dashicons to return and how to verify that the removal actually worked.

What are Dashicons?

Dashicons is WordPress’s official administration icon font.

WordPress has used it throughout administrative interfaces since WordPress 3.8.

Typical Dashicons markup looks like:

<span
    class="dashicons dashicons-search"
></span>

Another supported pattern uses:

dashicons-before

for example:

<span
    class="dashicons-before dashicons-email"
>
    Contact
</span>

Dashicons is registered by WordPress Core

Current WordPress Core registers the stylesheet under the handle:

dashicons

through its default stylesheet registry.

The official wp_default_styles() source includes:

$styles->add(
    'dashicons',
    "/wp-includes/css/dashicons$suffix.css"
);

The production file is normally equivalent to:

/wp-includes/css/dashicons.min.css

Registered does not mean loaded

This distinction matters.

WordPress knowing about:

dashicons

does not mean every frontend visitor automatically downloads it.

The stylesheet must be:

• explicitly enqueued;
• or required as a dependency of another enqueued stylesheet.

Before removing Dashicons, check whether your frontend uses it

You should not dequeue Dashicons merely because an optimization tutorial told you to.

First determine whether your theme or plugins actually depend on it.

See How to Check if Your Theme Uses Dashicons for a complete audit process.

The most important distinction: guests vs logged-in users

For many WordPress installations, Dashicons appears on the frontend because of the WordPress admin toolbar.

Current WordPress Core registers:

admin-bar
↓
depends on
↓
dashicons

The relevant Core registration is conceptually:

$styles->add(
    'admin-bar',
    '/wp-includes/css/admin-bar.css',
    array( 'dashicons' )
);

This means authenticated users can legitimately require Dashicons even when ordinary site visitors do not.

This is why removing Dashicons globally can be a mistake

Consider:

anonymous visitor
→ no toolbar
→ theme does not use Dashicons
→ Dashicons unnecessary

logged-in administrator
→ toolbar displayed
→ toolbar depends on Dashicons
→ Dashicons may be required

The safest common configuration is therefore often:

remove Dashicons for guests
keep Dashicons for logged-in users

The basic way to dequeue Dashicons

WordPress provides:

wp_dequeue_style()

The official wp_dequeue_style() documentation describes it as removing a previously enqueued stylesheet.

The basic call is:

wp_dequeue_style( 'dashicons' );

Do not execute it randomly

The call needs to run after Dashicons has been enqueued.

The appropriate frontend hook is:

wp_enqueue_scripts

The official wp_enqueue_scripts documentation confirms that this is the proper hook for frontend scripts and styles.

Despite the name, it handles both.

A safe guest-only Dashicons removal snippet

For a site where public visitors do not require Dashicons, a practical pattern is:

add_action(
    'wp_enqueue_scripts',
    function () {
        if ( is_user_logged_in() ) {
            return;
        }

        wp_dequeue_style( 'dashicons' );
    },
    100
);

This produces:

logged-out visitor
→ Dashicons dequeued

logged-in user
→ Dashicons preserved

Why use a late priority?

The default action priority is:

10

If a theme or plugin enqueues Dashicons later than your removal function, this can happen:

priority 5
→ you dequeue Dashicons

priority 10
→ theme enqueues Dashicons

result
→ Dashicons loads anyway

Running later changes the order:

theme/plugin enqueue
↓
your late removal
↓
final queue without Dashicons

Priority 100 is not magical

It is simply later than the common default priority.

If another component enqueues Dashicons at:

200

then your priority-100 removal occurs too early.

Always inspect the actual site rather than assuming one number works universally.

Do you need wp_deregister_style() too?

Usually not for simple frontend removal.

This distinction is useful:

wp_dequeue_style()
→ remove from current loading queue

wp_deregister_style()
→ remove stylesheet registration

The official wp_deregister_style() documentation describes it as removing a registered stylesheet.

Dequeue is usually the narrower operation

If your objective is:

do not load Dashicons
for public visitors

then:

wp_dequeue_style( 'dashicons' );

is normally the operation that matches the requirement.

Deregistering changes more

If you call:

wp_deregister_style( 'dashicons' );

you remove the registered handle from WordPress’s stylesheet registry for the remainder of that request.

That can affect code expecting the registered dependency to exist.

Aggressive removal example

If you have a very controlled frontend and intentionally want both removal from the queue and removal from the registry:

add_action(
    'wp_enqueue_scripts',
    function () {
        if ( is_user_logged_in() ) {
            return;
        }

        wp_dequeue_style( 'dashicons' );
        wp_deregister_style( 'dashicons' );
    },
    100
);

This should be used only after dependency testing.

Why deregistering can cause trouble

Imagine a plugin registers:

plugin-interface
↓
depends on
↓
dashicons

If Dashicons is no longer registered, the dependency graph is now incomplete.

The plugin may display incorrectly or its stylesheet loading behavior may become unpredictable.

A dependent stylesheet can cause Dashicons to load

This is one of the most common reasons a simple dequeue appears not to work.

Suppose a plugin registers:

wp_enqueue_style(
    'frontend-controls',
    $url,
    array( 'dashicons' ),
    '1.0.0'
);

The dependency chain is:

frontend-controls
↓
dashicons

If frontend-controls remains required, WordPress’s dependency resolver can still require Dashicons.

You should not fight the dependency system blindly

If another stylesheet genuinely depends on Dashicons, ask:

Does that stylesheet actually
use Dashicon glyphs?

If yes, removing Dashicons will break it.

If no, the dependency declaration itself may need correcting.

Fix the source when you control it

If your own theme contains:

wp_enqueue_style(
    'theme-main',
    $url,
    array( 'dashicons' ),
    '1.0.0'
);

but the CSS no longer uses Dashicons, change the registration to:

wp_enqueue_style(
    'theme-main',
    $url,
    array(),
    '1.0.0'
);

This is cleaner than repeatedly dequeuing a dependency you unnecessarily declared yourself.

Use WordPress’s dependency system intentionally

The official wp_enqueue_style() documentation confirms that the $deps argument contains the handles the stylesheet depends on.

For the wider asset-loading architecture, see wp_enqueue_scripts Explained.

How to check whether Dashicons is currently enqueued

WordPress provides:

wp_style_is()

You can temporarily inspect the queue:

add_action(
    'wp_enqueue_scripts',
    function () {
        if ( wp_style_is( 'dashicons', 'enqueued' ) ) {
            error_log( 'Dashicons is enqueued.' );
        }
    },
    999
);

This confirms whether the handle is in the queue at that point.

Registered and enqueued are different states

Because Core registers Dashicons, this:

wp_style_is(
    'dashicons',
    'registered'
);

can return true without the browser ever receiving the stylesheet.

For frontend removal, the more relevant question is normally:

Is it enqueued?

How to identify styles that depend on Dashicons

You can inspect the global stylesheet registry through:

wp_styles()

A temporary diagnostic snippet:

add_action(
    'wp_enqueue_scripts',
    function () {
        $styles = wp_styles();

        foreach ( $styles->registered as $handle => $style ) {
            if (
                in_array(
                    'dashicons',
                    $style->deps,
                    true
                )
            ) {
                error_log(
                    $handle
                    . ' depends on Dashicons.'
                );
            }
        }
    },
    999
);

This can reveal indirect loading

You may discover:

admin-bar
depends on Dashicons

or:

plugin-ratings
depends on Dashicons

or:

theme-ui
depends on Dashicons

Each requires a different decision.

The admin toolbar deserves special protection

Current WordPress Core explicitly declares Dashicons as a dependency of the admin-bar stylesheet.

That is why the guest-only condition:

if ( ! is_user_logged_in() )

is commonly safer than globally removing Dashicons from every frontend request.

Do not confuse frontend removal with admin removal

This guide is about:

public WordPress frontend

not:

/wp-admin/

Dashicons remains deeply integrated with administrative interfaces and Core styles.

Removing or deregistering it globally across WordPress administration can break:

• menu icons;
• buttons;
• media interfaces;
• plugin UI;
• administrative controls.

Do not use admin_enqueue_scripts for this frontend optimization

admin_enqueue_scripts is intended for administration pages.

Frontend assets should be handled through:

wp_enqueue_scripts

Where should the removal code live?

A Dashicons optimization is site behavior rather than theme presentation in many projects.

Possible locations include:

• a site-specific plugin;
• a must-use plugin;
• a maintained snippet manager;
• a child theme if the behavior is explicitly tied to that theme.

Avoid modifying WordPress Core

Do not edit:

/wp-includes/css/dashicons.css

or:

/wp-includes/script-loader.php

to remove Dashicons.

Core updates can overwrite those changes, and changing WordPress internals for a frontend enqueue decision is unnecessary.

Avoid editing the parent theme directly

If the theme itself loads Dashicons and will receive future updates, editing the parent theme can also be overwritten.

Use a child theme or site-level implementation where appropriate.

Test the removal while logged out

Open a private/incognito browser window.

Then:

1. Open Developer Tools.
2. Go to Network.
3. Filter by CSS.
4. Reload the page.
5. Search for dashicons.

Before removal you may see:

/wp-includes/css/dashicons.min.css

After successful removal for guests, that request should disappear.

Inspect the page source too

Search the rendered HTML for:

dashicons-css

A normal WordPress style tag may have an ID such as:

dashicons-css

If the stylesheet is no longer queued, that link should no longer appear.

Then inspect visual behavior

Removing the network request is not enough.

Search the frontend for:

• missing icons;
• empty squares;
• incorrect glyphs;
• broken arrows;
• missing menu icons;
• missing search icons;
• broken rating stars;
• misaligned controls.

Test pseudo-elements

Dashicons can be used entirely through CSS:

.search-toggle::before {
    font-family: dashicons;
    content: "\f179";
}

No element needs to contain:

class="dashicons"

for the dependency to exist.

This is why visual testing matters even after searching HTML.

Test responsive states

A theme may use Dashicons only for mobile controls.

For example:

desktop
→ textual menu

mobile
→ Dashicons menu icon

Removing the font could look perfect on desktop and break at 390 pixels.

Check intermediate viewport widths

Test more than one desktop and one mobile width.

Useful examples include:

1440
1200
1024
768
600
430
390
360

or the breakpoints used by the actual project.

Test interaction states

An icon may appear only when a component is active.

Check:

• mobile menus;
• dropdowns;
• accordions;
• modals;
• search overlays;
• forms;
• pagination;
• carousels;
• account interfaces;
• frontend dashboards.

Test plugin-specific pages

A plugin may use Dashicons only on one frontend route.

Possible examples include:

• account pages;
• membership areas;
• booking forms;
• product pages;
• checkout;
• user dashboards.

Global removal must be safe across all of them.

Conditional Dashicons loading may be the better solution

Suppose the site needs Dashicons only on one frontend dashboard.

Instead of:

Dashicons everywhere

or:

Dashicons nowhere

you can implement:

normal public pages
→ remove Dashicons

dashboard
→ keep Dashicons

Example of conditional removal

Assume Dashicons is required only on a specific page:

add_action(
    'wp_enqueue_scripts',
    function () {
        if ( is_user_logged_in() ) {
            return;
        }

        if ( is_page( 'special-interface' ) ) {
            return;
        }

        wp_dequeue_style( 'dashicons' );
    },
    100
);

The exact condition should match your site’s real architecture.

Do not copy a placeholder slug into production and then wonder why the universe has once again declined to infer your intentions.

If your theme uses only one Dashicon, consider replacing it

Sometimes the frontend needs Dashicons only because one theme element contains:

dashicons-search

In that situation, replacing one icon can eliminate the entire dependency.

Inline SVG is a common alternative

Instead of:

Dashicons stylesheet
+
font
+
one search icon

you can use:

<svg
    viewBox="0 0 24 24"
    aria-hidden="true"
>
    ...
</svg>

Inline SVG can provide:

• no font request;
• precise sizing;
• easy color inheritance;
• better control;
• no unrelated icon glyphs.

Use currentColor for reusable SVG icons

An SVG can often use:

fill="currentColor"

or:

stroke="currentColor"

so it follows the text color of the surrounding interface.

Do not replace Dashicons with a larger global icon library

If the objective is reducing frontend requests and payload, replacing Dashicons with:

another large webfont
+
another global stylesheet

may accomplish very little.

Compare the resulting architecture, not the brand name of the icon system.

Should you use an SVG sprite?

If the site uses many icons repeatedly, an SVG sprite can be a useful alternative.

The architecture may become:

one controlled SVG asset
↓
multiple icon references

This can be more appropriate than duplicating many inline SVGs.

Removing Dashicons can reduce frontend requests

When Dashicons is genuinely used, the browser may request:

dashicons stylesheet
↓
font resource

Removing the dependency can therefore reduce the frontend request graph.

See Reducing WordPress Front-End Requests for the broader request-level optimization process.

Removing Dashicons can also reduce page weight

The stylesheet and font contribute additional transferred resources.

The exact saving depends on:

• WordPress version;
• compression;
• cache state;
• CDN configuration;
• whether the font itself was actually requested.

Do not publish an exact universal KB saving unless you measured it on the current site.

For the wider payload discussion, see Reducing WordPress Front-End Page Weight.

Dashicons may already be cached for returning users

A warm browser cache can reduce repeat transfer cost.

This does not make an unused dependency useful, but it means the difference between:

cold visit
and
return visit

can be substantial.

Measure cold and warm loads separately

For a useful before-and-after test:

1. Record a cold load.
2. Record request count and transferred bytes.
3. Apply Dashicons removal.
4. Clear relevant caches.
5. Record another cold load.
6. Repeat with warm-cache navigation.

Do not expect Dashicons removal to transform a heavy site

Suppose the page contains:

5 MB hero media
+
1.5 MB JavaScript
+
3 external videos
+
8 font files
+
Dashicons

Dashicons is probably not the dominant problem.

Removing it is legitimate cleanup, but optimization priority matters.

Third-party embeds usually deserve more attention

One external video player can generate far more network activity and JavaScript work than Dashicons.

See Why Third-Party Embeds Slow Down WordPress.

Unused JavaScript may also matter more

Large plugin scripts can introduce:

• network transfer;
• parsing;
• compilation;
• execution;
• main-thread work.

See How to Remove Unused WordPress Scripts.

How TheOneWP removes Dashicons

If your public frontend does not require the icon font, TheOneWP Disable Dashicons provides a dedicated control for removing Dashicons from the frontend.

The module supports separate behavior for guest and logged-in users.

That distinction is important because Core frontend administration elements can depend on Dashicons even when the public theme does not.

Why guest-only removal is usually the sensible default

The configuration can follow:

visitor not logged in
↓
public theme audited
↓
Dashicons unnecessary
↓
remove

visitor logged in
↓
WordPress toolbar may exist
↓
Dashicons may be required
↓
keep

This minimizes risk while still removing the unnecessary public dependency.

Do not combine several Dashicons-removal mechanisms

Avoid simultaneously using:

• custom PHP;
• a performance plugin;
• a theme optimization setting;
• TheOneWP Disable Dashicons;
• another snippets plugin;

to remove the same stylesheet.

Choose one owner for the behavior.

Multiple removal systems make debugging harder

If Dashicons disappears on one page but returns on another, you need to know which component owns the final queue state.

Several overlapping implementations make that unnecessarily difficult.

Do not hardcode removal inside random templates

Avoid placing:

wp_dequeue_style( 'dashicons' );

inside template files such as:

header.php
single.php
page.php

Asset management should happen through the appropriate enqueue lifecycle.

Check whether the stylesheet returns after plugin updates

A plugin may change its dependencies in a future release.

After important theme or plugin updates, re-check:

Network
↓
dashicons

and verify visual behavior.

Test removals on staging

Asset changes can affect pages you did not expect.

Use a staging environment for the first test.

See WordPress Staging Site Best Practices.

A recommended manual implementation

For many conventional WordPress sites, the narrow implementation is:

/**
 * Remove Dashicons from the public frontend for guests.
 *
 * Keep Dashicons available to logged-in users because
 * WordPress frontend administration interfaces may
 * depend on them.
 */
add_action(
    'wp_enqueue_scripts',
    function () {
        if ( is_user_logged_in() ) {
            return;
        }

        wp_dequeue_style( 'dashicons' );
    },
    100
);

Why this snippet does not deregister Dashicons

The objective is simply:

remove from guest frontend queue

not:

rewrite WordPress's global stylesheet registry

Using the narrower operation reduces the chance of disturbing dependencies unnecessarily.

When the basic snippet may not be enough

You need deeper investigation if:

• Dashicons still loads afterward;
• a dependent stylesheet re-enqueues it;
• the theme uses Dashicons conditionally;
• a plugin requires it;
• icons disappear;
• the site has custom frontend administration interfaces.

If Dashicons still loads, inspect dependencies

Do not simply increase priority indefinitely.

Find which registered stylesheet declares:

dashicons

as a dependency.

Then decide whether:

• that parent stylesheet is necessary;
• the dependency is legitimate;
• the parent asset should be loaded conditionally;
• Dashicons should actually remain.

If icons break, restore Dashicons first

A missing icon after removal is evidence that your audit was incomplete.

Restore the dependency before redesigning the entire stylesheet queue.

Then identify the consumer and decide whether to:

• keep Dashicons;
• replace that icon;
• load Dashicons conditionally;
• refactor the component.

Dashicons removal checklist

• Confirm that Dashicons is actually loaded for logged-out visitors.
• Check the Network panel for dashicons.css.
• Inspect page source for dashicons-css.
• Search the rendered DOM for Dashicon classes.
• Check ::before and ::after pseudo-elements.
• Inspect computed font-family.
• Search the active theme for dashicons.
• Search the child theme.
• Search the parent theme.
• Check active plugins.
• Look for wp_enqueue_style( 'dashicons' ).
• Inspect stylesheet dependency arrays.
• Use wp_style_is() where useful.
• Use wp_styles() to inspect dependencies.
• Remember that Core registers Dashicons even when the frontend does not use them.
• Remember that the admin bar depends on Dashicons.
• Prefer guest-only removal unless logged-in usage has been audited separately.
• Use wp_dequeue_style() for normal queue removal.
• Do not automatically deregister Dashicons.
• Run removal after the enqueue that you intend to override.
• Do not rely on an arbitrary hook priority without testing.
• Test the homepage.
• Test posts.
• Test pages.
• Test archives.
• Test forms.
• Test account pages.
• Test e-commerce pages where relevant.
• Test desktop navigation.
• Test mobile navigation.
• Test modals and dropdowns.
• Test hover and focus states.
• Test as a logged-out visitor.
• Test separately as a logged-in administrator.
• Clear caches before comparing results.
• Measure actual request and transfer savings.
• Re-test after significant theme or plugin changes.

Related guides

• How to Check if Your Theme Uses Dashicons
• Reducing WordPress Front-End Requests
• Reducing WordPress Front-End Page Weight
• wp_enqueue_scripts Explained
• How to Remove Unused WordPress Scripts
• Why Third-Party Embeds Slow Down WordPress

Final recommendation

Removing Dashicons from the WordPress frontend is a sensible optimization when public visitors genuinely do not use them.

But the decision should come after an audit, not before it.

Start by separating three states:

registered
↓
WordPress knows about Dashicons

enqueued
↓
current request wants Dashicons

used
↓
frontend UI actually depends on Dashicons

WordPress registering the stylesheet is normal.

What matters is whether it is enqueued and required for the current frontend context.

Pay particular attention to authenticated users because WordPress’s admin-bar stylesheet currently declares Dashicons as a dependency.

For that reason, the safest common optimization is:

guests
→ dequeue Dashicons

logged-in users
→ preserve Dashicons

Use wp_dequeue_style( 'dashicons' ) through the frontend wp_enqueue_scripts lifecycle rather than editing Core files or randomly removing stylesheet tags after WordPress has generated the page.

Do not automatically deregister the handle unless you understand the dependency consequences.

If Dashicons returns after dequeueing, investigate which stylesheet depends on it rather than repeatedly increasing hook priority.

If your own theme needs only one or two Dashicon glyphs, replacing those icons with lightweight SVGs may allow you to eliminate the dependency cleanly.

Finally, keep the optimization in perspective.

Dashicons is a valid cleanup target, but it is normally a smaller concern than oversized images, unnecessary JavaScript, excessive fonts and heavy third-party embeds.

The useful rule is:

verify it is unused
↓
remove it narrowly
↓
preserve authenticated functionality
↓
test every relevant frontend state
↓
measure the real result

That produces a safer WordPress frontend than simply dequeuing every Core stylesheet whose name appears in an optimization checklist.