Void(0) in JavaScript: Verständnis, Einsatz, Alternativen und Best Practices

Was du über den void-Operator wirklich wissen musst

Der void-Operator in JavaScript ist ein unärer Operator, der einen Ausdruck auswertet und immer undefined zurückgibt. In Codeform: void expression. Häufig siehst du ihn als void(0) oder void 0 – beides ist äquivalent.

Entscheidend ist: Der Ausdruck wird ausgeführt (und entfaltet seine Nebenwirkungen), aber sein Wert wird bewusst verworfen. Dadurch eignet sich void überall dort, wo du sicherstellen willst, dass kein Rückgabewert weiterverwendet wird – zum Beispiel in Kombination mit dem Pseudo-URL-Schema javascript:.

// Basis: void verwirft jeden Rückgabewert
const result = void (1 + 1);
console.log(result); // undefined

// Komplexere Ausdrücke: Nebenwirkungen passieren, Rückgabewert ist egal
void (
  document.body.style.backgroundColor = 'red',
  document.body.style.color = 'white'
);
// Die Styles ändern sich, die Auswertung liefert "undefined".

Merke: void ist kein Keyword für „tu nichts“, sondern „werte aus und gib undefined zurück“. Das macht es ideal, um Rückgabewerte sicher zu ignorieren.

javascript:void(0); – Was im Browser wirklich passiert

Das bekannte Konstrukt javascript:void(0) kombiniert die JavaScript-Pseudo-URL javascript: mit dem Ergebnis-supprimierenden void(0). Verwendet in <a href="...">, teilt es dem Browser mit: „Führe diesen JavaScript-Ausdruck aus, aber navigiere nicht, weil das Ergebnis undefined ist.“

javascript: signalisiert dem Browser, JavaScript auszuführen (statt eine URL anzufordern).
void(0): garantiert, dass die Auswertung mit undefined endet – also keine Navigation/Seitenersetzung.

<a href="javascript:void(0)" onclick="performAction()">Aktion ausführen</a>

Historisch war das ein gängiges Muster, um „Links“ zu bauen, die Code ausführen, ohne die Seite zu verlassen. Der Browser:

wertet den Code nach javascript: aus,
verwendet das Ergebnis zur Dokumentenaktualisierung wenn es ein String ist,
navigiert nicht, wenn das Ergebnis undefined ist (daher void(0)).

Hinweis: Bei javascript:-URIs in Adressleiste oder Lesezeichen (Bookmarklets) wird der auszuführende Code im Kontext der aktuellen Seite evaluiert. Das Ergebnis beeinflusst die Navigation nur dann, wenn ein String zurückgegeben wird.

Beachte moderne Sicherheitsrichtlinien: Eine strikte Content Security Policy (CSP) kann javascript:-URIs blockieren, weil sie als Inline-Skripte gelten. Das ist ein weiterer Grund, heute Alternativen zu bevorzugen.

Historische Relevanz vs. heutige Erwartungen

In den frühen Jahren des Webs waren Event-APIs, Semantik und Tooling limitiert. javascript:void(0); wurde genutzt, um klickbare Elemente mit Skript-Verhalten zu bauen, die wie Links aussahen, aber nicht navigierten. Das Muster war pragmatisch – aber es zementierte Fehlsemantik: Anker stehen semantisch für Navigation, nicht für bloße Aktionen. Heute hast du bessere, barrierefreie und suchmaschinenfreundliche Alternativen.

Konkrete Anwendungsfälle: Früher vs. heute

1) „Klick mich, aber navigiere nicht“

Früher:

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

Heute (besser):

<button type="button" class="btn btn-link" aria-expanded="false" aria-controls="main-menu" id="menu-toggle">Menü</button>

<script>
  document.getElementById('menu-toggle').addEventListener('click', function () {
    // Menü ein-/ausklappen, ARIA-States pflegen
    const expanded = this.getAttribute('aria-expanded') === 'true';
    this.setAttribute('aria-expanded', String(!expanded));
    document.getElementById('main-menu').hidden = expanded;
  });
</script>

2) Bookmarklets

Heute noch sinnvoll: Für Bookmarklets (Lesezeichen, die JS ausführen) ist javascript: weiterhin üblich. void verhindert, dass der Rückgabewert die Seite ersetzt.

javascript:void(function(){ 
  alert('Hallo aus dem Bookmarklet');
}());

3) Inline-Effekte ohne Navigation

Früher:

<a href="javascript:void(document.body.style.backgroundColor='green')">Grüner Hintergrund</a>

Heute: Nutze Buttons und saubere Event-Handler.

<button type="button" id="bg-green">Grüner Hintergrund</button>
<script>
  document.getElementById('bg-green').addEventListener('click', () => {
    document.body.style.backgroundColor = 'green';
  });
</script>

Alternativen im Vergleich: Semantik, UX, Technik

Ansatz	Semantik	Verhalten	Vorteile	Nachteile	Empfehlung
<a href=“javascript:void(0)“>	Link (Navigation), aber agiert als Aktion	Kein Navigieren, JS-Ausführung möglich	Einfach, legacy-kompatibel	Barrierefreiheit, UX, SEO und CSP-Probleme	Vermeiden
<a href=“#“ onclick=“event.preventDefault()“>	Link, aber mittels JS „blockiert“	Verhindert Navigation	Weit verbreitet, einfach	Scrollt ggf. nach oben ohne preventDefault; Fehlsemantik	Nur als Übergang
<a href=“#!“>	Link mit Hash-Bang	Kein Scrollen, Router-freundlich (legacy-SPA)	Nützlich für Hash-Routing	Fehlsemantik, historisches SPA-Pattern	Nur für Hash-Router
<button type=“button“>	Aktion	Aktivierung via Enter & Space, fokusierbar	Semantisch korrekt, a11y-freundlich	Benötigt ggf. CSS, um wie Link auszusehen	Bevorzugt
<a href=“/ziel“>	Navigation	Öffnet Ressource, unterstützt SEO	Richtig für echte Links	Kein direkter JS-Aktionsersatz	Bevorzugt für Navigation
return false; im onclick	Ad-hoc Blockade	Unterdrückt Standardverhalten	Kurz, historisch oft genutzt	Reihenfolge-abhängig, weniger explizit als preventDefault	Nur legacy
<a role=“button“> (mit JS)	Link mit Button-Rolle	Kann a11y teils verbessern	Notlösung bei strengen Designvorgaben	Erfordert Zusatz-Handling (Keyboard, ARIA)	Nur mit Sorgfalt

Barrierefreiheit (a11y) und Nutzererwartungen

Tastaturbedienung: Echte Links werden mit Enter aktiviert; Leertaste scrollt typischerweise die Seite. Buttons werden mit Enter und Leertaste aktiviert. Ein „Link“, der wie ein Button benutzt wird, verletzt Erwartungshaltungen.
Screenreader: Ein <a> wird als Link angekündigt. Wenn er nicht navigiert, ist das irritierend. Ein <button> wird korrekt als Aktion angekündigt.
Kontextmenü: Rechtsklick auf einen Link zeigt Einträge wie „Link in neuem Tab öffnen“ – sinnlos bei javascript:void(0). Mittelklick kann leere Tabs öffnen oder schlicht nichts Sinnvolles tun.
Fokus und States: Buttons lassen sich mit ARIA-Attributen (z. B. aria-pressed, aria-expanded) und visuellem Fokuszustand klar kommunizieren.

Praxis-Tipp: Verwandle keine Links in Pseudo-Buttons. Nutze echte Buttons für Aktionen. Wenn du einen Link optisch wie einen Link behalten willst, style einen Button mit CSS (z. B. btn btn-link).

SEO und technische Implikationen

Suchmaschinen interpretieren echte Links (<a href="/ziel">) als Navigationssignale im internen Verlinkungsgraphen. Ein href="javascript:void(0)" ist kein Link im SEO-Sinn – es gibt keine Ziel-URL, also auch keinen Graph-Beitrag. Wenn deine Navigation so gebaut ist, fehlt Suchmaschinen die Verbindung zwischen Seiten.

JS-Ausführung: Moderne Crawler (z. B. Googlebot) können JavaScript ausführen, aber verlassen solltest du dich nicht darauf. Kritische Navigation sollte als statischer HTML-Link existieren.
Server-Side Rendering (SSR): Liefere echte href-Links. Progressive Enhancement kann immer noch dynamische UX bieten.
Struktur: Für interne Verlinkung sind echte Anker mit href Pflicht. javascript:void(0) hilft dir nicht beim Crawling.

Sicherheit und CSP

Content Security Policy (CSP): Strenge Policies sperren javascript:-URIs. Rely on event handlers and external scripts statt Inline-JS in href.
Injection-Risiken: Wenn du dynamische Inhalte in href="javascript:…" einfügst, schaffst du eine potenzielle XSS-Senke. Vermeide dieses Pattern konsequent.
Audits: Security-Scanner melden javascript:-URIs regelmäßig als Finding. Der Wechsel zu Buttons/Events reduziert die Angriffsfläche.

Browser-Support und Verhalten

Der void-Operator sowie die javascript:-Pseudo-URL sind seit Jahrzehnten breit unterstützt – von Legacy-Browsern bis modern. Dennoch:

Inkompatible Policies: Eine CSP kann Ausführung verhindern.
Tab-Verhalten: Mittelklick auf javascript:-Links führt je nach Browser zu leeren oder blockierten Tabs.
Tooling: Linter/Formatter und Security-Tools raten von javascript:-Links ab.

Best Practices: So triffst du die richtige Wahl

Wenn es navigiert, nutze <a href=“…“>. Das ist semantisch korrekt, zugänglich und SEO-freundlich.
Wenn es eine Aktion ist, nutze <button type=“button“>. Ergänze Event-Handler per JS.
Vermeide javascript:void(0) in Produktcode. Nutze es höchstens in Bookmarklets oder als historisches Verständnisartefakt.
Steuere Verhalten mit event.preventDefault() statt return false;. Explizit ist besser als implizit.
Stile entkoppeln: Forme Buttons bei Bedarf optisch zu Links um (CSS), nicht umgekehrt.

Entscheidungsbaum (vereinfacht)

Brauchst du eine URL-Zielseite? → Nutze <a href>.
Nur Aktion, kein Ziel? → Nutze <button>.
Bookmarklet? → javascript: mit void zulässig.

Migration: Weg von javascript:void(0)

Finde alle Vorkommen: Suche nach href="javascript:void(0)" und href="javascript:".
Kategorisiere: Handelt es sich um Navigation (falsche Verwendung) oder um Aktion?
Ersetze:
- Navigation → <a href="…"> mit echter URL.
- Aktion → <button type="button"> + Event-Handler.
Barrierefreiheit prüfen: Tastaturbedienung (Enter/Leertaste), Fokus, ARIA-Attribute.
SEO prüfen: Interne Linkstruktur intakt? Sitemap intern erreichbar?
Sicherheit prüfen: CSP aktiv? Keine Inline-Scripts im href mehr?

Vorher/Nachher-Beispiel


<a href="javascript:void(0)" onclick="openDialog();">Einstellungen</a>


<button type="button" id="open-settings" class="btn btn-link">Einstellungen</button>
<script>
  document.getElementById('open-settings').addEventListener('click', openDialog);
</script>

Moderne Verwendungen von void abseits von Links

Garantiert „undefined“: void 0 liefert immer undefined. Historisch relevant (als undefined noch überschreibbar war), heute vor allem stilistische oder minifizierungsbedingte Nutzung.
Promises bewusst „feuern“: In TS/ESLint-Setups wird void genutzt, um „no-floating-promises“-Regeln zu erfüllen:
```
onClick={() => { void doSomethingAsync(); }}
```
So signalisierst du explizit, dass du das Promise-Ergebnis ignorierst (z. B. Fire-and-Forget).
In Expressions: void als Teil komplexer Expressions zur Wertunterdrückung (sparsam und bewusst einsetzen).

Häufige Anti-Patterns und Missverständnisse

„Links sind besser für Klicks als Buttons“: Falsch. Für Aktionen sind Buttons semantisch korrekt und bieten die richtige Tastaturbedienung.
„href="#“ reicht“: Ohne event.preventDefault() scrollt die Seite nach oben. Und es ist semantisch weiterhin ein Link ohne Ziel.
„return false; ist gleichwertig zu preventDefault()“: Nicht ganz. preventDefault() ist explizit und robuster in komplexen Event-Ketten.
„Google folgt sowieso JS-Links“: Verlasse dich nicht darauf. Essenzielle Navigation gehört als echte href-Links in den DOM.

Code-Patterns: Do und Don’t

Do

// Aktion: Button + Event-Handler
<button type="button" id="save">Speichern</button>
<script>
  document.getElementById('save').addEventListener('click', saveData);
</script>

// Navigation: Link mit echtem Ziel
<a href="/profil">Zu meinem Profil</a>

// Hash-Router (falls genutzt):
<a href="#!/settings">Einstellungen</a>  // nur in Hash-basierten SPAs

Don’t

// Vermeiden
<a href="javascript:void(0)" onclick="saveData()">Speichern</a>

// Besser vermeiden oder nur mit preventDefault
<a href="#" onclick="saveData()">Speichern</a>

Leitfaden für konsistentes Verhalten (UX/a11y)

Sorge für sichtbaren Fokus (Focus-Ring nicht entfernen; oder via CSS gut sichtbar gestalten).
Nutze ARIA-Attribute nur, wenn nötig (z. B. aria-expanded, aria-controls für Toggles) – und halte sie konsistent aktuell.
Für „Pseudo-Links“ (Buttons im Link-Look) nutze CSS-Klassen wie btn btn-link oder minimale Styles (z. B. all: unset; plus Fokus-Styles).
Teste mit Tastatur und Screenreader (NVDA/JAWS/VoiceOver), nicht nur mit Maus.

Performance- und Wartungsaspekte

Trennung von Semantik und Verhalten: Klare DOM-Struktur (Link vs. Button) und Event-Delegation vereinfachen Performance-Optimierungen.
Wartbarkeit: Wegfall von javascript:-URIs reduziert Sonderfälle in Tests, Crawlern, Security-Scans und CSP-Konfigurationen.
Tooling-Kompatibilität: Linter und Formatierer arbeiten besser mit semantisch korrektem Markup und expliziten Event-Handlern.

Spickzettel: Wann ist Void(0) noch in Ordnung?

Bookmarklets: Ja. Beispiel: javascript:void(function(){ /* ... */ }())
Sonst im Produktcode: Nein. Nutze Button/Link + Event-Handler oder Router.
Als Sprachfeature: void ist okay, um bewusst undefined zu liefern oder Promises zu „feuern“ (z. B. void doAsync()).

Fazit

Void(0) steht für eine Ära, in der Entwickler Links als Allzweck-Klickziel missbraucht haben, um JavaScript-Aktionen ohne Navigation auszuführen. Technisch funktioniert es noch und wird in Bookmarklets weiterhin gebraucht. Aber für moderne Webanwendungen gilt: Setze auf korrekte Semantik – Buttons für Aktionen, Links für Navigation – und steuere Verhalten mit Event-Handlern statt mit javascript:-URIs. So profitierst du von besserer Barrierefreiheit, konsistenter UX, sauberer SEO, geringeren Sicherheitsrisiken und einfacherem Testing. Wenn du Legacy-Code migrierst, ist der Umstieg klar: weg von javascript:void(0), hin zu semantischen Elementen, event.preventDefault() wo nötig, und konsistenten ARIA-/Keyboard-Kontrakten.

FAQ

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

Ja. Die Klammern sind optional. void 0 ist eine gängige Kurzform und liefert ebenso undefined.

Warum wurde `javascript:void(0)` früher so oft verwendet?

Weil es eine einfache Möglichkeit bot, bei Klicks JavaScript auszuführen, ohne die Seite zu verlassen. Heute gibt es mit Buttons, Event-Handlern und besserer Semantik überlegene Alternativen.

Kann ich `href="#!"` anstelle von `javascript:void(0)` nutzen?

Nur wenn du einen Hash-basierten Router verwendest. Ansonsten ist es weiterhin semantisch ein Link ohne Ziel. Für reine Aktionen bleibe bei <button>.

Ist `return false;` eine gute Alternative zu `event.preventDefault()`?

Es funktioniert oft, ist aber weniger explizit und kann bei komplexer Event-Verkettung unerwartet sein. event.preventDefault() ist die klare, robuste Wahl.

Wie wirkt sich `javascript:void(0)` auf SEO aus?

Es gibt keine Ziel-URL, also tragen solche „Links“ nicht zum internen Linkgraphen bei. Für wichtige Navigation nutze echte <a href>-Links, idealerweise serverseitig gerendert.

Blockiert eine Content Security Policy `javascript:`-Links?

Strenge CSPs können javascript:-URIs blockieren, da sie als Inline-Skripte gelten. Das ist ein weiterer Grund, produktiv keine javascript:-Links zu verwenden.

Was ist der Unterschied zwischen `undefined` und `void 0`?

void 0 ist eine Ausdrucksform, die immer undefined ergibt. Historisch war undefined überschreibbar; heute ist das nicht mehr so. Du kannst undefined direkt verwenden, void 0 ist nur eine stilistische/kompatible Alternative.

Ist `void` in modernen Projekten noch sinnvoll?

Ja – als Sprachkonstrukt: z. B. um Promises als „Fire-and-Forget“ kenntlich zu machen (void doAsync()) oder gezielt undefined zu erzeugen. Als Teil von javascript:-Links solltest du es meiden.

Wie style ich Buttons wie Links?

Nutze CSS-Klassen (z. B. btn btn-link) oder minimalistische Styles (all: unset;, Textfarbe, Hover-, Fokus-States). Achte auf klaren Fokus und ausreichenden Kontrast.

Gibt es Fälle, in denen `<a role="button">` okay ist?

Nur wenn du aus Designgründen nicht umstellen kannst. Dann musst du Tastaturbedienung (Enter und Space), ARIA-Attribute und Fokus-Management selbst sicherstellen. Ein echter <button> ist in der Regel besser.

Wie teste ich, ob ich überall korrekte Semantik benutze?

Prüfe per Tastatur (Tab, Shift+Tab, Enter, Space), mit einem Screenreader, durch Linkprüfer (interner Linkgraph) und via Security-Scanner (keine javascript:-URIs). Ergänze Linting-Regeln gegen Inline-Handler und javascript:-Links.