DEV Community: Svg/icons

From Icon Search to React Components: Building a Reusable Icon Collection

Svg/icons — Thu, 08 Oct 2026 22:15:54 +0000

Finding an SVG icon is easy. Keeping a consistent set of icons across an evolving React application takes a little more planning.

Consider a dashboard with navigation, billing, notifications, and account settings. Each screen needs icons, but downloading them one by one quickly leads to a folder of unrelated assets.

A more practical approach is to build a collection specifically for the project.

1. Create a collection for your UI

On SVGicons, you can create a named Icon Collection and add icons directly from search results or individual icon pages.

For a dashboard, you might create a collection called Dashboard Navigation and select icons for:

Home
Analytics
Billing
Notifications
Settings

The collection preserves the original icon references, including their source sets and license information.

You can also reorder icons, remove unused entries, and review which icon families are represented.

2. Choose how your icons behave

Before exporting, two settings are particularly useful.

Color policy

For a typical React interface, currentColor allows compatible icons to inherit their color from CSS.

That means a navigation icon can follow the color of its surrounding UI without requiring a separate colored SVG file.

SVGicons also supports preserve for original colors and strip for workflows that require normalized paint attributes.

Naming policy

You can choose consistent naming conventions, including kebab, camel, and pascal.

For React components, PascalCase is a natural choice: ArrowLeft, CreditCard, or Settings.

3. Export components instead of converting every SVG

Once the collection is ready, SVGicons can generate an archive containing React TypeScript components.

Depending on the selected export options, the archive can also contain:

Individual SVG files and an SVG sprite
JSON metadata and license manifests
Vue, Svelte, Solid, or Blade components
Storybook galleries and npm package scaffolds

This avoids manually converting every selected SVG into a frontend component.

The exported files can then be added to your project and managed alongside your application code.

4. Keep the collection as your UI evolves

A dashboard rarely stays unchanged.

When a new feature needs an icon, you can return to the collection, review the existing visual style, and add another selection.

SVGicons also provides a VS Code extension that lets Pro users access collections and add icons directly from the editor.

The collection remains available for future exports, while the generated files live in your project.

A small detail worth checking

Before shipping, review the collection's icon sets and license summary. Grouping icons into one archive does not automatically make their licenses identical.

Creating and organizing collections is free with a Member account. Adding icons and exporting collections use Pro credits, and free Member accounts include 15 credits to explore the workflow.

Final thought

A reusable icon collection is not just a convenient way to download multiple SVG files.

It gives your project a defined selection of icons, consistent export settings, and a practical route from visual selection to frontend components.

Explore SVGicons Project Kits.

SVG 2 in 2026: What Icon Designers and Developers Should Know

Svg/icons — Thu, 08 Oct 2026 20:54:22 +0000

SVG has been part of web development for years. It's lightweight, scalable, and particularly well suited for icons and interface graphics.

On October 6, 2026, the W3C published an updated Candidate Recommendation Snapshot of SVG 2, bringing corrections and clarifications intended to improve interoperability, especially between web browsers.

It's a positive step for the SVG standard. But what does it actually mean for designers, developers, and icon libraries?

And does everyone need to change the way they work with SVG?

SVG 2 is evolving, not starting from scratch

SVG 2 builds on SVG 1.1, the specification behind many of the features developers already use today.

The goal isn't to reinvent vector graphics. It's to modernize the specification, clarify existing behavior, and improve integration with other web technologies.

The October 2026 publication continues that process.

A Candidate Recommendation Snapshot is an important milestone in the W3C standards process, but it isn't the same as a final Recommendation.

It also doesn't mean that every SVG 2 feature suddenly became available in every browser.

The specification defines how something should work. Browser implementations determine how reliably it works in practice.

That distinction matters when SVG graphics become part of a real application.

What's different in SVG 2?

Several changes introduced during the development of SVG 2 are particularly relevant to people working with icons and user interfaces.

These are broader developments since SVG 1.1, not features introduced specifically on October 6, 2026.

1. Closer integration with CSS

SVG 2 brings SVG geometry and styling closer to the CSS model.

For example, certain geometric attributes, including dimensions and positions, are defined as CSS geometry properties.

This makes it possible to control more aspects of SVG graphics through stylesheets, where supported.

For developers building adaptable interfaces, closer integration between SVG and CSS is a useful direction.

However, support for individual properties still needs to be checked before relying on them in production.

2. Modernized references

SVG 2 also modernizes how elements reference other resources.

For example, older SVG markup may contain:

<use xlink:href="#search-icon" />

Modern SVG markup can use:

<use href="#search-icon" />

The older xlink:href syntax is deprecated, although it remains recognized for backward compatibility.

This relatively small change illustrates how SVG continues to evolve alongside the rest of the web platform.

3. Clearer rules for reusable graphics

Reusability has always been one of SVG's strengths.

Elements such as <symbol> and <use> allow developers to define graphics once and reference them elsewhere.

SVG 2 refines the specification around reusable elements, including their sizing, styling, and rendering behavior.

For icon systems, these details matter because the same graphical asset may appear in many different contexts.

The goal is greater consistency, although actual behavior still depends on browser implementations.

What does this mean for icon libraries?

For most developers using SVG icons today, the immediate impact is limited.

Existing SVG files don't suddenly become obsolete because the specification has been updated.

Simple, well-structured SVG icons remain a practical choice for modern interfaces.

What matters most is still familiar:

Scalability: Icons should remain sharp at different sizes.
Styling: Colors and strokes should behave predictably.
Consistency: Icons should remain visually coherent across an interface.
Compatibility: SVG assets should render reliably in the environments where they're used.
Accessibility: Icons should be implemented appropriately, whether decorative or meaningful.

These requirements aren't new. But they remain just as important while the underlying standard evolves.

Should developers start using every SVG 2 feature?

Not necessarily.

A feature being defined in a specification doesn't automatically make it the best choice for every project.

Before adopting a newer SVG capability, it's worth asking a few practical questions.

Does it solve a real problem? Is it supported in the browsers your users rely on? Can the same result be achieved with a simpler, well-established approach?

For an icon library, predictability is often more valuable than using the newest available syntax.

There's little benefit in introducing additional complexity if it doesn't improve the final experience.

Developers interested in implementation progress can consult the Web Platform Tests results for SVG.

These results provide a useful starting point for understanding browser conformance, although application-specific testing remains important.

Looking ahead

The October 2026 update is a positive development for the SVG ecosystem.

It demonstrates that SVG is still being refined as part of the modern web platform, with ongoing attention to interoperability and implementation consistency.

For designers and developers, this is worth following even when there's no immediate need to change an existing workflow.

At SVGicons.com, we believe that simple, reliable, and easy-to-use SVG icons remain essential, regardless of how the specification evolves.

A more capable SVG standard is good news. But reliable rendering and predictable integration are what make SVG icons useful.

References

Published by SVGicons.com — SVG icons for designers and developers.

Why Icon Shape Still Matters

Svg/icons — Wed, 07 Oct 2026 12:59:51 +0000

Consistency is one of the foundations of a good icon system.

Icons should share proportions, stroke weight, optical balance, and visual language. When they belong to the same interface, they should feel like members of the same family.

But consistency can also remove information.

A recent discussion around increasingly standardized app icon shapes highlights an interesting design tradeoff: when every icon is placed inside the same outer shape, the silhouette stops helping us recognize it.

And that means the glyph inside has to work harder.

An icon is more than its glyph

When we think about an icon, we often focus on the symbol itself.

A magnifying glass means search.

A trash can means delete.

A gear suggests settings.

But recognition does not come from the internal symbol alone.

Several visual signals work together:

the outer silhouette
the internal glyph
color
negative space
proportions
visual weight
sometimes even texture or depth

The brain does not necessarily process these elements separately. It recognizes the whole object.

That makes silhouette surprisingly important.

A circle, star, shield, folder, cloud, or irregular outline can often be recognized before we consciously inspect what is inside it.

Standardization removes one recognition cue

Imagine six icons with completely different outer shapes.

Even in monochrome, their silhouettes already give us six distinct visual objects.

Now place those same concepts inside six identical rounded-square containers.

The layout becomes cleaner.

The icons align perfectly.

The interface feels more controlled.

But one layer of differentiation has disappeared.

The outer shape now communicates almost nothing because it is identical everywhere.

Recognition depends much more heavily on the internal glyph.

In other words:

The more standardized the container becomes, the more distinctive the symbol inside needs to be.

Consistency and recognizability are different goals

This is an important distinction for icon designers.

Consistency answers questions like:

Do these icons look like they belong together?
Do they use the same visual grammar?
Do they align correctly?
Do they have similar optical weight?

Recognizability asks something different:

Can users distinguish one icon from another quickly?
Can the icon still be identified at a glance?
Does it remain recognizable at small sizes?

A perfectly consistent icon set can still contain icons that are difficult to distinguish.

In fact, excessive standardization can sometimes make that problem worse.

If every icon uses the same container, stroke weight, corner radius, visual density, and construction rules, individual symbols may begin to look too similar.

Consistency reduces noise.

But some visual differences are useful information.

The glyph has to carry more meaning

When the silhouette is fixed, the internal glyph becomes more important.

That has practical consequences.

Small differences between symbols matter more.

Negative space matters more.

The overall mass of the glyph matters more.

And at small sizes, unnecessary detail becomes even more expensive.

Consider two icons that both use the same rounded-square container.

If their internal symbols are also similar, perhaps both using three horizontal lines with only small differences, users may need additional time to distinguish them.

But if one symbol has a strong diagonal structure and the other has a clear circular structure, recognition becomes much faster.

The container may be identical.

The internal visual signature is not.

This matters beyond app icons

The same principle applies to many interface systems.

Toolbar icons often share the same bounding box.

Sidebar icons usually occupy identical slots.

Design systems frequently enforce consistent icon dimensions.

Component libraries normalize padding and alignment.

All of that is useful.

But once the external geometry becomes standardized, differentiation must happen inside that structure.

This is especially important for large icon libraries.

As the number of icons grows, designers cannot rely only on aesthetic consistency.

They also need sufficient visual distance between related symbols.

For example:

import vs export
upload vs download
duplicate vs copy
expand vs maximize
archive vs inbox
refresh vs sync

These concepts are already semantically close.

If their silhouettes, proportions, and internal constructions are also too similar, recognition becomes harder.

A useful design question

When reviewing an icon set, we often ask:

Does this icon fit the visual system?

It may be useful to add another question:

If every surrounding visual cue disappeared, would this symbol still be easy to recognize?

Or more specifically:

If the container shape were identical for every icon, would the glyph still be distinctive enough?

That question changes how we evaluate icons.

It pushes us to think not only about visual consistency, but also about information density and recognition.

Consistency should support meaning, not erase it

Standardization is not the enemy of good icon design.

Without shared rules, icon sets quickly become chaotic.

But the goal of those rules should be to create a coherent visual language without eliminating the differences users rely on.

An icon system has to balance two forces:

Consistency helps users understand that icons belong together.

Distinctiveness helps users understand that they mean different things.

Good icon design needs both.

When the outer shape becomes standardized, the responsibility simply moves inward.

The glyph has to work harder.

When SVG Optimization Fails, Your Pipeline Shouldn’t

Svg/icons — Tue, 06 Oct 2026 15:22:00 +0000

SVG optimization is usually treated as a simple step in an asset pipeline.

An SVG comes in.

An optimizer removes unnecessary data.

A smaller SVG comes out.

But real-world SVG files are not always simple.

They may contain embedded styles, unusual selectors, metadata, generated markup, accessibility attributes, or constructs that an optimizer does not fully understand.

When that happens, an important question appears:

Should an optimization failure make the asset itself fail?

In many pipelines, the answer is effectively yes.

It probably shouldn’t be.

Optimization and validity are different questions

Consider four operations that are often mixed together:

PARSE → OPTIMIZE → VALIDATE → RENDER TEST

They may happen one after another, but they answer very different questions.

Parse

Can the system read the SVG structure?

If parsing fails, the document may genuinely be malformed or unsupported.

Optimize

Can parts of the document be simplified or removed safely?

This is a transformation.

Failure here does not necessarily mean anything is wrong with the original asset.

Validate

Does the SVG satisfy the rules required by the application or project?

For example:

required viewBox
forbidden external resources
naming conventions
accessibility requirements
maximum dimensions

Those are project constraints, not optimization rules.

Render test

Does the SVG actually produce the expected visual result?

This can reveal problems that neither parsing nor structural validation can detect.

These four stages should not be treated as interchangeable.

A recent SVGO example

A recent SVGO issue illustrates the distinction.

An SVG containing CSS pseudo-element selectors such as:

.icon::before { content: ""; }

can currently cause the default optimization process to throw an error because part of the internal CSS processing does not support those selectors.

The interesting part is not whether pseudo-elements are common inside SVG files.

The interesting part is what the failure means.

The SVG can still be parseable.

It may still be renderable.

It may still satisfy every requirement of the application using it.

Yet the optimization stage cannot process one part of its stylesheet.

That is an optimizer limitation, not automatically an asset failure.

Related issue:

https://github.com/svg/svgo/issues/2308

The failure state matters

Automated pipelines often reduce everything to two states:

SUCCESS

FAILURE

But asset processing usually needs more nuance.

A better model could be:

Parsed successfully
Optimization skipped or partially completed
Validation passed
Render test passed

The asset can then continue through the pipeline while the optimization warning is recorded separately.

For many systems, this is more useful than rejecting the file completely.

Optimizers should be conservative transformers

An optimizer performs transformations.

That means its safest behavior when encountering something it cannot confidently transform is often:

leave it unchanged.

This is very different from silently rewriting unfamiliar syntax.

A conservative optimizer can effectively say:

I cannot safely optimize this rule, so I will preserve it.

The rest of the SVG may still contain dozens of optimizations that can be performed safely.

This creates a useful engineering boundary:

Unknown syntax → Preserve → Continue processing

instead of:

Unknown syntax → Reject entire asset

The second behavior can make automated workflows unnecessarily fragile.

Pipelines should preserve the reason for failure

There is another important consequence.

When a build system reports:

SVG FAILED

the developer has very little information.

Was the XML invalid?

Did optimization fail?

Did validation reject the file?

Did the renderer produce a broken result?

Those are completely different problems.

A better pipeline exposes the actual stage:

PARSE ✓
OPTIMIZE ⚠ Unsupported CSS selector
VALIDATE ✓
RENDER ✓

Now the developer knows that the asset works, but one optimization could not be applied.

That distinction becomes increasingly important as asset pipelines grow more automated.

Treat optimization as an enhancement

The simplest design principle is this:

Optimization should usually improve a valid asset, not define whether the asset is valid.

There are exceptions.

A team may deliberately require every SVG to pass a particular optimizer before deployment.

That can be a perfectly valid project policy.

But it should be an explicit policy.

It should not happen accidentally because one transformation tool became the de facto validator for the entire pipeline.

For SVG workflows, keeping responsibilities separate produces clearer failures, safer transformations, and pipelines that are much easier to debug.

Parse → Optimize → Validate → Render test

Four stages.

Four different responsibilities.

And an optimization failure does not always mean the SVG has failed.

Your Empty Icon Searches Are Product Data

Svg/icons — Mon, 05 Oct 2026 17:30:08 +0000

An icon search returns nothing.

The obvious conclusion is:

We don't have that icon.

In a small library, that may be true.

In a search engine spanning hundreds of icon sets, it becomes much less obvious.

The icon may already exist several times.

One set may call it settings.

Another may call it sliders.

Another may use tune.

A fourth may describe it as configuration.

The concept exists.

The catalog simply failed to connect the user's language with the vocabulary used by its sources.

That makes an empty search more than a disappointing result.

It can be evidence that the aggregation layer failed.

Multi-set search creates a different problem

Searching one icon set is relatively simple.

The search vocabulary and the icon vocabulary usually come from the same source.

Aggregating many sets changes that.

Consider a user searching for:

preferences

The catalog might contain:

Set A → settings
Set B → sliders
Set C → tune
Set D → configuration

There is no shortage of relevant icons.

There is a shortage of agreement.

That distinction matters.

If the system treats every zero-result search as missing content, the natural reaction is to add more icons.

But adding a fifth representation of the same concept does not solve the real problem.

The catalog already had the answer.

The search layer couldn't retrieve it.

Zero results need a diagnosis

A failed search can come from several different causes.

For an aggregated icon catalog, a useful classification might look like this:

ZERO RESULT
   │
   ├─ SOURCE VOCABULARY GAP
   │
   ├─ AGGREGATION GAP
   │
   ├─ FILTER GAP
   │
   ├─ LOCALE GAP
   │
   └─ COVERAGE GAP

These failures look identical to the user.

They are not identical to the product.

Source vocabulary gap

Suppose a collection contains an icon named:

receipt

but the user searches for:

bill

The source itself does not expose the terminology the user chose.

That is a vocabulary mismatch.

It does not necessarily require changing the original asset or canonical identifier.

The search layer can preserve the source name while learning additional ways to retrieve it.

Aggregation gap

This is more interesting.

Suppose several sets contain relevant concepts:

settings
sliders
adjustments
tune
configuration

but none of them appear for:

preferences

Individually, each source may be perfectly reasonable.

The problem appears only when they are combined.

A multi-set search engine has an opportunity that the original collections did not have:

it can build a layer above their differences.

That layer can learn that multiple upstream names may express the same user intent.

This is not simply better tagging.

It is part of the value of aggregation.

Filter gap

Search failures are also contextual.

Consider:

wind turbine

The catalog contains several matching icons.

But the user has selected:

Style: Filled
License: MIT
Set: Collection X

and none of the matching results survive those filters.

The query itself worked.

The catalog coverage was sufficient.

The search context removed the answer.

So logging only:

"wind turbine" → 0 results

throws away important information.

A useful failed-search record should preserve the context that produced the failure.

For example:

query
filters
selected sets
locale
result count

Otherwise, the team may spend time fixing something that was never a search problem.

Locale gap

Icon terminology also changes between languages, regions and professional contexts.

Even in English, users may describe the same concept differently.

A designer, developer and accountant may not search for the same icon using the same words.

A large catalog amplifies this because its upstream sources were often created by different teams, for different audiences, using different naming conventions.

Again, the underlying asset can already exist.

The retrieval vocabulary may simply be incomplete.

Coverage gap

And then there are genuine gaps.

Suppose users repeatedly search for:

quantum chip

There is no convincing equivalent under another name.

No filter is hiding it.

No related concept is already represented.

Then the diagnosis is different.

This time, the catalog really may be missing something.

Adding new content becomes justified.

The key is that content expansion comes after diagnosis, not before it.

A large catalog should not confuse quantity with coverage

This becomes increasingly important as an icon catalog grows.

A catalog with 300,000 icons can still fail a simple search.

Not because it lacks visual assets.

Because the assets came from many independent vocabularies.

More content can even make the problem harder.

Each new source may introduce:

new names
new categories
new style labels
new abbreviations
new terminology
new metadata conventions

So the search challenge changes as the catalog expands.

At some point, growth is no longer only about collecting more icons.

It is about making heterogeneous collections behave like one coherent search space.

Do not count queries. Group intent.

There is another trap.

Consider these failed searches:

dark mode
darkmode
night theme
dark theme
theme dark
night UI

Counting them as six unrelated failures would miss the interesting part.

They may all express one intent.

That means the useful signal is often not:

How many times did this exact string fail?

but:

How many users were trying to express this concept?

This changes prioritization dramatically.

One unusual query repeated twice may not matter.

Twenty different phrasings around the same missing concept probably do.

For search quality, intent clusters can matter more than exact query counts.

Keep the failed queries

Once a search problem has been identified, the obvious next step is to fix it.

But there is another useful step:

keep the query that exposed it.

Suppose this failed yesterday:

preferences → 0 results

You improve the search layer.

Now it returns:

settings
sliders
adjustments
tune

Do not throw away the original failure.

It has become a test case.

The same applies to:

dark mode
bill
night theme
wind turbine

Every meaningful failure can become part of a small regression set.

Yesterday's failures can become tomorrow's tests

This creates a simple loop:

OBSERVE
   ↓
DIAGNOSE
   ↓
FIX
   ↓
KEEP THE QUERY
   ↓
REPLAY
   ↓
MEASURE

After changing:

ranking
metadata
aliases
filters
indexing
normalization

replay previous failed searches.

Then ask:

Did this query start returning useful results?
Did another query get worse?
Did ranking improve?
Did a filter still hide the expected result?

Now zero-result analytics are doing more than generating product ideas.

They are contributing to search regression testing.

That is a useful shift.

A query that once demonstrated a problem can later verify that the problem stays fixed.

Search quality becomes cumulative

Without this loop, search improvements can be difficult to measure.

You fix one vocabulary problem.

Then another.

Then change ranking.

Then import another 20 icon sets.

Months later, the same search may silently fail again.

A retained set of real failed queries gives the search engine memory.

For example:

FAILED SEARCH REGRESSION SET

preferences
dark mode
bill
wind turbine
download cloud
user settings
archive box

Run them again after meaningful search changes.

Not every query needs a perfect answer.

But important previously solved failures should not quietly return.

The search box becomes a sensor

There is a broader lesson here.

In a large aggregated catalog, the search box is not only a retrieval interface.

It is also a sensor.

It reveals where:

user language
     ≠
catalog language

and where:

aggregated data
     ≠
coherent search experience

Those mismatches are product information.

They tell you where the abstraction above the underlying icon sets is incomplete.

Sometimes the fix is an alias.

Sometimes it is metadata.

Sometimes it is normalization between sources.

Sometimes it is filter behavior.

Sometimes the icon really is missing.

The search failure alone cannot tell you which.

The diagnosis can.

The useful question is not how many searches failed

Zero-result rate is still useful.

It tells you that users sometimes reach a dead end.

But for a multi-set icon search engine, the more important question is:

Why did the search fail when the catalog may already contain the answer?

That is where empty searches become valuable.

Not because every failed query demands another icon.

But because every meaningful failure can reveal something about the distance between hundreds of independent icon sets and the single search experience built on top of them.

And once those failures are preserved and replayed, they become something else too:

tests for whether the search engine is actually getting better.

External SVGs May Finally Become Themeable: Meet CSS Linked Parameters

Svg/icons — Sat, 03 Oct 2026 17:02:41 +0000

SVG icons have always forced developers into a trade-off.

Keep the SVG inline and you get excellent control from CSS.

Load it as an external image and you get a clean, reusable asset — but most of that styling control disappears.

A new CSS feature called CSS Linked Parameters could narrow that gap.

The interesting part is not simply that an external SVG may become recolorable. It is that an SVG file could expose a small, explicit theming interface while remaining an external resource.

That changes how we can think about reusable icon assets.

The problem with external SVGs

Consider a simple icon:

<img src="/icons/notification.svg" alt="">

This is convenient.

The SVG lives in its own file, the markup stays small, and the browser can treat the icon like any other external image resource.

But there is a boundary.

CSS from the host page cannot normally reach inside that SVG and change its individual paths.

Something as natural as this does not solve the problem:

.notification {
  color: rebeccapurple;
}

If the icon contains hard-coded fills or strokes, changing color on the <img> element does not magically propagate into its internal SVG elements.

Inline SVG behaves very differently.

<svg class="notification" viewBox="0 0 24 24">
  <path fill="currentColor" d="..." />
</svg>

Now currentColor can participate directly in the surrounding page styles.

That makes inline SVG ideal for buttons, menus, states, themes and interactive UI.

But it also means the graphic becomes markup instead of remaining a standalone image asset.

CSS masks solve one important case

For monochrome icons, CSS masks already provide a very useful alternative.

.icon {
  width: 24px;
  height: 24px;

  background: currentColor;

  mask: url("/icons/search.svg") center / contain no-repeat;
}

The SVG provides the shape while CSS provides the visible color.

This works especially well for interface icons that should simply follow the text color.

But a mask reduces the SVG to a silhouette.

That is exactly what you want for many icons — and exactly what you do not want for an icon containing multiple meaningful colors.

Imagine a notification icon with a neutral bell and a red status badge.

A mask cannot independently theme both parts.

What if the external SVG exposed parameters?

This is where CSS Linked Parameters becomes interesting.

Instead of allowing the page to reach arbitrarily into the external SVG, the SVG itself can define values it is willing to receive.

For example, our external notification.svg could contain:

<svg
  xmlns="http://www.w3.org/2000/svg"
  viewBox="0 0 24 24"
>
  <path
    fill="env(--icon-primary, #1f2937)"
    d="..."
  />

  <circle
    cx="18"
    cy="6"
    r="4"
    fill="env(--icon-accent, #e11d48)"
  />
</svg>

There are two interesting pieces here:

env(--icon-primary, #1f2937)
env(--icon-accent, #e11d48)

The SVG defines two parameters it knows how to use.

It also defines fallback colors.

Without any values coming from the host page, the icon still has a complete visual appearance.

Now consider the HTML:

<img
  class="notification-icon"
  src="/icons/notification.svg"
  alt=""
>

The host page could supply values through link-parameters:

.notification-icon {
  --theme-icon-primary: #334155;
  --theme-icon-accent: #e11d48;

  link-parameters:
    param(--icon-primary, var(--theme-icon-primary)),
    param(--icon-accent, var(--theme-icon-accent));
}

The page chooses the values.

The SVG chooses what those values control.

That separation is important.

This is not CSS inheritance through a wall

It is tempting to describe this feature as making external SVGs behave like inline SVGs.

That is not quite the right mental model.

The parent page still does not suddenly gain unrestricted styling access to every path inside the external image.

Instead, the SVG exposes an explicit contract:

--icon-primary
--icon-accent

The document consuming the icon supplies values for that contract.

This is much closer to a component API than normal CSS inheritance.

And for reusable icon assets, that may actually be better.

The page should not need to know whether the red badge happens to be the third <path>, a <circle>, or part of a group.

It only needs to know:

This icon accepts an accent color.

The SVG remains responsible for its own structure.

Light and dark themes become more interesting

That contract could make an external icon respond to a design system without duplicating the SVG file.

For example:

.notification-icon {
  --theme-icon-primary: #334155;
  --theme-icon-accent: #dc2626;

  link-parameters:
    param(--icon-primary, var(--theme-icon-primary)),
    param(--icon-accent, var(--theme-icon-accent));
}

@media (prefers-color-scheme: dark) {
  .notification-icon {
    --theme-icon-primary: #e2e8f0;
    --theme-icon-accent: #fb7185;
  }
}

The SVG file itself does not change.

The URL does not need to switch between:

notification-light.svg
notification-dark.svg
notification-red.svg
notification-blue.svg

Instead, the asset describes its visual structure and the consuming page provides the theme values.

That is a subtle but useful shift.

Four different SVG strategies

CSS Linked Parameters would not make the existing approaches obsolete.

They solve different problems.

Approach	External asset	Page-controlled color	Multiple colors	Best fit
Inline SVG	No	Yes	Yes	Maximum styling and interaction
`<img>` today	Yes	Very limited	Fixed inside SVG	Stable image assets
CSS mask	Yes	Yes	No	Monochrome UI icons
Linked Parameters	Yes	Yes	Yes	Parameterized reusable assets

This is why the feature is interesting.

It does not introduce a universal “best way” to use SVG.

It potentially adds a missing fourth option.

Use inline SVG when

you need deep styling, animation, DOM access or individual element manipulation.

Use a CSS mask when

the icon is fundamentally monochrome and should follow currentColor.

Use a normal `<img>` when

the SVG should behave like a fixed image and does not need runtime customization.

Linked Parameters may eventually fit when

the SVG should remain external but expose a controlled set of visual choices.

That last category is something the platform has not handled particularly elegantly before.

Fallbacks matter

A parameterized icon should still be a valid icon when no parameter is provided.

That is why this:

env(--icon-accent, #e11d48)

is more robust than designing the SVG under the assumption that a host page will always configure it correctly.

The fallback is part of the asset.

A well-designed parameterized SVG could therefore have two layers:

Default visual identity
        +
Optional host customization

That makes the file useful both as an ordinary image and as a theme-aware asset.

This could change how icon libraries describe SVGs

Today an icon catalog typically exposes an SVG as a file or a block of markup.

But parameterized SVGs suggest another possibility.

An icon could eventually declare something like:

notification.svg

Parameters:
--icon-primary
--icon-accent

Another icon might expose:

--icon-fill
--icon-stroke

A larger illustration could expose:

--surface
--foreground
--highlight

At that point, an SVG is no longer just a graphic file.

It has a small public styling interface.

For an icon search engine or design system, that metadata could become useful: developers could know immediately whether an asset is fixed, monochrome-themeable, or fully parameterizable.

Don't ship your production icon system around this yet

CSS Linked Parameters is still experimental.

The specification is a work in progress, browser implementation is still evolving, and support is nowhere near a production baseline.

Firefox has an experimental implementation, and WebKit has also been actively implementing pieces of the specification.

That is encouraging.

It is not the same thing as broad browser support.

For production applications today, inline SVG, regular external SVGs and CSS masks remain the practical choices.

But Linked Parameters is worth watching because it targets a real limitation rather than inventing another SVG embedding technique.

The bigger idea

For years, choosing an SVG integration strategy has often meant deciding between two useful properties:

keep the graphic external

let the page control its appearance.

CSS masks found a clever compromise for monochrome graphics.

CSS Linked Parameters could eventually extend that idea to richer SVGs.

And perhaps the most interesting part is not dynamic recoloring itself.

It is the possibility of treating an SVG asset as something with a deliberate interface:

Here is the graphic.

Here are the parts you are allowed to theme.

Everything else remains encapsulated.

That feels less like styling an image.

It feels more like using a very small visual component.

And that could be a useful direction for SVG icons on the Web.

SVG Serialization Is a Security Boundary

Svg/icons — Fri, 02 Oct 2026 20:26:35 +0000

When an application generates an SVG, it is tempting to think of the result as an image.

But before it becomes pixels, SVG is structured markup.

That distinction matters whenever untrusted data is involved.

A recent vulnerability in Satori — which also affected the Node.js ImageResponse path in Next.js — provides a useful example of why SVG serialization should be treated as a security boundary.

What happened?

Satori converts HTML and JSX-like structures into SVG.

A security issue was discovered in the way certain values were escaped before being inserted into generated SVG output.

Under the right conditions, attacker-controlled values could be interpreted as SVG markup instead of remaining plain data.

The issue was fixed in Satori 0.33.5.

The interesting part is what can happen after that SVG is generated.

Next.js uses this rendering pipeline in the Node.js implementation of ImageResponse from next/og.

For affected Next.js 16 versions, applications passing attacker-controlled values into SVG content, attributes or styles could ultimately expose themselves to remote code execution.

The affected range for this specific advisory is:

Next.js >= 16.2.0 and < 16.3.6

The specific fix landed in Next.js 16.3.6.

Applications using the Edge implementation of ImageResponse, or applications that do not pass attacker-controlled values into SVG content, attributes or styles, are not affected by this issue.

Next.js subsequently published its September 2026 security release and recommends upgrading to the current patched releases rather than stopping at the first version containing this specific fix.

The interesting part is not Next.js

For an affected application, the immediate action is straightforward:

patch the dependency.

But there is a broader lesson here for anyone building systems that generate SVG.

Consider a simplified pipeline:

USER INPUT
    ↓
APPLICATION DATA
    ↓
SVG SERIALIZER
    ↓
<svg>...</svg>
    ↓
RENDERER / CONVERTER / BROWSER

One of the important trust boundaries sits here:

APPLICATION DATA
    ↓
[ ESCAPE / VALIDATE ]
    ↓
SVG SERIALIZER

Once application data becomes markup, the rules change.

A string that is harmless as application data may have a completely different meaning when inserted into an XML element, attribute, style declaration or another serialized structure.

This is not unique to SVG.

Developers already think this way about HTML generation, SQL queries, shell commands and templating systems.

SVG deserves the same mental model.

Generated SVG is not automatically trusted SVG

There is an easy assumption to make:

We generated the SVG ourselves, so it must be trusted.

But the application may control the SVG structure while an external user controls some of the values inserted into it.

For example:

<svg>
  <text>{userProvidedTitle}</text>
</svg>

The <svg> structure belongs to the application.

userProvidedTitle does not.

The serializer has to preserve that distinction.

If escaping fails, data may cross the boundary and become syntax.

That is the core issue.

Context matters after serialization too

There is another interesting lesson in this vulnerability.

The Satori advisory rates the escaping issue itself as moderate severity.

But the impact depends on what consumes the generated SVG afterward.

In the affected Next.js Node.js path, the consequences can become much more serious.

So a security review of an SVG pipeline should not stop at:

Can this library generate valid SVG?

It should also ask:

Where does the generated SVG go next?

A generated SVG might be:

sent directly to a browser;
rasterized into PNG;
passed to another parser;
converted by a native library;
cached by a server;
embedded into another document;
processed by an image-generation service.

The same serialization weakness can have very different consequences depending on the next component in the pipeline.

Three practical rules

For developers generating SVG dynamically, three rules are worth keeping in mind.

1. Treat serialization as a security boundary

Do not assume that values are safe simply because your application created the SVG structure.

Untrusted values remain untrusted until they have been correctly encoded for the context in which they are inserted.

2. Patch the whole pipeline

Knowing which library creates your SVG is not enough.

Track the components that parse, serialize, optimize, render and convert it.

A vulnerability can originate in one component and become significantly more serious because of what happens later in the pipeline.

3. Minimize what untrusted input can control

Where possible, avoid allowing external input to define arbitrary SVG markup, attributes or styles.

For many applications, external data only needs to control a limited set of values such as text, predefined colors or numeric dimensions.

Reducing that surface makes the pipeline easier to understand and easier to secure.

SVG is an image format — and markup

Developers often work with SVG alongside PNG, WebP or JPEG.

That can hide an important architectural difference.

Raster formats primarily describe pixels.

SVG describes a document.

And documents are parsed.

When SVG is generated dynamically, the transition from data to document syntax deserves the same attention we already give other serialization boundaries.

The recent Satori and Next.js vulnerabilities are specific bugs affecting specific versions.

They do not mean that dynamically generated SVG is inherently unsafe.

But they provide a useful reminder:

the moment untrusted data becomes SVG markup, serialization becomes part of your security model.

Sources

An Icon API Should Be Able to Say “RTL Behavior Unknown

Svg/icons — Thu, 01 Oct 2026 17:13:53 +0000

Right-to-left support creates an interesting problem for icon libraries.

Some icons clearly depend on reading direction. Others clearly do not. Some need a dedicated RTL drawing rather than a simple horizontal flip.

But there is another case that matters when you work with icons from many different sources:

What if nobody has documented the intended RTL behavior at all?

For an icon aggregator, that should be a valid state.

Not an invitation to guess.

RTL support is not just a rendering problem

It is tempting to treat right-to-left support as something that happens at the CSS layer.

For example:

[dir="rtl"] .icon {
  transform: scaleX(-1);
}

Technically, this flips the icon.

Semantically, however, it may be wrong.

An icon representing navigation may need to change direction.

A clock normally should not.

A list icon may need a different composition.

An icon containing letters or numbers may require a completely separate asset, because mirroring the SVG would also mirror its content.

So the real question is not:

Can this SVG be flipped?

It is:

Was this icon intended to change in an RTL interface?

Those are very different questions.

Some icon systems already encode this knowledge

This is not purely theoretical.

Microsoft's Fluent UI System Icons includes direction information in icon metadata. An icon can be marked as one that can be mirrored or one that has distinct RTL and LTR versions.

Source:

https://github.com/microsoft/fluentui-system-icons/blob/main/README.md

Wikimedia's Codex design system also documents that some icons should be mirrored, some should remain unchanged, and some require dedicated RTL assets.

For example, Codex treats icons representing horizontal direction or text differently from icons representing concepts such as time.

Source:

https://doc.wikimedia.org/codex/latest/style-guide/icons.html

The important lesson is not that every icon library must use the same rules.

It is almost the opposite.

Different icon systems may make different decisions.

The aggregator problem

Things become more complicated when an icon service contains assets from many independent icon sets.

Imagine four source libraries:

Set A → explicitly documents RTL behavior
Set B → provides separate LTR and RTL assets
Set C → contains directional icons but no metadata
Set D → says nothing about RTL

An aggregator cannot safely treat all four sources the same way.

It may know that an icon from Set A can be mirrored.

It may know that an icon from Set B has a dedicated RTL equivalent.

But with Set C or Set D, the correct behavior may simply be unknown.

That distinction should survive the import process.

Unknown is useful metadata

A directionality model for a multi-source icon library could expose states such as:

neutral
mirror
variant
unknown

Where:

neutral

means the same icon should normally be used in both directions.

mirror

means horizontal mirroring is explicitly supported.

variant

means a separate RTL asset exists.

And:

unknown

means the source does not provide enough information to make that decision safely.

unknown may look like incomplete data.

In reality, it is valuable data.

It tells developers:

We do not have an authoritative directionality decision for this icon.

That is much better than silently inventing one.

Absence of metadata is not permission

Consider an icon named:

arrow-turn-right

An automated importer could decide:

It contains "right", therefore it must be mirrored in RTL.

That sounds reasonable until naming describes geometry rather than semantic direction.

Or consider:

reply

Should it mirror?

Possibly.

But that decision may depend on how the source design system defines the metaphor.

The same problem appears with:

enter
exit
login
logout
forward
undo
redo
send

Names provide hints.

They do not provide authority.

A large icon platform should therefore distinguish between:

inferred behavior

and:

source-defined behavior

Ideally, automatic inference should never silently replace the latter.

Preserve provenance

Directionality becomes much more useful when combined with provenance.

Instead of returning only:

{
  "directionality": "mirror"
}

an API could eventually expose something closer to:

{
  "directionality": {
    "mode": "mirror",
    "source": "upstream"
  }
}

Or:

{
  "directionality": {
    "mode": "unknown",
    "source": null
  }
}

This makes an important distinction visible.

Did the original icon project specify this behavior?

Was it added by the aggregation platform?

Was it inferred?

Was it manually reviewed?

Once icon metadata is consumed automatically, provenance matters almost as much as the metadata itself.

Why this matters for APIs

Suppose an application requests:

GET /icons/back

Today, an icon API might simply return an SVG.

A direction-aware API could return:

{
  "name": "back",
  "svg": "...",
  "directionality": "mirror"
}

A different icon could return:

{
  "name": "document-numbered-list",
  "directionality": "variant",
  "variants": {
    "ltr": "...",
    "rtl": "..."
  }
}

And another:

{
  "name": "custom-arrow",
  "directionality": "unknown"
}

Now the consumer has enough information to make a deliberate decision.

Why this matters even more for coding agents

This becomes especially important when an AI agent is choosing assets.

Imagine asking:

Add a back action suitable for an Arabic interface.

Without metadata, the agent may:

search for a back icon,
retrieve an SVG,
notice that the interface is RTL,
decide by itself whether to mirror it.

That last step is where uncertainty is being hidden.

A better workflow would be:

search icon
→ retrieve directionality metadata
→ choose RTL behavior
→ generate implementation

And when the metadata says:

unknown

the agent should not silently pretend otherwise.

It could instead choose an icon with known RTL support or flag the decision for review.

For automated UI generation, this distinction matters.

CLI tools need the same information

The same idea applies outside an HTTP API.

A CLI could expose directionality during search:

svgicons search "back"

with results such as:

Back Arrow        mirror
Chevron Left      mirror
History Back      unknown
Navigation Back   variant

Or allow filtering:

svgicons search "back" --rtl-safe

An MCP tool could expose the same property to IDE agents.

Once this information exists as structured metadata, every interface can use it:

web search
API
CLI
React components
Vue components
MCP tools
coding agents
design system pipelines

Do not flatten upstream knowledge

An aggregator creates value by making many icon sets searchable through one interface.

But aggregation should not erase useful differences between those sets.

If a source library provides:

icon-x-ltr.svg
icon-x-rtl.svg

that relationship should ideally be preserved.

If another source explicitly says an icon can be mirrored, that should also be preserved.

And if a third source provides no information, that absence should remain visible.

Otherwise, aggregation can accidentally turn carefully designed behavior into guesswork.

A possible metadata model

A simple model might look like this:

{
  "directionality": {
    "status": "known",
    "behavior": "mirror",
    "provenance": "upstream"
  }
}

For a dedicated pair:

{
  "directionality": {
    "status": "known",
    "behavior": "variant",
    "provenance": "upstream",
    "ltr": "icon-id-ltr",
    "rtl": "icon-id-rtl"
  }
}

And when nothing reliable is known:

{
  "directionality": {
    "status": "unknown"
  }
}

The exact schema is less important than the principle:

uncertainty should be represented instead of hidden.

This is bigger than RTL

There is a broader lesson here for icon infrastructure.

Modern icon libraries increasingly feed automated systems.

SVG files are consumed by:

build tools,
component generators,
APIs,
IDE extensions,
design systems,
AI agents.

As this happens, an icon is no longer just vector geometry.

It increasingly needs machine-readable context.

Directionality is one example.

Others might include:

theme compatibility
semantic role
filled/outline relationship
deprecated aliases
accessibility guidance
brand restrictions
source provenance

Better metadata reduces the number of assumptions downstream tools need to make.

The safest default is sometimes “we don't know”

Developers usually prefer APIs that return precise answers.

But precision should not be manufactured.

For an icon platform aggregating many independent sources, there will always be metadata that exists for some sets and not for others.

RTL behavior is a good example.

When the upstream project provides the answer, preserve it.

When an explicit RTL variant exists, expose it.

When mirroring is documented, expose that too.

And when the information does not exist:

unknown

is a perfectly useful answer.

Because when a tool does not know whether an icon should change direction, the safest behavior is not to guess more confidently.

It is to preserve the uncertainty.

At SVGicons.com, we are interested in how icon metadata can make large multi-set libraries more useful to developers, APIs and automated workflows.

RTL directionality is a small detail visually.

But for machines choosing and transforming icons automatically, it is exactly the kind of detail that should not be left implicit.

AI Agents Need an Icon Contract

Svg/icons — Wed, 30 Sep 2026 16:43:23 +0000

AI coding agents are getting much better at finding assets.

Give an agent access to an icon library and it can search for settings, download, database, or user and return several usable SVGs in seconds.

That solves an important problem.

But it does not solve the whole problem.

An interface can contain individually good icons and still feel inconsistent.

The reason is simple:

Finding an icon is not the same as knowing which icon belongs in a project.

As agents take a larger role in generating interfaces, they need more than access to an icon catalog.

They need an icon contract.

Search solves discovery

The first generation of AI-assisted icon workflows naturally focused on search.

Instead of:

leaving the IDE,
opening an icon website,
searching manually,
downloading an SVG,
copying it into the project,

an agent can search the library directly.

That is already useful.

With APIs, CLIs, MCP servers, and other developer integrations, an agent can retrieve icons without interrupting the coding workflow.

But consider what happens after the search.

A query for settings may return dozens or hundreds of valid results.

Which one should the agent use?

The answer depends on the project.

A project contains rules that search cannot know

Two icons can represent the same concept while belonging to completely different visual systems.

One may be:

16px
filled
geometric
sharp

Another may be:

24px
outlined
rounded
2px stroke

Both are technically correct results for settings.

Only one may belong in the current interface.

The same problem exists at the implementation level.

Should the icon be inserted as:

<Settings />

or:

<svg>...</svg>

or loaded from a sprite?

Should the project use individual package imports?

Should SVGs inherit currentColor?

Should decorative icons use aria-hidden="true"?

None of those decisions can be answered by search alone.

They require project context.

The four layers of an icon contract

A useful way to think about this is to divide icon context into four layers.

1. Semantic rules

The first layer defines what visual metaphor the product uses for a concept.

For example:

settings       → gear
delete         → trash
external link  → arrow-up-right
notifications  → bell

This may look obvious, but products often develop their own vocabulary over time.

An agent should not replace an established metaphor just because another icon scored highly in search.

Semantic consistency matters too.

2. Visual rules

The next layer defines how icons should look.

For example:

family      → Project Outline
style       → outline
canvas      → 24 × 24
stroke      → 2px
line caps   → round
line joins  → round
color       → currentColor

This is the difference between using icons individually and using them as a system.

The agent should ideally search within those constraints instead of searching the entire catalog first and trying to fix inconsistencies later.

3. Implementation rules

Visual consistency is only half the problem.

The agent also needs to understand how the application consumes icons.

A React project might define:

framework      → React
icon format    → components
imports        → individual imports
default size   → 20
color          → inherited

A different project might prefer inline SVG.

Another might use Vue components, a sprite, raw SVG files, or generated TypeScript components.

An agent that knows these rules can produce code that fits the existing architecture instead of introducing a new icon pattern every time it touches the UI.

4. Policy rules

Finally, there are project rules that are neither visual nor technical.

For example:

allowed sources   → approved libraries only
license policy    → compatible with project distribution
accessibility     → decorative icons hidden from screen readers
provenance        → original source retained

These rules become increasingly important when agents can search across very large catalogs.

The easiest icon to retrieve is not necessarily the icon the project should use.

From icon search to icon selection

This changes the role of an icon service.

The basic workflow is:

query
↓
search results
↓
icon

A context-aware workflow looks more like this:

user intent
↓
project icon contract
↓
candidate search
↓
constraint filtering
↓
implementation
↓
consistent UI

Search still matters.

But it becomes one step inside a larger decision process.

That distinction matters because AI agents operate repeatedly.

A developer may ask an agent to build a toolbar today, a settings panel tomorrow, and a dashboard next week.

If each session starts from an empty context, the agent may make slightly different decisions every time.

Those differences accumulate.

The project should remember

A useful icon contract does not necessarily require a complex new standard.

It could simply be project-readable context.

For example:

icons:
  family: project-outline
  style: outline
  size: 24
  stroke: 2

implementation:
  framework: react
  format: component
  color: currentColor

semantics:
  settings: gear
  delete: trash
  external-link: arrow-up-right

policy:
  accessibility: required
  preserve-source: true

The exact syntax is not the important part.

The important part is that these decisions live with the project rather than inside one temporary prompt.

That gives future agents something stable to work from.

Why this matters for AI-generated interfaces

AI agents are moving from isolated code generation toward longer-running work inside real codebases.

That changes the problem.

When an agent creates one button, picking a reasonable icon may be enough.

When an agent contributes to hundreds of interface elements over weeks or months, local decisions need to follow global rules.

The same principle already exists elsewhere in software development.

Projects have:

formatting rules
linting rules
dependency policies
component conventions
design tokens
coding guidelines

Icons need similar context.

Not because icons are unusually complicated.

Because consistency is a project property, not a search result.

The next step for icon tooling

Large icon catalogs will remain useful.

Better search will remain useful.

Agent integrations will remain useful.

But the next useful layer may be the connection between the catalog and the rules of the project consuming it.

An agent should eventually be able to understand:

Find me an icon for this concept — but only one that belongs in this interface.

That is a much more interesting problem than retrieval alone.

Search finds candidates.

Project context decides what fits.

And as agents generate more of our interfaces, that context may become just as important as the icon catalog itself.

Animated Icons Need a Motion Contract

Svg/icons — Tue, 29 Sep 2026 22:02:19 +0000

Trigger, duration, looping, accessibility and reduced motion should travel with the asset.

An SVG icon is usually easy to describe.

It has a name.

A size.

A viewBox.

A style.

Maybe a stroke width, a category and a license.

But once that icon starts moving, those properties are no longer enough.

An animated icon does not only have an appearance.

It has behavior.

And behavior needs rules.

The SVG file is only part of the asset

Consider a download icon.

The same basic icon could be used in several completely different ways.

It could remain static:

download
└── static

It could animate briefly when the user starts a download:

download
└── interaction feedback
    ├── trigger: click
    ├── duration: 240ms
    └── loop: false

Or it could represent an operation that is still running:

download
└── progress
    ├── trigger: state-change
    ├── loop: while-pending
    └── semantic purpose: status

The geometry may be almost identical.

The integration contract is not.

That distinction matters when icons are distributed through libraries, APIs, component packages or automated development tools.

Motion has a trigger

An animation should not exist without knowing what starts it.

Typical triggers include:

page or component load
hover
keyboard focus
click or tap
application state change
explicit programmatic control

These are not interchangeable.

A hover animation may make sense as optional feedback on desktop, but not as the only way to expose information.

A loading animation should usually be controlled by application state rather than by pointer interaction.

An animation associated with keyboard focus should behave correctly for keyboard users rather than simply reproducing :hover.

So animated: true is not very useful metadata.

Something like this is more useful:

motion:
  trigger: interaction
  events:
    - hover
    - focus

Now the consumer knows something about how the asset is intended to behave.

One-shot and looping animations solve different problems

There is another important distinction: does the animation finish?

A short animation after an action can acknowledge that something happened.

A loop often communicates something different: activity, waiting, synchronization or an ongoing process.

Those behaviors should not be confused.

Imagine an icon rotating after the user presses a refresh button.

A single rotation could mean:

Your action was received.

Continuous rotation could mean:

Refresh is still in progress.

Same icon.

Very different semantics.

A useful motion description therefore needs to say whether the animation is:

loop: false

or perhaps:

loop: while-active

That information belongs closer to the asset than many current icon formats allow.

Duration is part of the component contract

Developers frequently customize animation duration after importing an icon.

But duration is not always merely decoration.

A very short movement may feel like interaction feedback.

A longer movement may communicate transition or progression.

An infinite animation creates an entirely different runtime behavior.

For reusable assets, it can therefore be useful to expose an intended duration:

duration: 240ms

This does not necessarily mean consumers must use exactly 240 milliseconds.

It means the asset communicates its intended behavior instead of forcing every implementation to reconstruct it from scratch.

The same applies to easing.

easing: ease-out

Again, the important idea is not that every icon library needs identical values.

The important idea is that motion properties can be part of the asset definition.

Motion should not carry important information alone

Animation can reinforce meaning.

It should be much more carefully treated when it becomes the only way to understand state.

Suppose a download icon animates while a file is being transferred and stops when the transfer completes.

If animation is the only indication of that state, removing the movement could also remove the information.

A better implementation might combine motion with another state change:

DOWNLOADING
animated arrow
+
accessible status
+
state change

COMPLETE
static check mark
+
accessible status

Font Awesome's accessibility documentation makes a similar practical point: animation should complement other indications of state rather than be the only indication.

That principle becomes particularly important when reduced-motion preferences enter the picture.

Reduced motion is not just `animation: none`

Browsers expose the user's motion preference through:

@media (prefers-reduced-motion: reduce) {
  /* reduced-motion behavior */
}

The W3C documents prefers-reduced-motion as a technique for preventing motion triggered by user interactions when appropriate.

But there is an important product-design question hidden behind that CSS rule:

What should replace the animation?

Sometimes the answer really is a static icon.

reducedMotion: static

Sometimes the movement can be reduced while preserving another visual transition.

reducedMotion: fade

And sometimes the animation communicates application state, in which case simply removing it may be insufficient.

For example:

motion:
  semanticPurpose: progress
  reducedMotion:
    animation: none
    fallback: explicit-status

The important part is that the fallback is intentional.

Reduced motion should not be an emergency patch applied after the asset has already shipped.

It should be part of its behavior definition.

Accessibility requirements are moving in this direction

This is also becoming more relevant from a standards perspective.

EN 301 549 V4.1.1, published in September 2026, updates the European accessibility standard for ICT and adopts WCAG 2.2 as its accessibility baseline. The revision also expands how user accessibility preferences are considered.

There is an important legal distinction: V4.1.1 has been published, but it has not yet replaced V3.2.1 as the harmonized reference used for presumption of conformity under the relevant EU legislation. That requires formal citation in the Official Journal of the European Union.

So the interesting takeaway for developers is not "a new law requires animated icons."

It does not.

The broader signal is that respecting user preferences is becoming increasingly explicit in accessibility practice.

Motion-aware components should be designed accordingly.

An animated icon needs a motion contract

This leads to a useful abstraction.

Instead of treating an animated icon as:

icon.svg

we could treat it as an asset plus a motion contract.

For example:

name: download
style: outline

motion:
  trigger: state-change
  duration: 240ms
  loop: false
  semanticPurpose: feedback

  reducedMotion:
    mode: static
    preserveState: true

formats:
  - svg
  - animated-svg
  - lottie

This is not a proposed standard.

It is simply a way of making implicit behavior explicit.

A production schema would probably need more detail: interruption behavior, easing, supported interaction modes, state mapping and runtime requirements could all matter.

But even a small contract already answers questions that the SVG geometry cannot answer.

Format also changes the runtime contract

An animated SVG, a Lottie animation and a video export may look similar on screen.

They are not equivalent assets.

An animated SVG may expose DOM elements that can be styled or controlled.

A Lottie file brings its own animation model and runtime.

WebM or MP4 is fundamentally media playback.

That means format is no longer just an export preference.

It can change:

runtime dependencies
styling possibilities
interaction control
accessibility implementation
reduced-motion handling
bundle and network cost

A catalog that offers animated assets should therefore describe not only what formats are available, but what those formats imply.

What should an icon catalog expose?

For static icons, common metadata might include:

name
category
style
viewBox
stroke/fill
license

For animated icons, I would add another layer:

motion
├── trigger
├── duration
├── easing
├── loop behavior
├── semantic purpose
├── reduced-motion behavior
└── available animation formats

Potentially also:

interaction
├── hover
├── focus
├── press
└── programmatic

This turns animation from a visual preview into something developers can actually reason about.

APIs should return behavior, not just files

This becomes even more important when assets are retrieved programmatically.

Imagine an icon API returning:

{
  "name": "download",
  "svg": "...",
  "animated": true
}

The client still knows almost nothing about how to use the animation.

Compare that with:

{
  "name": "download",
  "motion": {
    "trigger": "state-change",
    "durationMs": 240,
    "loop": false,
    "semanticPurpose": "feedback",
    "reducedMotion": "static"
  }
}

Now the result can be evaluated before the asset is inserted into an interface.

The same principle applies to a CLI.

And it becomes especially interesting for agent-based development.

Coding agents need these rules even more than humans do

A developer looking at an animated icon can usually infer some of its intended behavior.

An automated coding agent has a harder problem.

Suppose an agent receives the instruction:

Add an animated download icon to the toolbar.

Which asset should it choose?

Should the animation run continuously?

On hover?

When the download begins?

Should keyboard focus trigger it too?

What happens when the operating system requests reduced motion?

Without structured information, the agent has to guess.

With a motion contract, it can reason against explicit constraints.

For example:

Request:
"Show feedback when the user starts downloading."

Candidate A
trigger: hover
purpose: decorative

Candidate B
trigger: state-change
purpose: feedback
loop: false
reducedMotion: static

Candidate B matches the requested behavior for reasons that are machine-readable.

That is much safer than selecting an asset because its preview simply "looks appropriate."

The catalog becomes part of the design system

This is the larger consequence.

Once icons contain behavioral metadata, an icon catalog stops being only a repository of files.

It begins to describe part of the interface system.

The catalog can answer questions such as:

Which icons are suitable for interaction feedback?
Which animations loop?
Which require runtime support?
Which have static fallbacks?
Which respond to reduced-motion preferences?
Which animations communicate state?
Which formats are available for each environment?

Those answers are useful to developers.

They are even more useful to tools operating on behalf of developers.

A practical checklist

Before shipping an animated icon, ask:

Trigger

What starts the animation?
Does keyboard interaction receive equivalent behavior?
Can application state control it directly?

Timing

How long does it run?
Does it loop?
Can it be interrupted?

Meaning

Is the motion decorative, feedback, progress or state communication?
Would the interface still communicate correctly if movement disappeared?

Accessibility

What happens under prefers-reduced-motion?
Is there a static or reduced-motion alternative?
Is important state communicated by something other than motion?

Runtime

Is the asset animated SVG, CSS, JavaScript, Lottie or video?
Does it introduce a runtime dependency?
Can the application control its state?

Distribution

Can an API expose these properties?
Can a CLI inspect them?
Could a coding agent use them when selecting an asset?

If these questions cannot be answered, the animated icon may be visually complete but operationally underspecified.

The icon is not just what it looks like

Static icon systems taught us to treat properties such as size, stroke, style and licensing as structured information.

Motion introduces another dimension.

When an icon moves, developers need to know more than what the file contains.

They need to know why it moves, when it moves, how long it moves, whether it repeats, and what should happen when movement should be reduced.

That information should not have to be reverse-engineered from a preview.

An animated icon needs more than an SVG file.

It needs a motion contract.

The Price Tag Is Not the License

Svg/icons — Tue, 29 Sep 2026 16:23:42 +0000

Downloading an icon is easy.

Understanding what you are allowed to do with it six months later is much harder.

A developer finds an SVG, downloads it, optimizes it, renames the file and adds it to a repository.

The icon now looks like every other asset in the project.

What may no longer be visible is where it came from, under which license it was obtained, whether attribution is required, or whether redistribution is allowed.

That is the real problem.

The price of an asset does not describe its usage rights.

A $0 download tells you how much you paid.

It does not tell you what you can do with the file.

An SVG can lose its context very quickly

Imagine a typical workflow.

You download:

dashboard.svg
search.svg
settings.svg

Then you:

optimize the SVG
normalize its dimensions
change its color handling
rename it
move it into your application repository

A few weeks later, the files may look like this:

icons/
  analytics.svg
  search.svg
  preferences.svg

The graphics survived perfectly.

But the original context may not have.

Where did analytics.svg come from?

Which collection?

Which version?

Which license applied at the time?

Was attribution required?

Could the file be modified?

Could it be redistributed inside another downloadable product?

If the answers live only in someone's browser history, the workflow is fragile.

Free is a price condition, not a usage model

Developers often use words such as:

free icon

as if "free" described the asset itself.

It does not.

It describes one dimension of the transaction.

There are other questions that matter just as much:

Where did it come from?
What license applies?
Is attribution required?
Can it be modified?
Can it be redistributed?

Those questions become especially important when assets move between projects, teams and products.

An icon can be perfectly appropriate for one use case and require additional attention for another.

That is why a useful asset pipeline should preserve more than pixels and paths.

The asset should carry its usage context

A more robust way to think about an icon is:

icon
+ origin
+ license
+ obligations
+ permitted use

The SVG file is only one part of the asset.

The rest is metadata.

In practical terms, a project could retain information such as:

{
  "file": "analytics.svg",
  "collection": "example-icons",
  "source": "https://example.com/icons/analytics",
  "license": "Example License",
  "attribution": false,
  "modification": true,
  "redistribution": "check terms"
}

The exact format is less important than the principle.

The information should stay close to the asset.

Not in an old bookmark.

Not in a Slack message.

Not in the memory of the developer who originally downloaded it.

Modification should not break traceability

Icon workflows rarely keep source files untouched.

Developers optimize SVGs.

Designers adjust paths.

Build systems convert them into components.

Applications may generate sprites, symbol sets or framework-specific assets.

For example:

original SVG
    ↓
optimized SVG
    ↓
React component
    ↓
application bundle

The representation changes.

The provenance should not.

The same applies to usage information.

A transformed asset should still be traceable back to the conditions under which it entered the project.

Otherwise optimization becomes an accidental metadata deletion step.

Redistribution is where missing context becomes expensive

During development, an icon may simply appear inside an interface.

Later, the same project may become:

a reusable component library
a design system
a downloadable template
an SDK
a commercial application
an open-source repository

The asset has not necessarily changed.

The way it is distributed has.

At that point, knowing only that the icon was "free" is not very useful.

The team needs the original context.

This is why license information should be considered part of dependency management rather than something checked once during download.

Treat icons more like dependencies

Software teams already preserve metadata for code dependencies.

A package manager does not simply download files and forget where they came from.

Projects retain information such as:

package
version
source
license
dependency tree

Icon assets deserve a similar level of discipline.

Not because every icon workflow needs a complex compliance system.

But because provenance becomes much easier to maintain when it is captured at the moment the asset enters the project.

The best time to record usage rights is not six months later.

It is during acquisition.

A simple rule for icon pipelines

Before an icon becomes part of a project, capture at least:

SOURCE
LICENSE
ATTRIBUTION
MODIFICATION
REDISTRIBUTION

Then keep that information with the asset or with the project's asset manifest.

The workflow becomes:

discover
   ↓
verify
   ↓
record
   ↓
transform
   ↓
ship

instead of:

download
   ↓
forget
   ↓
investigate later

That small change makes future decisions much easier.

The useful question is not "Is this icon free?"

A better question is:

Do we still know what we are allowed to do with this asset?

That question remains useful long after the download button has disappeared.

Good asset pipelines preserve more than the file.

They preserve the information required to use the file responsibly.

Because the price tag is not the license.

And usage rights should travel with the asset.

Your SVG Has No Scripts. Is It Safe to Process?

Svg/icons — Fri, 25 Sep 2026 14:37:10 +0000

An application accepts an SVG icon, removes scripts and event handlers, then generates a preview. Has it made the file safe?

It has addressed one category of risk. The next question is what happens inside the software that reads and renders the file.

Two recent vulnerability reports show why that distinction matters for developers building icon importers, asset pipelines and preview services.

Two bugs that do not need JavaScript

In librsvg, CVE-2026-96889 concerns nested XML inclusions with duplicate entity declarations. During processing, an XML entity could be freed while the parser was still using it: a use-after-free error.

The RustSec advisory, issued on September 23, 2026, lists fixes in versions 2.63.2 and 2.62.4 for the respective release branches.

The NanoSVG report describes a different failure. Extreme arc radius values can make an intermediate calculation produce NaN — “not a number.” Converting that value to an integer without checking it introduces undefined behavior.

The report demonstrates the problem with a runtime sanitizer; the associated CVE, CVE-2026-88366, describes a potential denial of service.

Neither mechanism requires JavaScript.

These are issues in specific implementations and versions. They do not establish that every SVG renderer is vulnerable. They do show why “contains no scripts” is an incomplete security test.

The file passes through more than one component

Consider a typical icon upload feature. Before an icon reaches the interface, it might pass through an XML parser, a sanitizer, an optimizer and a rasterizer that creates thumbnails.

Each component processes input supplied by someone else.

Even the sanitizer has to read the original file. A later filter cannot protect an earlier component that has already encountered a malicious input.

For teams handling untrusted SVGs, four layers deserve attention.

1. Sanitize for the intended use

Define which elements, attributes and references your application needs.

A static icon usually requires a smaller feature set than an interactive SVG document. Use a maintained sanitizer with an explicit policy.

Sanitization remains useful, but its output should not be treated as proof that every downstream parser can safely process the file.

2. Track and patch the actual dependencies

Identify what parses and renders SVGs in your deployed application, including libraries bundled inside converters or image-processing tools.

Check affected versions and available fixes. Updating your own code does not necessarily update the library inside a thumbnail generator or conversion service.

3. Bound the work

Set limits on upload size, rendering dimensions, execution time and memory.

A small file is not necessarily cheap to process. Complex geometry or other expensive input can demand more work than its file size suggests.

Limits help contain excessive resource consumption; they do not repair memory-safety bugs.

4. Isolate untrusted processing

Where practical, run conversion and preview generation in a restricted worker with minimal permissions and no unnecessary network or filesystem access.

Design the application to handle a failed worker without taking down the main service.

Apply these protections from the first component that reads untrusted input, including sanitization.

Ask what happens when processing fails

These layers address different failure modes:

Sanitization restricts content.
Patches fix known defects.
Limits bound resource use.
Isolation reduces the consequences of a failure.

For an SVG icon pipeline, the useful question is broader than “Did we remove the scripts?”

Which components read this file, and what happens if one of them fails?

Sources:

DEV Community: Svg/icons

From Icon Search to React Components: Building a Reusable Icon Collection

1. Create a collection for your UI

2. Choose how your icons behave

3. Export components instead of converting every SVG

4. Keep the collection as your UI evolves

A small detail worth checking

Final thought

SVG 2 in 2026: What Icon Designers and Developers Should Know

SVG 2 is evolving, not starting from scratch

What's different in SVG 2?

1. Closer integration with CSS

2. Modernized references

3. Clearer rules for reusable graphics

What does this mean for icon libraries?

Should developers start using every SVG 2 feature?

Looking ahead

References

Why Icon Shape Still Matters

An icon is more than its glyph

Standardization removes one recognition cue

Consistency and recognizability are different goals

The glyph has to carry more meaning

This matters beyond app icons

A useful design question

Consistency should support meaning, not erase it

When SVG Optimization Fails, Your Pipeline Shouldn’t

Optimization and validity are different questions

Parse

Optimize

Validate

Render test

A recent SVGO example

The failure state matters

Optimizers should be conservative transformers

Pipelines should preserve the reason for failure

Treat optimization as an enhancement

Your Empty Icon Searches Are Product Data

Multi-set search creates a different problem

Zero results need a diagnosis

Source vocabulary gap

Aggregation gap

Filter gap

Locale gap

Coverage gap

A large catalog should not confuse quantity with coverage

Do not count queries. Group intent.

Keep the failed queries

Yesterday's failures can become tomorrow's tests

Search quality becomes cumulative

The search box becomes a sensor

The useful question is not how many searches failed

External SVGs May Finally Become Themeable: Meet CSS Linked Parameters

The problem with external SVGs

CSS masks solve one important case

What if the external SVG exposed parameters?

This is not CSS inheritance through a wall

Light and dark themes become more interesting

Four different SVG strategies

Use inline SVG when

Use a CSS mask when

Use a normal <img> when

Linked Parameters may eventually fit when

Fallbacks matter

This could change how icon libraries describe SVGs

Don't ship your production icon system around this yet

The bigger idea

Further reading

SVG Serialization Is a Security Boundary

What happened?

The interesting part is not Next.js

Generated SVG is not automatically trusted SVG

Context matters after serialization too

Three practical rules

1. Treat serialization as a security boundary

2. Patch the whole pipeline

3. Minimize what untrusted input can control

SVG is an image format — and markup

Sources

An Icon API Should Be Able to Say “RTL Behavior Unknown

Use a normal `<img>` when

Reduced motion is not just `animation: none`