How to Check if your Theme Uses Dashicons

Dashicons is the official icon font traditionally used throughout the WordPress administration interface.

It provides familiar icons for:

• dashboard menus;
• posts and pages;
• media;
• settings;
• users;
• comments;
• custom post types;
• plugin interfaces;
• other WordPress UI elements.

Dashicons can also appear on the public frontend.

That creates a common optimization question:

Can I remove Dashicons
from my WordPress frontend?

Before doing that, you need to answer a more important question:

Does my theme or another
frontend component actually
use Dashicons?

Simply seeing dashicons.min.css in the page source is not enough to answer that.

The stylesheet may have been loaded by:

• WordPress Core;
• the admin toolbar;
• your theme;
• a plugin;
• a stylesheet dependency;
• custom code.

This guide explains how to determine whether your WordPress theme genuinely uses Dashicons, how to distinguish theme usage from Core or plugin usage, how to inspect the stylesheet queue, how to search your theme files and how to test whether removing Dashicons is actually safe.

What are Dashicons?

Dashicons is the official WordPress admin icon font.

WordPress has used Dashicons for administration icons since WordPress 3.8.

A typical Dashicon can be rendered with HTML such as:

<span class="dashicons dashicons-admin-home"></span>

or through the dashicons-before helper class:

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

The icon itself comes from the Dashicons font loaded by WordPress’s Dashicons stylesheet.

What does the Dashicons stylesheet contain?

WordPress registers Dashicons under the stylesheet handle:

dashicons

Current WordPress Core registers the stylesheet from:

/wp-includes/css/dashicons.css

or the minified production equivalent:

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

The current wp_default_styles() source shows Core registering:

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

Seeing Dashicons loaded does not prove your theme uses it

This is the most important distinction in the audit.

You may inspect your page source and find:

dashicons.min.css

That tells you:

Dashicons is loaded

It does not tell you:

your theme uses Dashicons

Several systems can enqueue the same registered stylesheet.

WordPress Core itself can require Dashicons

Current WordPress registers several styles that declare dashicons as a dependency.

Examples in Core include:

• admin-bar;
• wp-auth-check;
• editor-buttons;
• media-views;
• wp-pointer;
• customize-preview;
• several administrative styles.

This means the dependency graph can look like:

admin-bar
↓
depends on
↓
dashicons

Even if your theme never references a single Dashicon.

The WordPress admin bar is a common reason Dashicons appears

For logged-in users, the WordPress toolbar may be displayed on the frontend.

Current Core registers the admin-bar stylesheet with Dashicons as a dependency.

That means:

logged-in frontend
↓
admin bar loads
↓
Dashicons loads

This can lead to a misleading test.

You inspect the site while logged in, see Dashicons and conclude:

the theme requires Dashicons

when the real reason may simply be:

WordPress admin toolbar

Always test logged out

The first useful Dashicons test is therefore extremely simple.

1. Open the frontend while logged in.
2. Check whether Dashicons loads.
3. Open a private/incognito window.
4. Visit the same URL while logged out.
5. Check again.

If Dashicons disappears for logged-out visitors, the admin toolbar may have been responsible.

How to check whether Dashicons is loaded

You can inspect it using your browser’s developer tools.

Method 1: inspect the Network panel

Open Developer Tools and navigate to:

Network
↓
CSS

Reload the page and search for:

dashicons

You may see a request similar to:

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

Method 2: inspect page source

Search the rendered source for:

dashicons

You may find something similar to:

<link
    rel="stylesheet"
    id="dashicons-css"
    href="https://example.com/wp-includes/css/dashicons.min.css"
    media="all"
/>

The generated element ID is useful because WordPress stylesheet handles are commonly reflected in the output.

Loaded is not the same as used

A stylesheet can be present while none of its icon classes are actually used on the page.

The situation may be:

Dashicons stylesheet
→ loaded

Dashicon classes
→ zero frontend matches

In that case the stylesheet may be removable for that visitor context.

But you still need to determine why it was loaded before removing it.

Search the rendered HTML for Dashicon classes

The next step is to inspect the final DOM.

Search for:

dashicons

Typical class patterns include:

dashicons
dashicons-before
dashicons-admin-home
dashicons-menu
dashicons-search
dashicons-email
dashicons-cart

If you find markup such as:

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

then something on that page is clearly using the icon font.

Inspect which element owns the class

Do not stop after finding the class.

Inspect the surrounding HTML.

For example:

<header class="site-header">
    <button class="search-toggle">
        <span
            class="dashicons dashicons-search"
        ></span>
    </button>
</header>

This strongly suggests that the theme or header implementation uses Dashicons.

Compare that with:

<div id="wpadminbar">
    ...
    <span class="ab-icon"></span>
</div>

which belongs to WordPress’s logged-in toolbar rather than your public theme design.

Search your active theme files

The most direct source-code check is to search the theme directory.

Search for:

dashicons

inside:

/wp-content/themes/your-theme/

Useful files to inspect include:

• functions.php;
• template files;
• template parts;
• CSS files;
• JavaScript files;
• block templates;
• PHP classes;
• theme includes.

What should you search for?

Search several patterns rather than only the word:

dashicons

Look for:

dashicons-
dashicons-before
wp_enqueue_style( 'dashicons'
wp_enqueue_style("dashicons"
array( 'dashicons' )
array("dashicons")

A theme may enqueue Dashicons explicitly

You could find:

wp_enqueue_style( 'dashicons' );

This is strong evidence that the theme intentionally asks WordPress to load Dashicons.

The official wp_enqueue_style() documentation explains that an already registered stylesheet can be enqueued by its handle without supplying the source again.

Because Core already registers dashicons, a theme only needs:

wp_enqueue_style( 'dashicons' );

to request it.

A theme may declare Dashicons as a dependency instead

This is slightly easier to miss.

You might find:

wp_enqueue_style(
    'theme-icons',
    get_theme_file_uri( '/assets/css/icons.css' ),
    array( 'dashicons' ),
    '1.0.0'
);

The theme never directly says:

load Dashicons separately

but its own stylesheet depends on Dashicons.

WordPress’s dependency system will therefore ensure Dashicons is loaded first.

This is why understanding wp_enqueue_scripts Explained is useful when auditing frontend assets.

Search CSS for the Dashicons font family

A theme may use Dashicons without obvious dashicons-* classes.

For example:

.menu-toggle::before {
    font-family: dashicons;
    content: "\f333";
}

or:

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

This is important because searching only HTML classes would miss it.

Search for font-family declarations

Search theme CSS for:

font-family: dashicons
font-family:"dashicons"
font-family: "dashicons"
font-family:'dashicons'
font-family: 'dashicons'

Spacing and quoting vary, so a project-wide case-insensitive search for:

dashicons

is still usually the simplest approach.

Search for Dashicon Unicode values carefully

Some themes reference the icon font only through Unicode glyph values.

Example:

.theme-arrow::before {
    font-family: dashicons;
    content: "\f345";
}

The content value alone does not identify Dashicons.

A hexadecimal CSS glyph such as:

\f345

could belong to another icon font.

The important evidence is the associated font family.

Do not search only functions.php

Modern themes can organize enqueue logic across many files.

You may find frontend assets inside:

/inc/
/includes/
/src/
/assets/
/classes/

or inside a theme framework.

Search the entire active theme directory.

Check the child theme too

If the site uses a child theme, inspect both:

child theme
+
parent theme

A child theme may enqueue Dashicons even when the parent does not.

The reverse is also possible.

Plugins can make the theme appear responsible

Suppose the page contains:

<span
    class="dashicons dashicons-star-filled"
></span>

inside a review widget.

The theme may merely provide the page layout.

The plugin generating that widget may be the actual Dashicons consumer.

Inspect plugin markup

Look at surrounding class names and DOM structure.

For example:

<div class="review-plugin-rating">
    <span
        class="dashicons dashicons-star-filled"
    ></span>
</div>

This strongly suggests a plugin dependency rather than a theme dependency.

Search plugin files when necessary

If the origin is unclear, search:

/wp-content/plugins/

for:

dashicons

Ideally, narrow the search to the plugins active on the affected page.

Use wp_style_is() to inspect the WordPress style queue

WordPress provides the function:

wp_style_is()

The official wp_style_is() documentation explains that it can check whether a stylesheet is:

• enqueued;
• registered;
• in the queue;
• in to_do;
• already done.

Check whether Dashicons is enqueued

For debugging, you can temporarily use:

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

This confirms the WordPress queue state.

It still does not tell you which component caused the enqueue.

Registered does not mean loaded

This distinction matters when using wp_style_is().

Current WordPress Core registers Dashicons by default.

Therefore:

wp_style_is(
    'dashicons',
    'registered'
)

may return true simply because Core knows about the stylesheet.

That does not prove it is being printed on the frontend.

Use enqueued or queue when checking frontend loading

The more useful states are normally:

enqueued
queue
done

depending on exactly when your debugging code executes.

Inspect the global WP_Styles object for dependencies

For deeper debugging, WordPress exposes its registered style system through:

wp_styles()

The function returns the global WP_Styles instance.

You can inspect registered dependencies programmatically.

For example:

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 dependencies

You might discover something such as:

theme-main
→ depends on dashicons

or:

admin-bar
→ depends on dashicons

Those two results mean very different things.

Inspect only enqueued dependents when possible

The registry may contain styles that are registered but not actually used on the current page.

A more useful debug check can combine dependency inspection with queue status:

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

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

Remember that timing affects debugging

If you check too early:

wp_style_is( 'dashicons' )

may return false simply because the theme or plugin has not enqueued its styles yet.

That is why debugging examples often run at a very late priority.

But hook priority should not be treated as a permanent substitute for understanding asset dependencies.

Use Query Monitor when you need easier attribution

A debugging plugin such as Query Monitor can make asset inspection easier by showing enqueued styles and their relationships without requiring temporary logging code.

When auditing a complex site, this can be considerably faster than manually tracing every hook.

Temporarily disable the theme to distinguish ownership

On a staging site, you can also perform a controlled comparison.

1. Record whether Dashicons loads with the current theme.
2. Switch temporarily to a default WordPress theme.
3. Load the same frontend context.
4. Compare the result.

If Dashicons disappears only when the theme changes, the active theme or child theme becomes a strong candidate.

But this is still not absolute proof because changing themes can also alter which plugins or widgets execute.

Never perform this diagnostic directly on production

Switching themes can affect:

• menus;
• widgets;
• templates;
• customizer settings;
• frontend output;
• block templates;
• plugin integrations.

Use a staging copy.

See WordPress Staging Site Best Practices.

Temporarily dequeue Dashicons as a visual test

Once you believe logged-out frontend visitors do not require Dashicons, you can test that assumption on staging.

A temporary diagnostic snippet can be:

add_action(
    'wp_enqueue_scripts',
    function () {
        if ( ! is_user_logged_in() ) {
            wp_dequeue_style( 'dashicons' );
        }
    },
    999
);

Then inspect the entire frontend carefully.

What should you look for after removing it?

Check for:

• missing icons;
• empty squares;
• strange glyphs;
• misaligned buttons;
• missing arrows;
• missing search icons;
• social icons;
• star ratings;
• navigation controls;
• modal controls;
• frontend plugin interfaces.

Do not test only the homepage

Your homepage may not contain the component that requires Dashicons.

Check representative:

• posts;
• pages;
• archives;
• search results;
• 404 pages;
• contact pages;
• account pages;
• checkout flows;
• custom post types;
• logged-out forms.

Responsive states matter

Some themes use one icon system on desktop and another on mobile.

For example:

desktop
→ text navigation

mobile
→ Dashicons menu icon

If you test only desktop, you could remove Dashicons and silently break the mobile navigation icon.

Test hover, focus and active states

Icons may appear only after interaction.

Check:

• hover states;
• keyboard focus;
• dropdown menus;
• accordions;
• modals;
• search overlays;
• mobile menus;
• pagination;
• back-to-top controls.

Check pseudo-elements

This is particularly important.

A theme may not contain any Dashicons HTML at all.

Instead:

.menu-item-has-children > a::after {
    font-family: dashicons;
    content: "\f347";
}

The icon exists only through CSS.

Searching the DOM for:

class="dashicons"

would completely miss it.

Use browser computed styles

If an icon appears but you are unsure where it comes from:

1. Inspect the icon element.
2. Check ::before and ::after.
3. Open Computed Styles.
4. Find font-family.

If you see:

dashicons

then you have direct evidence that the rendered element depends on the font.

Search for the @font-face declaration only with context

The Dashicons stylesheet itself contains its own font definition.

Therefore seeing:

@font-face {
    font-family: dashicons;
}

inside loaded CSS merely proves the Dashicons stylesheet exists.

It does not prove another frontend rule uses the font.

Browser Coverage can provide additional evidence

CSS coverage tools can help identify whether rules inside a loaded stylesheet were used during the current page session.

This can be useful for answering:

Did this page actually use
anything from dashicons.css?

However, coverage is interaction-dependent.

Unused during one recording does not mean unused everywhere

An icon may appear only:

• after opening a menu;
• after submitting a form;
• inside a modal;
• on another template;
• at another viewport width;
• for another user state.

Coverage results should therefore support the audit, not replace it.

Theme usage can be conditional

Your theme might enqueue Dashicons only on:

single posts
WooCommerce pages
search results
mobile
logged-in frontend
specific templates

A single homepage test cannot detect all of these cases.

Look for conditional enqueue logic

Theme code might contain:

if ( is_singular( 'post' ) ) {
    wp_enqueue_style( 'dashicons' );
}

or:

if ( is_page_template( 'contact.php' ) ) {
    wp_enqueue_style( 'dashicons' );
}

This means Dashicons can be legitimately absent on some templates and required on others.

Do not infer global safety from one URL

If you want to remove Dashicons globally for guests, your test must cover all relevant frontend contexts.

Check whether plugins use Dashicons only on specific pages

A plugin may enqueue the font on:

• login forms;
• account pages;
• frontend dashboards;
• booking pages;
• forms;
• product pages.

This can make global removal inappropriate even if most pages do not use the font.

Conditional removal may be safer

Suppose Dashicons is needed only on:

/account/

Then instead of globally removing it, you might use a condition appropriate to that project.

The general pattern is:

if ( current page does not need Dashicons ) {
    wp_dequeue_style( 'dashicons' );
}

The exact condition should match the site’s actual templates rather than a generic snippet copied blindly.

What about logged-in users?

This deserves special treatment because the WordPress toolbar commonly depends on Dashicons.

Current Core registers:

admin-bar
↓
dependency
↓
dashicons

Removing Dashicons for logged-in frontend users may therefore affect the toolbar.

A common optimization is guest-only removal

If the public site does not use Dashicons but WordPress’s logged-in interface does, a reasonable strategy is:

logged-out visitors
→ Dashicons removed

logged-in users
→ Dashicons retained

This is safer than blindly dequeuing the stylesheet for everyone.

How TheOneWP handles Dashicons

If your frontend does not need Dashicons, TheOneWP Disable Dashicons provides a dedicated control for removing the Dashicons stylesheet from the frontend.

The module distinguishes between guest and logged-in behavior, which is important because WordPress administrative frontend elements can still depend on the icon font.

The goal should be:

public frontend
does not use Dashicons
↓
remove unnecessary stylesheet

WordPress interface
still needs Dashicons
↓
preserve it where required

Should you replace Dashicons in your theme?

If your custom theme uses only one or two Dashicons on the frontend, it may be worth replacing them with another strategy.

Possible alternatives include:

• inline SVG;
• CSS shapes;
• locally bundled SVG sprites;
• text symbols where semantically appropriate.

Inline SVG is often suitable for isolated frontend icons

For example, instead of requiring an entire icon font for one search icon:

Dashicons font
+
Dashicons stylesheet
+
one icon

you can use:

one inline SVG

This can provide:

• explicit markup;
• precise sizing;
• easy styling with currentColor;
• no icon-font dependency.

Do not replace one small icon font with a larger one

Removing Dashicons and then loading an enormous third-party icon library just to recreate three icons is not an optimization.

Compare the complete resulting dependency, not merely the name of the library.

Dashicons is usually not your biggest performance problem

This is worth keeping in perspective.

If the page contains:

4 MB hero image
1 MB third-party JavaScript
3 video embeds
8 font files
+
Dashicons

Dashicons is unlikely to deserve first place in your optimization plan.

For the broader priority order, see Reducing WordPress Front-End Page Weight.

Small assets still deserve cleanup when genuinely unused

The fact that Dashicons is not usually the largest performance problem does not mean it should always remain.

If:

public visitors never use it
+
nothing depends on it
+
removal is tested

then removing it is legitimate frontend hygiene.

Removing Dashicons can reduce more than one request

The stylesheet references the associated font files.

When actual Dashicon glyphs are required, the browser may need both:

dashicons.css
+
dashicons font resource

Eliminating a genuinely unused icon system can therefore eliminate the related resources from the frontend path.

But measure before claiming a specific saving

Transfer size depends on:

• WordPress version;
• compression;
• browser cache;
• server configuration;
• CDN behavior.

Avoid universal claims such as:

removing Dashicons
always saves exactly X KB

How to perform a reliable Dashicons audit

Use several independent checks.

Step 1: test while logged out

Determine whether Dashicons is present for ordinary visitors.

Step 2: inspect the Network panel

Confirm whether dashicons.css is actually requested.

Step 3: inspect the rendered DOM

Search for:

dashicons
dashicons-before
dashicons-*

Step 4: inspect pseudo-elements

Look for CSS rules using:

font-family: dashicons

Step 5: search the complete active theme

Search both PHP and CSS.

Step 6: search the child and parent theme

Do not assume only one theme directory matters.

Step 7: inspect plugin code if required

Determine whether the dependency actually originates elsewhere.

Step 8: inspect WordPress’s style dependency graph

Use wp_style_is() and wp_styles() for deeper debugging.

Step 9: temporarily dequeue Dashicons on staging

Look for visual or functional regressions.

Step 10: test all major templates and states

Include mobile and interactive components.

A useful debugging snippet

During development, the following temporary code can help identify active styles that depend directly on Dashicons:

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

        if ( wp_style_is( 'dashicons', 'enqueued' ) ) {
            error_log( 'Dashicons is currently enqueued.' );
        }

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

What this snippet can tell you

It can reveal relationships such as:

Dashicons is currently enqueued.

admin-bar depends on Dashicons.

or:

Dashicons is currently enqueued.

my-theme-icons depends on Dashicons.

The second result provides much stronger evidence of a theme-level dependency.

What this snippet cannot tell you

It cannot prove that a visible icon was rendered.

A theme stylesheet may declare Dashicons as a dependency even though the current page does not actually use any associated icon.

Source inspection and visual testing remain necessary.

Do not leave diagnostic logging enabled permanently

Temporary logging is useful during an audit.

It should not remain indefinitely on production simply to answer a one-time asset question.

Safe guest-only removal example

If your audit confirms that no public-facing component requires Dashicons, a common removal pattern is:

add_action(
    'wp_enqueue_scripts',
    function () {
        if ( ! is_user_logged_in() ) {
            wp_dequeue_style( 'dashicons' );
        }
    },
    100
);

Notice the condition:

! is_user_logged_in()

This preserves the stylesheet for authenticated users, where the WordPress toolbar and other administrative frontend features may require it.

Do not copy the snippet before doing the audit

The correct sequence is:

inspect
↓
identify owner
↓
verify usage
↓
remove on staging
↓
test
↓
deploy

not:

find optimization snippet
↓
paste
↓
hope icons survive

Dashicons audit checklist

• Test the frontend while logged out.
• Test separately while logged in.
• Check whether the admin toolbar is enabled.
• Inspect the Network panel for dashicons.css.
• Inspect page source for dashicons-css.
• Search the rendered DOM for dashicons classes.
• Inspect ::before and ::after pseudo-elements.
• Check computed font-family values.
• Search the entire active theme directory for dashicons.
• Search both parent and child themes.
• Search for wp_enqueue_style( 'dashicons' ).
• Search stylesheet dependency arrays for dashicons.
• Search CSS for font-family: dashicons.
• Check active plugin files if theme ownership is unclear.
• Use wp_style_is() to confirm queue state.
• Use wp_styles() to inspect dependencies.
• Remember that registered does not mean enqueued.
• Remember that enqueued does not necessarily mean visibly used.
• Test all major frontend templates.
• Test mobile navigation.
• Test dropdowns.
• Test modals.
• Test forms.
• Test account and checkout flows where relevant.
• Test hover and focus states.
• Test logged-in and logged-out states separately.
• Temporarily dequeue Dashicons only on staging.
• Watch for missing glyphs and empty squares.
• Clear caches before comparing results.
• Measure the actual network saving.

Related guides

• How to Remove Dashicons from the WordPress Front End
• Reducing WordPress Front-End Page Weight
• How to Remove Unused WordPress Scripts
• wp_enqueue_scripts Explained
• WordPress Staging Site Best Practices

Final recommendation

Do not decide whether Dashicons can be removed by checking only whether dashicons.min.css appears in the page source.

That proves only that the stylesheet was loaded.

The correct investigation separates three questions:

Is Dashicons registered?
↓
usually yes, by WordPress Core

Is Dashicons enqueued?
↓
check the current page

Is Dashicons actually used?
↓
inspect theme, plugins and rendered UI

Start with a logged-out visitor session because the WordPress admin toolbar can bring Dashicons into the frontend for authenticated users even when the public theme does not need it.

Then inspect the browser Network panel and DOM, search for Dashicon classes, inspect pseudo-elements and check computed font families.

Search the entire active theme, including both parent and child themes, for:

dashicons
wp_enqueue_style
font-family
stylesheet dependencies

If the origin is still unclear, inspect WordPress’s style queue with wp_style_is() and the dependency registry available through wp_styles().

Once the evidence indicates that logged-out visitors do not use the icon font, temporarily dequeue it on staging and test every important template, responsive state and interaction.

If nothing breaks, guest-only removal is often safer than removing Dashicons universally because authenticated frontend interfaces can still rely on it.

If your theme genuinely uses only one or two Dashicons, consider replacing those icons with lightweight inline SVGs and eliminating the dependency altogether.

And keep the optimization in proportion.

Dashicons is worth removing when it is genuinely unused, but eliminating a small icon system while ignoring oversized images, several external video players or large JavaScript bundles is unlikely to transform the site.

The useful rule is:

loaded
does not mean
needed

registered
does not mean
loaded

and one successful homepage test
does not mean
safe everywhere