Icons in Webprojekten

1. SVG-Sprites mit <use>: Die skalierbare Lösung

Wie es funktioniert

<svg>
  <symbol id="icon-search" viewBox="0 0 24 24">
    <path d="..." />
  </symbol>
  <symbol id="icon-user" viewBox="0 0 24 24">
    <path d="..." />
  </symbol>
</svg>

Wir  haben einen großen SVG-Container, in dem mehrere Icons als <symbol>-Elemente definiert sind. Jedes Symbol hat:

• eine eindeutige ID (icon-search, icon-user)
• einen viewBox-Wert (0 0 24 24) — das ist das Koordinatensystem des Icons
• den Pfad (<path d="...") — die eigentliche Icon-Form

Zwar lassen sich SVG-Sprites grundsätzlich auch mit <g>-Elementen gruppieren, jedoch bringt <symbol> dafür entscheidende Vorteile mit. Ein <g> dient lediglich der Zusammenfassung mehrerer SVG-Elemente und kann daher als Vorlage für ein Icon verwendet werden. Es besitzt jedoch keine eigene viewBox, sodass alle Icons im gemeinsamen Koordinatensystem des übergeordneten SVG arbeiten. Dadurch werden unterschiedliche Ursprungsgrößen und Proportionen schwieriger zu handhaben. <symbol> wurde hingegen speziell für wiederverwendbare SVG-Inhalte entwickelt: Jedes Symbol kann eine eigene viewBox definieren und wird standardmäßig nicht direkt gerendert. Deshalb eignet sich <symbol> in den meisten Fällen besser für moderne SVG-Sprites, während <g> eher für einfache Gruppierungen innerhalb einer Grafik verwendet wird.

Verwendung:

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

Der Browser rendert das Icon an dieser Stelle, die Definition liegt jedoch zentral an einer Stelle.

Was spricht dafür

• Performance:
  Jedes Icon wird nur einmal definiert.
• Wartbarkeit:
  Änderungen wirken automatisch überall.
• Erweiterbarkeit:
  Neue Icons werden als weitere <symbol>-Elemente ergänzt.
• Skalierbarkeit:
  Bewährte Lösung für große Design-Systeme.

Die Schattenseiten

SVG-Sprites bringen einige Besonderheiten mit sich, die bei der Entscheidung berücksichtigt werden sollten. Zum einen ist in der Regel ein zusätzlicher Build-Schritt erforderlich, da die Sprite-Datei meist automatisch generiert wird und nicht manuell erstellt wird. Dies erhöht die Komplexität des Setups geringfügig. Zum anderen gibt es Einschränkungen beim Styling. Während bei Inline-SVG einzelne Pfade gezielt per CSS angesprochen und animiert  werden können, ist dies bei Sprites, die über <use> eingebunden werden, nicht möglich. Ein weiterer Aspekt ist die Abhängigkeit von der jeweiligen Architektur. Wenn die SVG-Sprite-Datei auf einem externen Server oder CDN liegt, kann sie durch Content Security Policies (CSP) oder spezielle Build- und Deployment-Konfigurationen eingeschränkt oder blockiert werden.

2. Inline SVG: Die flexible Lösung

Wie es funktioniert

<svg viewBox="0 0 24 24">
  <path d="M10 18a8 8 0 1 1 5.293-14.293..." />
</svg>

Wir betten das SVG direkt in unseren HTML-Code ein. Der Browser rendert es direkt. Es gibt keinen Umweg über Fonts oder externe Dateien.  

Was spricht dafür

Inline SVG gibt maximale Flexibilität. Einzelne Pfade lassen sich direkt per CSS ansprechen, gestalten und animieren:

svg path {
  fill: currentColor;
}

Das Icon erbt automatisch die Textfarbe.

Barrierefreiheit  funktioniert elegant:

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

Mehrfarbigkeit ist kein Problem. CSS-Animationen funktionieren ebenfalls.

Die Schattenseiten von Inline SVG

• DOM-Wachstum bei vielen Icons.
• Duplikation desselben SVG-Codes.
• Inkonsistenzen ohne zentrales Design-System.

Gedanken zur Barrierefreiheit

Beim Einsatz von Icon kann man einiges falsch machen. Ein häufiger Fehler besteht darin, pauschal jedem Icon aria-hidden="true" zuzuweisen. Das wirkt zunächst pragmatisch, macht jedoch auch informative Icons für Screenreader unsichtbar. Ein Warnsymbol neben einem Formularfeld vermittelt beispielsweise eine wichtige Information. Wird es mit aria-hidden="true" ausgeblendet, bleibt diese Bedeutung für Nutzer assistiver Technologien verborgen.

Die korrekte Lösung erfordert keine zusätzliche Komplexität, sondern lediglich eine Entscheidung anhand des Kontexts. Ein Pfeil neben einem „Mehr lesen“-Link ist dekorativ und kann ausgeblendet werden. Ein Icon, das eigenständig einen Status oder eine Information kommuniziert, muss seine Bedeutung hingegen an assistive Technologien weitergeben können.

Icons erfüllen unterschiedliche Funktionen, und eine durchdachte SVG-Strategie sollte dies widerspiegeln. Anwender müssen daher die Möglichkeit haben, Icons sowohl dekorativ als auch semantisch bedeutungsvoll einzusetzen. Ein pauschales aria-hidden="true" für alle Icons ist deshalb grundsätzlich falsch. Entscheidend ist, ob ein Icon ausschließlich der visuellen Gestaltung dient oder eine relevante Information transportiert.

3. CSS-Masken

Wie es funktioniert

<span class="icon-search"></span>

.icon-search {
  width: 1rem;
  height: 1rem;
  background-color: currentColor;
  mask: url(search.svg) no-repeat center;
  mask-size: contain;
  -webkit-mask: url(search.svg) no-repeat center;
  -webkit-mask-size: contain;
}

Die mask-Eigenschaft nutzt das SVG als Formmaske. Sichtbar sind nur die Bereiche der Hintergrundfarbe, die durch das SVG durchgelassen werden.

Was spricht dafür

• Sehr einfaches HTML.
• Gute CSS Unterstützung ab 2026
• Kein zusätzlicher SVG-DOM. 

Die Einschränkungen

CSS-Masken können nur einfarbige Icons darstellen. Mehrfarbige Icons oder Verläufe sind nicht möglich. Mit mask-image müssen Sie background-color manipulieren  und das funktioniert nur wenn die dahinterliegende Fläche sichtbar ist. Auch CSS Fehler sind schwer zu erkennen. Was ist falsch , die Maske? Das Bild? Das Rendering....

<button aria-label="Benachrichtigungen">
  <span class="icon-bell" aria-hidden="true"></span>
</button>

<span class="icon-bell"
      role="img"
      aria-label="Benachrichtigungen">
</span>

4. Internationalisierung und Übersetzung

Icons brauchen keine Übersetzung. Ein Such-Icon ist überall auf der Welt eine Lupe, die Form ist universell verständlich.

Aber: Das Icon selbst hat keine intrinsische Bedeutung. Diese entsteht erst im UI-Kontext. Dort sitzt auch die Übersetzung. Der Button mit aria-label="Suche" muss übersetzt werden, das Icon selbst bleibt gleich.

Übersetzung passiert immer außerhalb des Icons:

<button aria-label="Suche">
  <svg class="icon" aria-hidden="true">
    <use href="#icon-search"></use>
  </svg>
</button>

Hier wird das aria-label übersetzt. Das Icon bleibt gleich.

Das Anti-Pattern: <title> im SVG

SVG-Icons können mit einem <title>-Element grundsätzlich zugänglich gemacht werden, da dieses eine textuelle Beschreibung innerhalb des SVG bereitstellt.

<svg role="img">
  <title>Suche</title>
  <path d="..." />
</svg>

Wenn die Bedeutung eines Icons im <title>-Element des SVG selbst hinterlegt wird, entsteht eine unnötige Kopplung zwischen dem visuellen Asset und der UI-Semantik. Dadurch wird ein und dasselbe Icon semantisch „aufgeladen“, obwohl es je nach Einsatzort unterschiedliche Funktionen haben kann. Besser ist es, Icons als bedeutungsfreie visuelle Ressourcen zu behandeln und die zugängliche Beschreibung im UI-Kontext zu definieren. <title> ist weiterhin Bestandteil der SVG-Accessibility-Spezifikation und kann in bestimmten Szenarien  jedoch sinnvoll eingesetzt werden, beispielsweise bei eigenständigen SVG-Grafiken, komplexen Illustrationen oder wenn kein umgebendes Label vorhanden ist. 

<svg aria-hidden="true">
  <use href="#icon-search"></use>
</svg>

aria-hidden="true" sagt Assistive Technologies: Das Label kommt von einem umgebenden Element.

5. Accessibility im Direktvergleich

Hier ist die Übersicht, welches System wie sicher in Sachen Accessibility ist:

• Inline SVG:
  Sehr gut. Sie können role="img", <title> und Labels nutzen.
• SVG-Sprites:
  Sehr gut. Dieselben Möglichkeiten wie Inline SVG, aber mit zentraler Wiederverwendung.
• CSS-Masken:
  Mittel. Das Icon selbst ist semantisch leer. Das Label muss vom Container kommen.
• Icon Fonts:
  Schlecht. Screenreader sehen Textzeichen statt Grafiken.

6. Performance im Direktvergleich

• Icon Fonts: DOM-Überlast gibt es nicht, aber die Mapping-Logik kostet Komplexität.
• Inline SVG: Browser müssen viele DOM-Knoten verwalten.
• SVG-Sprites: Bestes Caching. Eine Datei, viele Icons.
• CSS-Masken: Minimaler DOM, kleine SVG-Dateien und gute Cache-Nutzung.

Für reine Performance gewinnen SVG-Sprites.

7. Wartbarkeit und Erweiterbarkeit

• Inline SVG: Sehr flexibel, aber viele Duplikate entstehen. Ein Entwickler kopiert ein Icon, ändert es leicht ab – plötzlich existieren mehrere Varianten desselben Symbols.
• CSS-Masken: Einfach und übersichtlich. Solange die Anforderungen bei einfarbigen Icons bleiben, ist die Wartbarkeit hoch.
• SVG-Sprites:Zentrale Verwaltung. Keine Duplikate. IDs bleiben stabil. Änderungen wirken global. Das ist langfristig die nachhaltigste Lösung.

8. Praxisbeispiele aus echten Design-Systemen

Bisher haben Sie die theoretischen Unterschiede kennengelernt. Lassen Sie mich jetzt zwei völlig verschiedene Implementierungen zeigen. Beide sind produktiv im Einsatz. Beide lösen das Icon-Problem anders. Das ist wichtig zu verstehen: Es gibt nicht das richtige Icon-System. Es gibt das richtige System für den jeweiligen Kontext.

IBM Carbon: Icons als UI-Komponenten

Das IBM Carbon Design System behandelt Icons nicht als Dateien, sondern als Komponenten.

Statt:

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

schreibt man:

<Search size={16} />

Das ist ein fundamentaler Architekturunterschied. Icons werden zu semantischen UI-Bausteinen.

Drei charakteristische Merkmale:

1. Strikte Integration ins Design-System
   Icons sind Teil einer kontrollierten API.
2. Sicherheit durch Struktur
   Typisierung verhindert Fehlverwendung.
3. Accessibility von Anfang an
   Icons werden stets innerhalb eines UI-Kontextes verwendet.

Der Kolibri-Ansatz: Leichtgewicht statt Design-System

Kolibri verfolgt den gegenteiligen Ansatz. Icons bleiben einfache Assets.

Variante A: CSS Mask-Images

.icon-search {
  width: 24px;
  height: 24px;
  mask-image: url('icons/search.svg');
  mask-size: contain;
  mask-repeat: no-repeat;
  background-color: currentColor;
}

<span class="icon-search"></span>

Variante B: SVG-Sprite light

<svg class="icon">
  <use href="/icons.svg#search"></use>
</svg>

Typische Charakteristiken

1. Minimaler Abstraktions-Layer
2. Performance und Cache-Freundlichkeit
3. Niedrige Einstiegshürde

9. Finaler  Lösungsansatz: Reines HTML SVG-Icon-System

Die bisherigen Kapitel haben verschiedene Strategien gezeigt.
Für viele reine HTML/CSS-Projekte reicht jedoch ein einfaches, wartbares SVG-Sprite-System vollkommen aus.

Eine zentrale SVG-Sprite-Datei

<svg xmlns="http://www.w3.org/2000/svg">
  <symbol id="icon-search" viewBox="0 0 24 24">
   <path d="M10 18a8 8 0 1 1
             5.293-14.293A8 8 0 0 1
             10 18zm11 3-6-6"/>
  </symbol>
  <symbol id="icon-user"
          viewBox="0 0 24 24">
    <path d="M12 12a4 4 0 1 0-4-4
             4 4 0 0 0 4 4zm0 2
             c-4.418 0-8 2.239-8 5v1h16v-1
             c0-2.761-3.582-5-8-5z"/>
  </symbol>
  <symbol id="icon-check"
          viewBox="0 0 24 24">
    <path d="M9 16.2 4.8 12l-1.4 1.4
             L9 19 21 7l-1.4-1.4z"/>
  </symbol>
...
</svg>

Das ist die zentrale Icon-Registry. Jedes Icon existiert genau einmal.

Das CSS-Styling

.icon {
  width: 1em;
  height: 1em;
  display: inline-block;
  vertical-align: middle;
  fill: currentColor;
}

/* Größenvarianten */
.icon--sm {
  width: 0.85em;
  height: 0.85em;
}

.icon--md {
  width: 1em;
  height: 1em;
}

.icon--lg {
  width: 1.5em;
  height: 1.5em;
}

/* Baseline-Ausrichtung */
.icon--baseline {
  vertical-align: -0.125em;
}

Der wichtigste Teil ist:

fill: currentColor;

Das Icon übernimmt automatisch die Farbe seines umgebenden Textes. Ein Icon in einem roten Link wird automatisch rot. Ein Icon in deaktiviertem Text automatisch grau. Die Größe des Icons passt sich beim Zoomen an.

Dark Mode

@media (prefers-color-scheme: dark) {

  :root {
    --icon-color: #f2f2f2;
  }

}

Eine einzige Variablenänderung genügt, um sämtliche Icons an das Farbschema anzupassen.Das ist deutlich wartbarer als Inline-Styles oder individuelle Farbdefinitionen.

Verwendung 

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

width: 1em;
height: 1em;

Das Icon wächst automatisch mit der Schriftgröße.

Namenskonvention

icon-{meaning}

Beispiele:

• icon-search
• icon-user
• icon-check
• icon-settings
• icon-trash

Keine Größenangaben im Namen. Keine Farbangaben im Namen.

Die ID beschreibt nur das Icon selbst, niemals dessen Darstellung.

Neue Icons hinzufügen

<symbol id="icon-bell"
         viewBox="0 0 24 24">
  <path d="..." />
</symbol>

Das HTML bleibt unverändert. Das CSS bleibt unverändert. Lediglich das Sprite erhält ein weiteres Symbol.

icons/
  search.svg
  user.svg
  check.svg
  bell.svg

dist/
  sprite.svg

src/
  icon.css

scripts/
  build-icons.js

index.html

import fs from "fs";
import path from "path";
const ICON_DIR = "./icons";
const OUTPUT = "./dist/sprite.svg";

function buildSprite() {

  const files = fs.readdirSync(ICON_DIR)
    .filter(f => f.endsWith(".svg"));

  const symbols = files.map(file => {
    const name = path.basename(file, ".svg");
    const svg = fs.readFileSync(
      path.join(ICON_DIR, file),
      "utf8"
    );

    const content = svg
      .replace(/<svg[^>]*>/, "")
      .replace("</svg>", "");

    return `
      <symbol id="icon-${name}">
        ${content}
      </symbol>
    `;
  });

  const sprite = `
    <svg xmlns="http://www.w3.org/2000/svg">
      ${symbols.join("")}
    </svg>
  `;

  fs.writeFileSync(OUTPUT, sprite);

  console.log(
    `✓ Sprite built: ${OUTPUT}
     (${files.length} icons)`
  );
}

buildSprite();

node scripts/build-icons.js

Quell-Icons (SVG-Dateien)
        ↓

Linting (Namen prüfen)
        ↓

Build-Skript
(Sprite generieren)
        ↓

Sprite (dist/sprite.svg)
        ↓

HTML-Nutzung mit <use>
        ↓

CSS-Styling & Größen
        ↓

Browser rendert Icons