Working with Icons in Large B2B Applications

Most often, icons are a working tool. They help users navigate complex interfaces, speed up information scanning, and reduce cognitive load. That is why the approach to icons in large applications must be systematic and pragmatic.

SVG or Icon Fonts

In practice, most modern SaaS design systems choose SVG. This is not accidental. SVG icons provide much broader capabilities for several reasons.

When data is transferred, only the icons that are actually needed at a given moment are sent. An icon font always contains the entire icon set, which makes its size significantly larger.

Loading fonts from third-party resources also has several drawbacks. First, it introduces an additional network request. Second, it creates a dependency on an external service.

SVG icons can support multicolor designs and gradients.

In reality, no large project relies exclusively on third-party icon sets such as Google Material Icons or Font Awesome. As a result, teams end up using at least two libraries. Maintaining and updating a custom icon font quickly becomes a separate task.

A common strategy is to take a third-party set as a base and gradually extend it with custom icons. In this case, it is critically important to follow unified rules: proportions, visual style, and stroke thickness. Users should not be able to distinguish which icons are external and which are created internally.

In mature design systems, an internal icon library becomes a separate artifact with versioning and documentation.

As a result, in complex interfaces where states, accessibility, and predictable behavior matter, SVG proves to be the more reliable choice.

Icon Construction Rules and Stroke Thickness

Within a design system, it is important to define the icon format at an early stage and avoid mixing approaches without a clear reason.

One of the most common sources of visual noise is inconsistent stroke thickness across icons. In large interfaces this becomes especially noticeable, because icons are used everywhere: in menus, tables, toolbars, and forms.

A good practice is to define a base stroke thickness for a standard icon size, for example 24×24 pixels. All other sizes are either scaled proportionally or provided as predefined variants.

It is important to decide in advance whether icons with different stroke thicknesses are allowed at different sizes. In many cases the answer is yes, but only when done intentionally.

For example, 16×16 icons may use slightly thinner strokes to avoid looking visually “filled”, while 32×32 icons may use thicker strokes to preserve visual weight. These rules should be documented and reflected in the source files.

Icon Sizes

In B2B SaaS products, a limited set of icon sizes is usually sufficient. Most commonly these are 16, 20, 24, and 32 pixels. Each size is tied to a specific context: tables, buttons, navigation, or headers.

It is important not only to define the sizes, but also to explain where each size should be used. This reduces arbitrary decisions and simplifies collaboration between designers and developers. When an icon is used inside a button, its size and spacing should be standardized rather than manually adjusted each time.

Colors and States

In a design system, icon color is usually not a property of the icon itself. It is defined by context. Base color, active state, hover, and disabled states are controlled through tokens and inherited from components.

It is important to separate, both visually and technically, non-interactive informational icons from functional ones. Visually, this can be achieved through color. Technically, interactive icons may use button components that already include all required states. In some cases, a dedicated Icon component is introduced to describe this behavior.

In B2B products, special care must be taken when working with status and warning colors. An icon should never be the only carrier of meaning. Color must always be supported by shape or text to keep the interface accessible and understandable.

For organizing icon groups within the library, it is recommended to use icons without a background shape, as well as icons enclosed in rectangles or circles. This makes filled and unfilled variations possible.

How to Organize SVG Icon Management

Before moving on to architecture, it is important to understand that inline SVG is not just an aesthetic decision. It is a way to give your interface more flexibility, fewer network requests, and more customization options.

Inline SVG turns an icon from a small asset stored somewhere on a CDN into a living DOM element that can be manipulated as easily as any HTML tag.

Centralized SVG Storage and Delivery via API

This approach works especially well for complex SaaS systems where icons may change or be customizable.

Each icon is stored as an XML string in a database or S3-compatible storage. The API returns the icon data in response to a request, and the frontend injects the SVG directly into the DOM.

This creates a single point of control over the entire icon set. Editors, versioning, and client-specific customization can be added while keeping everything under control.

SVG Component Library

Many SaaS teams prefer to store icons as UI components. In this case, each icon follows a unified style, accepts system properties such as color, size, and class, and can be easily reused across the product.

The benefits are especially noticeable in components with complex logic, where parts of an icon need to change depending on state.

SVG Sprite Embedded in the DOM

Another option is to combine all SVG icons into a single sprite that is injected into the DOM on page load.

This approach combines the advantages of inline SVG with compact storage. The sprite is added only once, and icons can then be reused without duplicating markup.

Inline SVG Accessibility and ARIA

Accessibility deserves special attention. SVG icons should include appropriate ARIA attributes, and purely decorative icons should be hidden from screen readers. These details are often overlooked early on, but in enterprise products they frequently become mandatory.

<svg role="img" aria-labelledby="icon-success-title">
  <title id="icon-success-title">Success</title>
  <path d="..." />
</svg>

<svg aria-hidden="true">
  <path d="..." />
</svg>

Icons that convey meaning should have accessible labels. Decorative icons should be excluded from the accessibility tree to avoid unnecessary noise for screen reader users.

Additional Considerations

Version management is another important aspect. Icons evolve over time: new ones are added and old ones become obsolete. When icons are part of a design system, they must have a clear lifecycle and defined deprecation rules.

Ultimately, working with icons in a large B2B application is not about drawing individual pictograms. It is about building a stable, understandable, and scalable system that works equally well for design, development, and end users.