Summary
When fetching Material Symbols Rounded from Google Fonts using the icon_names=... subsetting parameter with a large list of icons (~400 names), the resulting subset font renders glyphs at a different stroke / fill state than the un-subset full font, regardless of the font-variation-settings the consuming CSS specifies.
This appears to be a recurrence of the class of bugs already filed against icon_names subsetting, including:
I'm filing a separate report because the manifestation here is "wrong glyph weight / fill" rather than "icon missing," and triggers on a different icon list. Same underlying area of code, different symptom.
Versions involved
- Material Symbols Rounded internal Google Fonts version:
v344 → v345
- Bug observable starting on/around 2026-05-22 → 2026-06-02 (matches the public Material Symbols Changelog update window).
- The bug is in the subsetted font response. The un-subset (full) font fetched from
fonts.gstatic.com/s/materialsymbolsrounded/v345/... renders correctly at both v344 and v345.
Reproduction
Two minimal HTML files. Both request the same family, axes, and CSS — the only difference is the presence of &icon_names=.... Open both side by side in the same browser.
A — uses icon_names (broken)
<!doctype html><html><head><meta charset="utf-8"><title>A — subset</title>
<link rel="stylesheet" href="https://fonts.googleapis.com/css2?family=Material+Symbols+Rounded:opsz,wght,FILL,GRAD@24,300,0..1,0&icon_names=access_time,account_balance,account_balance_wallet,...HUNDREDS_OF_ICON_NAMES...,zoom_out_map&display=swap">
<style>
.btn{display:inline-grid;place-items:center;width:36px;height:36px;border-radius:999px;background:#234;color:#fff}
.icon{font-family:'Material Symbols Rounded';font-weight:normal;font-size:20px;line-height:1;
-webkit-font-feature-settings:'liga';-webkit-font-smoothing:antialiased;
font-variation-settings:'FILL' 0,'wght' 300,'GRAD' 0,'opsz' 24}
</style></head><body>
<span class="btn"><span class="icon">settings</span></span>
<span class="btn"><span class="icon">question_mark</span></span>
</body></html>The full icon list I used (alphabetical, ~400 names) is available [in this gist or PR / I can attach if useful]. A small two-icon list (just settings,question_mark) does not reproduce the bug — it requires a large icon set.
B — no icon_names (correct)
Same HTML as A, but the stylesheet link drops &icon_names=...:
<link rel="stylesheet" href="https://fonts.googleapis.com/css2?family=Material+Symbols+Rounded:opsz,wght,FILL,GRAD@24,300,0..1,0&display=swap">
Observed difference
The cog (settings) glyph in A renders with a noticeably thinner stroke / lower visual weight than in B, even though both ask for 'wght' 300, 'FILL' 0 and both ultimately resolve to the same family. The ? (question_mark) glyph is harder to distinguish visually.
The Network panel confirms different font paths:
- A:
fonts.gstatic.com/l/font?kit=…&v=v345 (size ~570 KB) — the "l" dynamic-subset path.
- B:
fonts.gstatic.com/s/materialsymbolsrounded/v345/... — the "s" canonical full-font path.
Direct font inspection (fontTools)
The subset font is structurally identical in shape between v344 and v345, just with +9 ligatures (matching the public changelog):
v344 woff2: 567,284 bytes, sha 7c18d84d96fa350ec33c2f4bc0080babd52a8785
cmap=31 chars, 4064 ligatures, features [rclt, rlig]
v345 woff2: 570,032 bytes, sha af3433aee2663cc9f14c65efdec9650e186e7c7c
cmap=31 chars, 4073 ligatures, features [rclt, rlig]
Both have the same OpenType table shape; what changed between v344 and v345 in the subsetted woff2 is the glyf / gvar / variation-axis data, in a way that interacts with our requested axes and produces wrong rendering.
Why this matters
This bug is shipping to production for any app that uses the documented icon_names subsetting parameter (recommended by your Material Symbols guide) with a sufficiently large icon list. The bug is non-deterministic-from-the-app's-perspective: a Google-side font version rollout can break a deployed product without any change in the app's repo. Build pipelines that inline Google Fonts CSS at build time (e.g. Angular CLI's optimization.fonts: true) bake the broken subset into the production artifact.
We've worked around it by removing icon_names from our font request and accepting the larger full-font payload. Self-hosting is our follow-up. But this should be a real fix on Google's side, given the documented icon_names feature is supposed to be safe.
What would help
- Acknowledgment of the bug.
- Either a fix in the
icon_names subsetter, or a documented disclaimer on the Material Symbols guide noting that the icon_names subset can render axes differently than the full font.
- Optionally: an opt-out parameter to force
font-variation-settings-honoring behavior in the subset.
Cross-references
Summary
When fetching Material Symbols Rounded from Google Fonts using the
icon_names=...subsetting parameter with a large list of icons (~400 names), the resulting subset font renders glyphs at a different stroke / fill state than the un-subset full font, regardless of thefont-variation-settingsthe consuming CSS specifies.This appears to be a recurrence of the class of bugs already filed against
icon_namessubsetting, including:I'm filing a separate report because the manifestation here is "wrong glyph weight / fill" rather than "icon missing," and triggers on a different icon list. Same underlying area of code, different symptom.
Versions involved
v344→v345fonts.gstatic.com/s/materialsymbolsrounded/v345/...renders correctly at both v344 and v345.Reproduction
Two minimal HTML files. Both request the same family, axes, and CSS — the only difference is the presence of
&icon_names=.... Open both side by side in the same browser.A — uses icon_names (broken)
The full icon list I used (alphabetical, ~400 names) is available [in this gist or PR / I can attach if useful]. A small two-icon list (just
settings,question_mark) does not reproduce the bug — it requires a large icon set.B — no icon_names (correct)
Same HTML as A, but the stylesheet link drops
&icon_names=...:Observed difference
The cog (
settings) glyph in A renders with a noticeably thinner stroke / lower visual weight than in B, even though both ask for'wght' 300, 'FILL' 0and both ultimately resolve to the same family. The?(question_mark) glyph is harder to distinguish visually.The Network panel confirms different font paths:
fonts.gstatic.com/l/font?kit=…&v=v345(size ~570 KB) — the "l" dynamic-subset path.fonts.gstatic.com/s/materialsymbolsrounded/v345/...— the "s" canonical full-font path.Direct font inspection (fontTools)
The subset font is structurally identical in shape between v344 and v345, just with +9 ligatures (matching the public changelog):
Both have the same OpenType table shape; what changed between v344 and v345 in the subsetted woff2 is the
glyf/gvar/ variation-axis data, in a way that interacts with our requested axes and produces wrong rendering.Why this matters
This bug is shipping to production for any app that uses the documented
icon_namessubsetting parameter (recommended by your Material Symbols guide) with a sufficiently large icon list. The bug is non-deterministic-from-the-app's-perspective: a Google-side font version rollout can break a deployed product without any change in the app's repo. Build pipelines that inline Google Fonts CSS at build time (e.g. Angular CLI'soptimization.fonts: true) bake the broken subset into the production artifact.We've worked around it by removing
icon_namesfrom our font request and accepting the larger full-font payload. Self-hosting is our follow-up. But this should be a real fix on Google's side, given the documentedicon_namesfeature is supposed to be safe.What would help
icon_namessubsetter, or a documented disclaimer on the Material Symbols guide noting that theicon_namessubset can render axes differently than the full font.font-variation-settings-honoring behavior in the subset.Cross-references