Icons: Redraw 64 icons to be stroke-based.

[jasmussen]

Part of #81274. Sibling PR to #78808, related to #78774.

What?

Updates 64 icon assets. It redraws 63 icons as stroke-based and refines the already stroke-based square icon. The batch focuses on arrow, line, alignment, and other utility icons.

It also updates consumers that colored these icons through fill. Built-in icons now follow CSS color, while Block Manager retains a fill fallback for third-party block icons that do not use currentColor.

Here's the updated icon map.

1. Green is the first 35 icons that landed.
2. Yellow is this PR.
3. Pink is the proposed next batch with few or no visual differences.
4. Blue contains icons with small visual updates, including font-based icons moving from fills to strokes.
5. Red contains icons that need more discussion or possible deprecation.

Why?

Stroke-based icons keep a consistent absolute stroke width at different icon sizes. The revised vectors also remove export artifacts and align related icons more consistently.

How?

• Uses stroke="currentColor" and vector-effect="non-scaling-stroke" for the converted icons.
• Updates CheckboxControl, ColorPalette, DataViews filters, welcome guides, and Block Manager to color stroke-based icons correctly.
• Keeps Block Manager compatible with custom block SVGs that do not use currentColor.
• Regenerates affected snapshots.

Testing Instructions

1. Run npm run storybook:dev and open Icons > Library.
2. Check the icons below at 16px, 24px, and 32px. They should remain visually consistent across sizes.
3. In the editor, verify checked and indeterminate CheckboxControls remain visible, including when disabled.
4. Select light and dark ColorPalette swatches. The selected checkmark should switch between black and white for contrast.
5. Open Block Manager. Built-in icons should use the intended gray, and a custom block icon without currentColor should retain the gray fill fallback.
6. Open the Edit Post, Edit Site, and Edit Widgets welcome guides. Their modal close icons should remain white in the styled states.
7. Verify DataViews filter reset and selected-option icons remain visible in their default, hover, focus, and selected states.

Icons: align-center, align-justify, align-left, align-none, align-right, arrow-down, arrow-down-left, arrow-down-right, arrow-left, arrow-right, arrow-up, arrow-up-left, arrow-up-right, block-meta, category, chart-bar, check, chevron-down, chevron-down-small, chevron-left, chevron-left-small, chevron-right, chevron-right-small, chevron-up, chevron-up-down, chevron-up-small, close, close-small, create, download, handle, home-button, justify-bottom, justify-center, justify-center-vertical, justify-left, justify-right, justify-space-between, justify-space-between-vertical, justify-stretch, justify-stretch-vertical, justify-top, line-dashed, line-dotted, line-solid, list-view, menu, next, plus, position-center, position-left, position-right, previous, pull-left, pull-right, pullquote, reset, resize-corner-ne, rss, separator, square, stretch-full-width, stretch-wide, upload.

Testing Instructions for Keyboard

There are no keyboard interaction changes. Repeat the editor checks with Tab, Shift+Tab, Enter, and Space. Focus order, activation, and visible focus should work as before.

Visual Preview

This existing screenshot records the separate Icon block CSS-specificity issue found during the work:

Use of AI Tools

Claude Opus 5 helped refine SVG geometry and audit CSS consumers. OpenAI Codex handled the rebase, review feedback, adversarial self-review, verification, and this description update.

[github-actions]

Flaky tests detected in 0ece777.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/33408891334
📝 Reported tests:

As a user I want to be able to add multiple close buttons so that users can close the overlay from different positions in /test/e2e/specs/site-editor/navigation-overlay-template-part.spec.js, passed after 1 failed attempt.

Error: expect(locator).toHaveCount(expected) failed

Locator:  getByRole('button', { name: 'Close' })
Expected: 2
Received: 1
Timeout:  5000ms

Call log:
  - Expect "toHaveCount" with timeout 5000ms
  - waiting for getByRole('button', { name: 'Close' })
    14 × locator resolved to 1 element
       - unexpected value "1"

    at /home/runner/work/gutenberg/gutenberg/test/e2e/specs/site-editor/navigation-overlay-template-part.spec.js:198:33

[jasmussen]

For those following along, noting that this PR is not ready for review and is blocked on #78808 landing first so it can be rebased, due to some stroke-based issues uncovered in #78808 (comment)

[simison]

Not sure if this PR is still relevant, but FYI a new icon:

• Icons: Add repeat all icon #79698

[jasmussen]

Following the merger of #78808, and continuing work on #81274, this PR has now been rebased.

This PR still contains a bunch of icons, notably a lot of alignment, justification, and arrow icons, now all stroke-based. With very few exceptions, all icons in this batch remain visualy identical to those shipping in trunk. The few exceptions are: "next" is now a perfect mirror of "previous", the trunk version was misaligned, and the "upload" and "download" icons notably had very off fractional coordinates, they are now rounded. I doubt anyone will notice the changes.

As I worked on this, and as you'll see in one of the commits, I discovered a new set of icons that were affected by parts of the codebase that set fill instead of color. I've fixed those areas—the most visible one being the CheckboxControl—and they are in their own commit. I expect this to be the part of the PR that will need the most feedback, and is the most substantial, as the other icons really just continue the work that was already started. Moving from using fill to using color nevertheless still feels like a code-quality step in the right direction.

That makes this PR ready for review. With no particular rush (would be nice to get all icons updated for 7.2, but also fine if we don't), I'd appreciate a look from @WordPress/gutenberg-design.

---

A few notes to be aware of:

• rss loses its dot in icon-registry contexts until Icons Registry: improve SVG sanitizer #75550 lands. Its dot is a <rect>, and the registry's wp_kses allowlist currently permits only svg, path and polygon, so the element is stripped.
• Forced-colors rules need a second look. Four places set fill: CanvasText under @media (forced-colors: active) (block-icon and its content.scss, Button, Placeholder, list-view). These are now redundant for library icons, all of which now inherit through currentColor. But BlockIcon renders third-party block icons, which are arbitrary SVGs that may carry hardcoded fills, worth pondering.

---

As for the overall next steps for this icon work, here's an updated map of icons:

1. Green was the first 35 icons to land. Few to no visual differences.
2. Yellow is this PR, another 65 icons to land. Few to no visual differences.
3. Pink is my the next PR I propose, a rather huge batch of icons but in all of them, few to no visual differences.
4. Blue is the last big batch of updates I'd propose. These are icons that have received slight visual updates.
5. Red are icons we need to talk about, consider for deprecation.

Expanding on 4 I will do in more depth when we get to that, but in all the cases the change have been discussed either in issues (such as improving the pagination icons), in some cases they are small stylistic changes to make them match the set better such as geometric curves in the "move to" icon rather than custom beziers, but notably these also include redesigns of most of the font-based icons, so that those move from fills to strokes.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: jasmussen <joen@git.wordpress.org>
Co-authored-by: ciampo <mciampini@git.wordpress.org>
Co-authored-by: mirka <0mirka00@git.wordpress.org>
Co-authored-by: simison <simison@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

Size Change: -1.49 kB (-0.02%)

Total Size: 7.91 MB

📦 View Changed

Filename	Size	Change
build/modules/boot/index.min.js	58 kB	-182 B (-0.31%)
build/modules/workflow/index.min.js	18.6 kB	-1 B (-0.01%)
build/scripts/block-editor/index.min.js	477 kB	-171 B (-0.04%)
build/scripts/block-library/index.min.js	370 kB	-71 B (-0.02%)
build/scripts/commands/index.min.js	19.9 kB	-14 B (-0.07%)
build/scripts/components/index.min.js	266 kB	-316 B (-0.12%)
build/scripts/customize-widgets/index.min.js	14.9 kB	-11 B (-0.07%)
build/scripts/edit-post/index.min.js	52.7 kB	-39 B (-0.07%)
build/scripts/edit-site/index.min.js	381 kB	-107 B (-0.03%)
build/scripts/edit-widgets/index.min.js	22.4 kB	-90 B (-0.4%)
build/scripts/editor/index.min.js	580 kB	-262 B (-0.05%)
build/scripts/format-library/index.min.js	39.5 kB	-13 B (-0.03%)
build/scripts/media-utils/index.min.js	199 kB	-157 B (-0.08%)
build/scripts/preferences/index.min.js	3.35 kB	-15 B (-0.45%)
build/styles/block-editor/style-rtl.css	20 kB	+3 B (+0.01%)
build/styles/block-editor/style-rtl.min.css	17.1 kB	+2 B (+0.01%)
build/styles/block-editor/style.css	20.1 kB	+3 B (+0.01%)
build/styles/block-editor/style.min.css	17.1 kB	+2 B (+0.01%)
build/styles/components/style-rtl.css	16.2 kB	-4 B (-0.02%)
build/styles/components/style-rtl.min.css	13.7 kB	-4 B (-0.03%)
build/styles/components/style.css	16.3 kB	-4 B (-0.02%)
build/styles/components/style.min.css	13.7 kB	-4 B (-0.03%)
build/styles/edit-post/style-rtl.min.css	1.97 kB	-2 B (-0.1%)
build/styles/edit-post/style.min.css	1.97 kB	-2 B (-0.1%)
build/styles/edit-site/style-rtl.css	21.7 kB	-8 B (-0.04%)
build/styles/edit-site/style-rtl.min.css	17.8 kB	-3 B (-0.02%)
build/styles/edit-site/style.css	21.7 kB	-8 B (-0.04%)
build/styles/edit-site/style.min.css	17.8 kB	-5 B (-0.03%)
build/styles/edit-widgets/style-rtl.css	5.06 kB	-2 B (-0.04%)
build/styles/edit-widgets/style-rtl.min.css	3.63 kB	-3 B (-0.08%)
build/styles/edit-widgets/style.css	5.06 kB	-2 B (-0.04%)
build/styles/edit-widgets/style.min.css	3.64 kB	-2 B (-0.05%)
build/styles/editor/style-rtl.min.css	27 kB	+4 B (+0.01%)
build/styles/editor/style.css	31.6 kB	-1 B (0%)
build/styles/editor/style.min.css	27 kB	+4 B (+0.01%)

_{compressed-size-action}

[ciampo]

To unblock this PR, I've removed both Search changes and the related changelog and description references. We can handle the conversion separately once we agree on the compatibility boundary and migration approach.

Given this, and @mirka 's previous review round, I believe we can approve and merge 🚀

---

Is there a way to know how big the impact is? Outside the Icon block and the editor itself, what's the back compat promise as far as these icons?
And absent including full copies of fill-based versions of these, is there any CSS/polyfill we can write that we can output with high specificity?

We'll need to look more into this, including any precedents regarding this type of breaking change (search is a public export and the Search block renders it on the front end).

We can't really do polyfills here, since the style (fill) that third-party consumers apply today will just stop working, since the new icon wouldn't have any filled shapes. Not sure if we can convert fill rules into strokes.

I will also note, there was already precedence for stroke icons. square has been a strokes-only icon for a while.

square shows that stroke-based icons are supported, but it does not necessarily make converting an existing fill-based icon compatible.

[jasmussen]

Thank you for the help. Before I move on to the next round, I wonder if we shouldn't settle that strategy first. What's the best way to make this happen?

[ciampo]

Before I move on to the next round, I wonder if we shouldn't settle that strategy first. What's the best way to make this happen?

For @wordpress/icons, we can follow the policy established in #78808 and migrate Search to a stroke-based icon, with the same dev note guidance.

The server-rendered Search block potentially needs a more careful rollout because existing sites receive the new SVG automatically. I tried searching on Veloria and found 12 WordPress.org themes (covering about 1,050 active installs) with CSS that directly conflicts with the change. The actual exposure is smaller because it only affects sites using the icon-button Search block in the matching context.

If we wanted to reduce the breakage, we could consider a gradual migration: a setting (on the block or, potentially even better, at the theme level) read by both editor and PHP renderer, to swith betwen the old fill-based or new stroke-based icon:

1. We would start with the fill-based option as default (and stroke as opt-in), add a note / warning of some sort
2. After some time (1/2 WP releases?) we could flip and switch to stroke as the default, and leave fill as an opt-out option
3. After some more time (another 1/2 WP releases?) we could remove the fill version entirely.

But I also admit I don't have as much knowledge/confidence in advising re. changes that involve public blocks. I'll ping a few folks with better expertise here (cc @WordPress/gutenberg-components @Mamaduka @t-hamano @andrewserong @aaronrobertshaw @ramonjd @tellthemachines )

[ramonjd]

What's the exact risk here? I'm not sure I follow - do the new icons (if implemented on blocks) represent a visual change to published sites? Or is the worst that can happen that themes silently lose whatever CSS overrides they've implemented to style icons?

If the latter, why not test in the themes we know about, ship the icon with whatever block tweaks it requires in Gutenberg, and write a note for theme authors on make blog? There are about six blocks to migrate?

Sorry, I don't want to simplify or trivalize the costs, just wondering if we've weighed the return on a multi-release opt-in verses ensuring that the icons are pulled from the same source in the editor + frontend.

In other words, just getting it in like #30180 seemed to do 😄

Sorry if I'm missing something!

[jasmussen]

Thanks for chiming in, and I agree finding out the impact is key. My confusion was whether this affected every icon, but it sounds like it's primarily the search icon. But to answer clearly:

do the new icons (if implemented on blocks) represent a visual change to published sites

The overwhelming majority, 80% plus, will be pixel-identical in the new stroke-based versions.

For the other 20% of icons, it sounds like they are used only in-editor, and here I will be proposing small visual changes. Not breaking: the overall shape and message is the same, but something that we will review and then merge if we agree it's an improvement. I'm speaking about all the blue icons in this screenshot.

So what's the exact risk? I did more digging, based on Marco's comment: it's about 6 icons are styled by themes on the frontend. It's mainly chevrons, the close button(s), and the search icon.

The main risk is that a theme might have the following CSS:

.wp-block-search__button svg { fill: #333 }

Since there's no longer a fill inside the icon, the icon will no longer receive the intended colour. Instead it will inherit its colour from the surrounding button, i.e. currentColor.

[ciampo]

Yes, that's the risk.

My honest opinion: it should be relatively low impact. It won't break sites. But also, I don't have experience with dealing with changes affecting blocks and the front-end of our sites, which is why I asked for extra opinions.

[jasmussen]

@henriqueiamarino @beafialho @iamtakashi my theme developer friends, with no rush and only if you have time, what are your instincts on this?

The context is: we are exploring new features for icons that improve the plumbing for future features. But one consequence that has, as we continue to work on it: you can no longer set the colour of an icon using fill: red;, now you have to do it using color: red;.

That means if you previously added something like:

.wp-block-search__button svg { fill: #333 }

This CSS will stop working, and instead of the icon being #333, the icon will now inherit its colour from the the color value of .wp-block-search__button svg { fill: #333 } (unless you update the CSS). So if the color of .wp-block-search__button was blue, the icon is now blue.

The question: how big of an impact do you perceive this change to have?

[simison]

I doubt we could simply remove the fill styling support at least in already inserted blocks just like that, even over one version WP as opt-in. We typically support public APIs for a very long time, and this has risk of breaking customer's sites frontend, not just dashboards.

For example, one of the sites (regional library of a city in Finland) using themes @ciampo highlighted uses the style and would look broken without it:

Can we keep old icon with fill support for already inserted blocks, and any newly inserted block just uses the new icon? It might make sense to move the legacy icon to be part of the block's code rather than icons package so that we don't need to maintain it there.

[jasmussen]

That actually touches on an important point. The icons in question—search, loupe, chevrons—that are used on the frontend are all part of the blocks frontend rendering piece. They happen to be the same as WordPress icons, because why not, but they don't have to be part of the set. Functionally they serve different needs, and can be on separate tracks. That's me both validating that I think it makes sense to move their SVG code and make it part of the block's code.

A longer term perspective is also to explore using the Icon Block for those particular pieces, so that it doesn't have to be locked to the built-in icon, but can benefit from third party icon sets registered.

[ciampo]

It might make sense to move the legacy icon to be part of the block's code rather than icons package so that we don't need to maintain it there.

From what I understand, the Search block already has two separate SVG definitions:

• @wordpress/icons provides search.svg, used by the block in the editor.
• The dynamic block’s PHP renderer contains its own inline SVG for the front end.

So the icon rendered in the front end is already a separate (identically looking) icon.

Can we keep old icon with fill support for already inserted blocks, and any newly inserted block just uses the new icon?

I may be wrong, but my understanding is that search is dynamically rendered, so existing and newly inserted blocks both receive whatever SVG the current PHP renderer emits. Distinguishing them would require a persisted attribute or version marker.

[ciampo]

We could update only the icon in @wordpress/icons and keep the PHP-rendered icon (the one shows on the front-end) still fill-based, but it would have some consequences:

• The Search block editor would @wordpress/icons in both on the React side (index.js and edit.jsx). It would show the stroke icon while the PHP renderer shows the fill icon. Theme CSS using fill could therefore work on the published page but not in the editor.
• Other JavaScript consumers of @wordpress/icons would receive the new icon. Any consumer styling search through fill would need to use color instead (as already applied for other icons)

We could even consider changing edit.jsx to use the same icon as in the PHP renderer (ie the fill based legacy version) so that block usage won't be affected neither in the editor, not in the frontend.

Is this a better compromise?

[jasmussen]

My mental model as of this comment is: think of them as different icons. One is the search icon part of the WordPress UX, we use it here:

The other is the search block loupe icon, and we use it here:

They are different icons, and that's okay. The latter could eventually be from the Icon Block, arguably should be. So divorcing those feels like a valid choice, even outside of any stroke-conversations.

Am I missing some nuance in the usage?

[jasmussen]

Realising also that it's weird we do this:

.commands-command-menu__header-search-icon:dir(ltr) {
    transform: scaleX(-1);
}

[ciampo]

We could update only the icon in @wordpress/icons and keep the PHP-rendered icon (the one shows on the front-end) still fill-based
[...]
We could even consider changing edit.jsx to use the same icon as in the PHP renderer (ie the fill based legacy version) so that block usage won't be affected neither in the editor, not in the frontend.

I'm about to open a PR to implement this approach.

[henriqueiamarino]

Hey @jasmussen, just chiming in with my two cents: the change from #fill to #color would not impact my themes, as I have been avoiding SVGs since they were not accepted without a plugin. I know folks from Theme 51 would use Safe SVG a lot, but not us on the Themes team.
With that, I endorse your work and decision here, and I’ll happily use the improved icons you are working on. 👊