WordPress Starts Replacing Dashicons With SVG Icons

🇹🇷 Türkçe: Bu yazının Türkçesini oku →

The little home icon next to the site title in your admin bar has been the same glyph since 2013. Every wp-admin screen you have ever loaded has drawn it from the same icon font called Dashicons. It is one of those pieces of the platform you stop noticing until somebody proposes replacing it, and then you realise every plugin you ship that added a menu item is quietly wired to it too.

That proposal is now on the table, and it is a good one. I have been through enough icon-font swaps — the web-font hype cycle, our own agency switch to inline SVGs about eight years ago — to recognise a change that is larger than it looks. On the surface: swap a font for some SVG markup, everybody’s admin bar looks a hair sharper. Underneath: WordPress finally stops asking assistive technology to guess what a Unicode private-use-area code point means. That is not cosmetic. That is the platform growing up in a corner it had been avoiding.

What is actually new

On September 4, 2026, WordPress design lead Joen Asmussen published Replacing Dashicons in the admin bar and menu on Make/Core. It formalises an effort that has been running in the background since June: retire the Dashicons icon font from the two most visible pieces of wp-admin — the top admin bar and the left-hand sidebar menu — and render every icon there as an inline SVG served by the new Icon API instead.

The mechanism is the wp_get_icon() function and its sibling registration helpers, shipped in WordPress 7.1 and documented in the Code Reference. Icons live in namespaced collections — core/plus, my-plugin/star — and are rendered server-side as sanitised SVG markup. The implementation on the admin surface is tracked in Trac ticket #65089 and lands in core PR #12270 by Fushar, which is currently in review against trunk.

The rationale in Asmussen’s post is the interesting part. Three concrete failures of the icon-font approach are called out, none of them theoretical:

• Icon fonts map glyphs to Unicode private-use-area code points. Those code points carry no semantic meaning, so screen readers announce them inconsistently — sometimes as garbage, sometimes as silence.
• Icon fonts break under Windows High Contrast Mode and CSS forced-colors. SVGs that use currentColor respect the user’s forced palette instead of vanishing.
• When a font file fails to load, users see confusing Unicode boxes. When an SVG fails to load, they see nothing — which is the correct failure mode.

The PR covers the full top bar (WordPress mark, menu toggle, multisite switcher, dashboard, appearance, edit, comments, updates, search, user) and the sidebar (Posts, Media, Links, Pages, Plugins, Tools, Settings, and the collapse toggle). The WordPress mark uses a 24px viewBox rather than the historic 22px because the @wordpress/icons library was drawn on that grid.

One architectural question is still on the table: what happens if a site or a plugin deregisters a core icon the admin bar depends on? Options being discussed include a file-path fallback for menu_icon, raw SVG string support, or a “built-in” icon collection that behaves like core post types and cannot be unregistered. That small decision will decide how graceful the failure mode is three years from now.

Why it matters for WordPress and WooCommerce people

If you ship plugins or themes, the number of admin icons you have wired up over the years using the dashicons-* class convention is larger than you remember. WooCommerce alone puts a shop bag in the admin bar and a whole cluster down the left rail. Every extension that adds a submenu with add_menu_page() passes a Dashicon name to that fourth argument. None of that breaks today — Dashicons is not being deprecated as a font — but the surface WordPress itself renders is moving to SVG, and the visual mismatch will become obvious to your clients before it becomes obvious to you.

The other side of it is accessibility, and I want to be careful not to sound preachy. Windows High Contrast Mode is used by people who need it to read a screen, not by curious developers in Chrome DevTools. If the admin bar disappears in forced-color mode because it was built with an icon font, that is not a niche bug — that is a client asking their assistant to open a WooCommerce order, and the assistant not being able to find the menu item. I have watched exactly that play out on an enterprise B2B store, and the client’s IT team quietly wrote off the entire admin experience for their accessibility-affected users. WordPress has been carrying that liability since 2013. Fixing it in core is overdue.

There is a small performance dividend too. Dashicons ship as a ~55 KB font file loaded on every wp-admin page. Inline SVGs served through wp_get_icon() are only the icons actually used, sanitised by wp_kses. Nobody will write a case study about it, but every ounce the admin loses compounds when a marketing team is opening thirty tabs on a laptop tethered to hotel wifi.

What I would do (or not do) about it

Three moves, in order.

First, take stock of your dashicons-* usage. Grep your plugin and theme repos for dashicons- and for 'dashicons-' passed to add_menu_page. Every hit is a place you will eventually want to point at wp_get_icon(). You do not need to do it today — the PR has not landed, Dashicons is not going away — but get the inventory in a text file before your first client asks why the WordPress logo suddenly looks crisper than your plugin’s icon.

Second, if you are writing anything new against WordPress 7.1 or later, register your icons through the Icon API from day one. The hands-on Icon Registration API guide on the Developer Blog has the pattern: register a collection under your plugin slug, register each icon with inline SVG using currentColor, render it with wp_get_icon( 'my-plugin/thing' ). Namespacing is what stops your icons from colliding with the ecosystem once it starts registering hundreds.

Third, if you run managed WordPress fleets, follow this PR to merge. When it lands, the visual change will prompt one round of tickets from clients who notice the logo looks slightly different. Get in front of it with a two-sentence internal note. That is a cheaper conversation than the one that starts with a ticket titled “the admin looks broken”.

What I would not do: rewrite every existing plugin icon this weekend. This is an additive migration, not a breaking one. The Dashicons font is not being pulled from core, third-party dashicons-* class usage keeps rendering, and the sensible move is to migrate opportunistically — whenever you are in a file for another reason, swap that one call. Rushing a fleet-wide sweep buys you nothing and multiplies the surface area of regressions you will spend the next month untangling.

Twenty years in, my favourite kind of WordPress change is one that fixes a foundational sharp edge quietly, without asking anybody to relearn anything. This is one of those. The admin looks the same, works better for the people who need it to, and gives extension developers a serious icon API to build against for the next decade.