JavaScript Void(0): Was es ist, wann Du es brauchst und welche Alternativen heute besser sind

Der void-Operator in JavaScript ist ein unärer Operator, der einen Ausdruck auswertet und stets undefined zurückgibt. In der Praxis ist vor allem die Notation void(0) bekannt – häufig in href-Attributen von Links oder als Hilfsmittel bei Immediately Invoked Function Expressions (IIFEs). In diesem Artikel zeige ich Dir ohne Umschweife, wie void(0) funktioniert, wofür es gedacht ist, wo es sinnvoll ist – und wo moderne Alternativen (z. B. event.preventDefault() oder die Verwendung von <button>) die bessere Wahl sind.

Kernidee: void(expr) evaluiert expr und liefert immer undefined.
Typische Nutzung: href="javascript:void(0)" verhindert Navigation bei Klicks auf Links.
Best Practice heute: Für Aktionen statt Navigation lieber <button> nutzen oder per event.preventDefault() die Standardaktion unterbinden.
Besonderheiten: Operator-Priorität beachten. void 0 ist äquivalent zu void(0).
Sicherheit & A11y: javascript:-URIs können von CSP blockiert werden; Buttons sind semantisch korrekter und barriereärmer.

1) Der void-Operator: Definition, Syntax und Operatorpriorität

Der void-Operator ist seit den Anfangstagen von JavaScript Teil der Sprache. Er ist einfach:

Syntax: void expression oder void(expression)
Rückgabewert: immer undefined, unabhängig vom ausgewerteten Ausdruck

Die populärste Schreibweise ist void(0). Funktional äquivalent ist void 0. Beide liefern undefined. Viele Entwickler bevorzugen die Variante mit Klammern, weil sie optisch klarer wirkt und versehentliche Bindungsprobleme vermeidet.

Merke: void ist kein Funktionsaufruf. Es ist ein Operator. void(0) sieht zwar wie ein Funktionscall aus, ist es aber nicht.

Operatorpriorität: Kleine Klammern, großer Effekt

Weil void ein Operator ist, greift die reguläre Operator-Priorität. Das kann überraschende Ergebnisse liefern, wenn Du keine Klammern setzt.

Ausdruck	Ergebnis	Warum?
`void 2 === '2'`	`false`	`void 2` wird zuerst ausgewertet (ergibt `undefined`), dann `undefined === '2'` ist `false`.
`void (2 === '2')`	`undefined`	Zuerst wird `(2 === '2')` ausgewertet, danach `void ...` → immer `undefined`.
`void console.log('Hallo')`	Logt „Hallo“, Ausdruck ergibt `undefined`	`console.log` wird ausgeführt, Rückgabewert wird durch `void` verworfen.

// Demo in der Konsole:
void 2 === '2'     // false
void (2 === '2')   // undefined
void console.log('Hallo') // schreibt "Hallo", ergibt undefined

Wenn Du semantisch ausdrücken willst: „Evaluiere das rechts, aber verwerfe bewusst den Wert“, ist void ein präzises Werkzeug.

2) Void(0) in HTML-Links: Verhalten und Praxis

Die häufigste praktische Nutzung von void(0) ist in <a>-Tags, um Navigation zu verhindern. Hintergrund: Wenn ein Browser einem javascript:-URI folgt, wird der enthaltene Code ausgeführt. Liefert dieser Code einen Wert, versuchen manche Browser, den Dokumentinhalt entsprechend zu ersetzen. Liefert er hingegen undefined, bleibt die Seite stehen. Genau das leistet void(0).

<a href="javascript:void(0)" onclick="alert('Willkommen!')">Klicke mich</a>

Beim Klick: alert wird ausgeführt, aber es findet keinerlei Navigation oder Reload statt.

Warum nicht einfach href=“#“ oder href=““?

href="#" kann die Seite zum Seitenanfang scrollen; href="" kann einen Reload auslösen – beides ist in interaktiven Oberflächen oft unerwünscht. Darum wird häufig javascript:void(0) genutzt.

Variante	Effekt	Probleme	Empfehlung
`href="#"`	Scrollt zum Seitenanfang	Nervige Seiteneffekte, ändert URL-Fragment	Nicht empfohlen
`href=""`	Kann Seite neu laden	Unterbricht Nutzerfluss	Nicht empfohlen
`href="javascript:void(0)"`	Führt JS aus, verhindert Navigation	Kann per CSP blockiert werden, zeigt „javascript:void(0)“ in Statusleiste; semantisch kein echter Link	Nur gezielt und bewusst einsetzen
`<button type="button">`	Führt Aktion aus, keine Navigation	Kein echter Link, falls semantische Navigation nötig	Bevorzugt für Aktionen

Praxis-Tipp: Wenn es nicht um Navigation geht, nimm einen <button type="button">. Das ist semantisch korrekt, besser für Assistive Technologien und natürlicher für Keyboard-Navigation.

3) IIFEs und der void-Operator: sauber signalisieren, dass der Rückgabewert egal ist

Bei Immediately Invoked Function Expressions (IIFEs) wird eine Funktion direkt bei ihrer Definition aufgerufen. Historisch gab es Parser-Fallen, wenn eine Zeile mit function beginnt und der Parser eine Deklaration statt eines Ausdrucks annimmt. void zwingt den Parser in den Ausdrucksmodus und signalisiert gleichzeitig, dass der Rückgabewert nicht genutzt werden soll.

// Klassische IIFE mit Klammern:
(function () {
  console.log('IIFE läuft');
})();

// IIFE mit void:
void function () {
  console.log('IIFE mit void läuft');
}();

Beide Varianten funktionieren. void ist hier ein stilistisches Mittel: Es drückt explizit aus, dass die Auswertung zwar gewollt ist, der Wert aber verworfen werden soll.

Zu Arrow Functions: Auch mit Pfeilfunktionen ist eine IIFE möglich, sie erfordert aber Klammern, damit der Parser die Funktionsdefinition korrekt interpretiert:

// Arrow-IIFE mit Klammern:
(() => {
  console.log('Arrow-IIFE läuft');
})();

// In Kombination mit void:
void (() => {
  console.log('Arrow-IIFE mit void läuft');
})();

Ohne die einleitenden Klammern wäre die Arrow-IIFE syntaktisch ungültig. Das gilt unabhängig vom void-Operator. Kurz: Mit passenden Klammern kannst Du void sowohl mit Function- als auch mit Arrow-IIFEs verwenden.

4) Moderne Alternativen: event.preventDefault(), Buttons und unobtrusive JavaScript

Aktionen statt Navigation: setze auf Buttons

<button type="button" id="openModal">Modal öffnen</button>

<script>
  document.getElementById('openModal').addEventListener('click', () => {
    // Modal öffnen ...
  });
</script>

Vorteile:

Semantisch korrekt für „Aktion ausführen“
Automatisch per Tastatur bedienbar
Bessere Barrierefreiheit, keine Navigation

Wenn Du einen Link brauchst, aber die Navigation verhindern willst

Statt href="javascript:void(0)" kannst Du ein echtes Ziel setzen oder das Standardverhalten per event.preventDefault() verhindern:

<a href="/eigentliche-navigation" id="linkAction">Aktion</a>

<script>
  const link = document.getElementById('linkAction');
  link.addEventListener('click', (event) => {
    // Nur wenn bestimmte Bedingung, sonst echte Navigation
    const sollNavigieren = false;
    if (!sollNavigieren) {
      event.preventDefault(); // verhindert das Folgen des href
      // Führe Deine Aktion aus
    }
  });
</script>

Unobtrusive JavaScript

Trenne Markup und Verhalten. Keine Inline-Handler (onclick="...") und keine javascript:-URIs im HTML. Lade Skripte getrennt und binde Events per addEventListener:

<!-- HTML -->
<button type="button" class="js-open-modal">Modal öffnen</button>

<!-- JS -->
document.addEventListener('DOMContentLoaded', () => {
  document.querySelectorAll('.js-open-modal').forEach((btn) => {
    btn.addEventListener('click', () => {
      // Modal öffnen
    });
  });
});

Framework-Hinweis: React und andere moderne Frameworks raten explizit von javascript:-URIs in href ab (Sicherheits- und CSP-Gründe). Nutze Event-Handler und Komponentenlogik.

5) Sicherheits- und Usability-Aspekte

Content Security Policy (CSP)

Die meisten strengen CSP-Konfigurationen blockieren javascript:-URIs, da sie als Inline-Script gelten. Wenn Deine Anwendung CSP einsetzt (z. B. script-src 'self' ohne 'unsafe-inline'), funktionieren href="javascript:..." nicht. Das ist gewollt, um XSS-Angriffe zu erschweren. Setze in diesem Umfeld keine javascript:-URIs ein.

Statusleiste und Nutzererwartung

Viele Browser zeigen beim Hover die Ziel-URL an. Steht dort javascript:void(0), wirkt das auf Nutzer wie ein „kaputter“ Link. Das kann Vertrauen und Verständnis beeinträchtigen. Buttons wirken in solchen Fällen natürlicher und klarer.

Barrierefreiheit (A11y)

Aktionen: Nutze Buttons, nicht Links. Screenreader interpretieren <a> als Navigation.
Rollen & ARIA: Wenn Du aus triftigen Gründen einen <a> als Aktion verwendest, ergänze role="button", stelle tabindex– und Tastaturbedienung sicher und unterbinde Navigation serverseitig (z. B. durch echtes href vermeiden).
Fokus: Achte darauf, dass der Fokus nicht „springt“ (z. B. bei #-Fragmenten).

SEO und Analytics

Links mit javascript:-URIs sind für Crawler bedeutungslos. Wenn es Navigation ist, nutze echte URLs. Wenn es eine Aktion ist, nutze Buttons und tracke Klick-Events sauber per Event-API.

6) Häufige Fehler und Debugging-Tipps

Verwechselte Operatorpriorität: Setze Klammern, wenn Du sicherstellen willst, dass zuerst ein Ausdruck ausgewertet wird, ehe void greift.
Übermäßiger Einsatz in Links: Nutze void(0) nicht reflexartig. Prüfe, ob button + Event-Handler die bessere Wahl ist.
Inline-Handler und „return false“: Verlasse Dich nicht auf Inline-Handler. addEventListener + preventDefault ist klarer, testbarer und CSP-freundlich.
CSP-Fehler: Wenn Klicks „nichts tun“, prüfe die Konsole: Möglicherweise blockiert die CSP javascript:-URIs.

// Operatorpriorität prüfen:
console.log(void 2 === '2');   // false
console.log(void (2 === '2')); // undefined

// Links debuggen:
document.querySelectorAll('a').forEach(a => {
  a.addEventListener('click', e => console.log('Klick auf', a.href));
});

7) Browserunterstützung und Stabilität

void ist in allen gängigen Browsern seit jeher unterstützt. void(0) funktioniert „überall“. Das Problem ist weniger die Browserkompatibilität als vielmehr:

CSP-Kompatibilität: javascript:-URI kann blockiert sein.
A11y-Semantik: Links signalisieren Navigation, Buttons signalisieren Aktion.
Developer Experience: Linter-Regeln (z. B. ESLint no-script-url) unterbinden javascript:-URLs aus gutem Grund.

// ESLint-Beispiel:
{
  "rules": {
    "no-script-url": "error"
  }
}

8) Historischer Kontext: Warum es überhaupt void(0) gibt

Vor ES5 war die globale Variable undefined überschreibbar. Um garantiertes undefined zu erzeugen, nutzte man void 0:

var undefined = 123;          // historisch möglich
console.log(undefined);       // 123
console.log(void 0);          // garantiert undefined

Außerdem waren javascript:-Lesezeichen (Bookmarklets) und Inline-JS gängige Techniken. void(0) half, ungewollte Dokumentenänderungen bei javascript:-URLs zu vermeiden. Heute setzen wir auf modulare Skripte, Event-Handler und strenge Sicherheitsrichtlinien – das erklärt den Rückzug dieser Muster aus modernen Codebasen.

9) Entscheidungs-Guide: Wann setzt Du Void(0) ein – und wann nicht?

Situation	Nutzung von Void(0)	Bessere Alternative	Begründung
Reine Aktion (kein Seitenwechsel)	Nicht nötig	`<button type="button">` + Event	Semantisch korrekt, A11y-freundlich, kein `javascript:`
Link-Optik, aber keine Navigation	Nur, wenn keine CSP greift und zwingend `<a>` gebraucht wird	`<button>` per CSS wie Link stylen	Vermeidet `javascript:`, klare Nutzererwartung
Kontextspezifischer Link, Navigation ggf. verhindern	Vermeide	`href` auf echtes Ziel + `event.preventDefault()` je nach Zustand	Erhält Semantik und Progressive Enhancement
Bookmarklets/Legacy-Widgets	Akzeptabel	—	Historisch bedingt, in Legacy-Umgebungen gängig
IIFEs, deren Rückgabewert verworfen wird	Optional sinnvoll	Klassische Klammer-IIFE	`void` signalisiert Absicht („Wert verwerfen“)

10) Praxisbeispiele: Von Anti-Pattern zu robustem Code

Anti-Pattern: Inline-JS und javascript:-URI

<a href="javascript:void(0)" onclick="toggleMenu()">Menü</a>

Probleme: CSP, Testbarkeit, A11y, Linting. Besser so:

Besser: Unobtrusive JS + Button

<button type="button" class="nav__toggle js-nav-toggle" aria-expanded="false" aria-controls="mainNav">
  Menü
</button>

<nav id="mainNav" hidden>...</nav>

<script>
  document.addEventListener('DOMContentLoaded', () => {
    const btn = document.querySelector('.js-nav-toggle');
    const nav = document.getElementById('mainNav');

    btn.addEventListener('click', () => {
      const isOpen = btn.getAttribute('aria-expanded') === 'true';
      btn.setAttribute('aria-expanded', String(!isOpen));
      nav.hidden = isOpen;
    });
  });
</script>

Fortgeschritten: Bedingte Navigation

<a href="/checkout" class="js-checkout">Zur Kasse</a>

<script>
  document.querySelector('.js-checkout').addEventListener('click', (e) => {
    const cartIsValid = validateCart();
    if (!cartIsValid) {
      e.preventDefault(); // verhindere Navigation
      showCartErrors();
    }
  });
</script>

IIFE mit void: Absicht betonen

void function init() {
  // Setup-Code, Rückgabewert ist unwichtig
  console.log('Init läuft');
}();

11) Feinheiten: Lesbarkeit, Performance, Tooling

Lesbarkeit: void(0) in Markup wirkt schnell „magisch“. Ein sauberer Button oder ein Event-Handler ist für Teams oft leichter zu warten.
Performance: Kein nennenswerter Unterschied zu Alternativen; relevant ist die Architektur (Unobtrusive JS, kein Inline-Code).
Linting & Policies: Lege Projektregeln fest (z. B. „kein javascript: im Markup“). Das verhindert unsichere Patterns im Review-Alltag.

12) Zusammenfassung: Was Du über Void(0) mitnehmen solltest

void evaluiert einen Ausdruck und liefert immer undefined.
void(0) in href verhindert Navigation und Seitenersatz bei javascript:-URIs – funktioniert breit, kann aber durch CSP blockiert sein und ist semantisch schwach.
Für interaktive Aktionen ohne Navigation sind <button> und Event-Handler die bevorzugte, barrierearme Lösung.
IIFEs lassen sich mit void elegant kennzeichnen („Wert verwerfen“); mit Function- und Arrow-IIFEs möglich, solange die Klammerung korrekt ist.
Nutze event.preventDefault() für gezieltes Verhindern von Standardverhalten; vermeide Inline-Handler und javascript:-URIs in modernem Code.

Fazit

Void(0) ist ein altes, aber legitimes Werkzeug: Es verhindert in javascript:-Links Navigation und signalisiert bei IIFEs, dass der Rückgabewert verworfen werden soll. In modernen Anwendungen solltest Du es gezielt und sparsam einsetzen. Wo immer es um Aktionen statt Navigation geht, sind <button> und saubere Event-Handler die bessere Wahl – semantisch korrekt, barrierearm, CSP- und sicherheitsfreundlich. Nutze void dort, wo es wirklich semantischen Mehrwert hat (z. B. in IIFEs), und greife im UI zu Alternativen, die heutigen Best Practices entsprechen.

FAQ

Was macht der void-Operator in JavaScript genau?

void evaluiert seinen Operanden und gibt unabhängig vom Ergebnis immer undefined zurück. Beispiel: void console.log('x') loggt „x“ und ergibt undefined.

Ist `void(0)` und `void 0` dasselbe?

Ja. Beides liefert undefined. void(0) wird aus Lesbarkeitsgründen oft bevorzugt.

Warum nutzt man `href="javascript:void(0)"` überhaupt?

Um die Navigation zu verhindern und nur eine Aktion auszuführen. Der Browser versucht den Dokumentinhalt nicht zu ersetzen, wenn der javascript:-Ausdruck undefined liefert – was void(0) garantiert.

Ist `href="#“` eine gute Alternative?

Meistens nicht. Es kann die Seite nach oben scrollen oder die URL verändern. Für reine Aktionen sind Buttons die bessere Wahl.

Blockiert meine Content Security Policy `javascript:`-URIs?

Häufig ja. Eine strenge CSP erlaubt keine Inline-Skripte, dazu zählen javascript:-URIs. Setze in CSP-Umgebungen auf Buttons und Event-Handler statt javascript:-Links.

Kann ich `void` mit Arrow-IIFEs verwenden?

Ja, mit korrekter Klammerung: void (() => { /* ... */ })(). Ohne Klammern ist das syntaktisch ungültig. Das gilt unabhängig von void.

Wie verhindere ich Navigation ohne `javascript:void(0)`?

Setze einen Event-Handler und rufe event.preventDefault() im click-Handler auf. Das ist flexibler, testbarer und CSP-freundlich.

Warum war `void 0` früher verbreitet?

Historisch konnte undefined überschrieben werden. void 0 garantierte ein echtes undefined. Heute ist undefined schreibgeschützt, der Grund entfällt – der Operator ist aber weiterhin nützlich.

Wie wirkt sich `void(0)` auf Barrierefreiheit aus?

Ein <a> suggeriert Navigation. Für Aktionen ohne Navigation ist ein <button> barriereärmer. Zudem kann „javascript:void(0)“ in der Statusleiste irritieren.

Gibt es Performanceunterschiede zwischen `void(0)` und `preventDefault()`?

Nein, in der Praxis irrelevant. Maßgeblich ist die semantisch korrekte und wartbare Architektur – Buttons und Event-Handler schlagen javascript:-URIs klar.