JavaScript Void(0): Definition, Einsatz, Alternativen und Best Practices

Wenn du in HTML-Ankern href="javascript:void(0)" siehst, geht es darum, die Navigation zu unterdrücken und trotzdem JavaScript auszuführen. In diesem Leitfaden erfährst du präzise, wie Void(0) technisch funktioniert, warum es historisch so verbreitet war, welche Stolperfallen es mitbringt, welche modernen Alternativen du heute bevorzugen solltest – und wie du Legacy-Code sauber refaktorst.

Was der `void`-Operator in JavaScript wirklich macht

Kurzfassung: Der unäre Operator void wertet einen Ausdruck aus und gibt immer undefined zurück – unabhängig vom Ergebnis des Ausdrucks.

Die Syntax ist schlicht: void expression. Du nutzt ihn, wenn dich das Ergebnis eines Ausdrucks nicht interessiert, aber seine Nebenwirkungen (z. B. ein Funktionsaufruf) stattfinden sollen. Typische Schreibweisen sind void(0) oder void 0 (gleichbedeutend, letztere ist nur etwas kürzer).

Ergebnis ist garantiert undefined: console.log(void(42) === undefined); // true
Side-Effects bleiben erhalten: void doSomething(); ruft die Funktion auf und verwirft deren Rückgabe.
Historischer Nutzen: Früher konnte undefined überdeckt werden; void 0 blieb verlässlich. Heute ist undefined in modernen Umgebungen zuverlässig nicht überschreibbar, trotzdem bleibt void als „garantierte Rückgabe von nichts“ semantisch eindeutig.

Operator-Priorität verstehen

void hat eine klare Priorität. Klammern helfen, Missverständnisse zu vermeiden:

// Wird als (void 2) === '2' ausgewertet:
void 2 === '2' // false

// Mit Klammern:
void (2 === '2') // undefined

Merke dir: Du willst in aller Regel void(...) mit Klammern – besonders in zusammengesetzten Ausdrücken.

`javascript:`-URL-Schema + `void(0)`: Warum das so oft zusammen vorkommt

Das Pseudo-Protokoll javascript: sagt dem Browser: „Führe den folgenden Code aus, statt zu navigieren.“ Dabei gilt die Eigenheit: Wenn der Ausdruck einen Wert zurückliefert, kann der Browser die aktuelle Seite durch diesen Rückgabewert (als HTML) ersetzen. Gibst du aber undefined zurück, bleibt die Seite wie sie ist. Genau hier setzt Void(0) an.

Typische Verwendung in Legacy-Code:

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

Der Link ist fokussierbar, klickbar und löst JavaScript aus.
Die Seite wird nicht neu geladen, weil void(0) undefined zurückgibt.

Wichtig: Dass der Browser die Seite nicht ersetzt, ist ein Nebeneffekt des undefined-Rückgabewerts. Sobald du hingegen einen String zurückgibst, riskierst du ein ungewolltes „Seite-ersetzen“-Verhalten.

Typische Anwendungsfälle – und warum sie historisch Sinn ergaben

Interaktive „Links“ ohne Navigation: UI-Elemente sollten wie Links aussehen, aber nur Aktionen triggern.
Platzhalter in der Entwicklung: Ein Link klickbar machen, bevor die echte URL feststeht.
AJAX-Interaktionen: Aktionen ausführen, ohne umzuladen (vor dem großen Durchbruch von SPA-Frameworks).
Bookmarklets: Als Lesezeichen gespeicherte Mini-Skripte, die im aktuellen Kontext laufen.

Damals gab es noch keine etablierten Muster wie saubere Event-Listener, semantische Buttons mit CSS-Styling oder robuste Frontend-Architekturen. javascript:void(0) war ein pragmatischer Weg, klickbare Elemente zu bauen, die auf der Seite verbleiben.

Warum du heute in der Regel auf `javascript:void(0);` verzichten solltest

Moderne Frontend-Entwicklung setzt auf semantisches HTML, klare Trennung von Struktur und Verhalten, starke Barrierefreiheit (A11y) und saubere Event-Architektur. javascript:-URLs und Void(0); stehen dem oft entgegen.

Semantik: Links (<a>) sind für Navigation. Aktionen gehören auf Buttons (<button>).
Zugänglichkeit: Screenreader und Tastaturnutzer profitieren von korrekter Semantik. Ein scheinbarer Link, der nur handelt statt zu navigieren, ist irritierend.
SEO: Links, die keine echten Ziele haben, tragen nichts zur internen Verlinkung bei und können die Crawlbarkeit verwässern.
Wartbarkeit: Inline-Handler und javascript:-URLs verteilen Logik ins Markup – das erschwert Testbarkeit, CSP-Konformität und Refactoring.
Sicherheit/CSP: Strikte Content Security Policies können die Ausführung von javascript:-URLs verhindern. Das ist gewollt – und ein weiterer Grund, das Muster zu meiden.

Best Practice heute: Nutze Buttons für Aktionen. Trenne Event-Handling vom Markup. Navigations-Links haben echte href-Ziele.

Moderne Alternativen – konkret und praxistauglich

1) Button statt Link

Wenn keine Navigation stattfinden soll, verwende ein <button>. Das ist semantisch korrekt, zugänglich und robust.

<button type="button" id="openSearch" aria-controls="site-search" aria-expanded="false">
  Suche öffnen
</button>

<div id="site-search" hidden>... Suchformular ...</div>

<script>
  const btn = document.getElementById('openSearch');
  const panel = document.getElementById('site-search');
  btn.addEventListener('click', () => {
    const open = btn.getAttribute('aria-expanded') === 'true';
    btn.setAttribute('aria-expanded', String(!open));
    panel.hidden = open;
  });
</script>

Pro: Richtige Tastatur-Semantik (Space/Enter), A11y-Attribute, klare Verantwortung.
Kontra: Wenn du „Link-Look“ willst, style den Button mit CSS statt semantisch falsche Anker zu verwenden.

Siehe auch Die besten Tipps, wie du unnötige Apps vom MacBook entfernst

2) Echte Links mit Event-Handling – nur wenn Navigation optional ist

Wenn ein Link standardmäßig navigieren soll, aber du die Navigation in bestimmten Fällen unterdrückst, arbeite mit Event-Listenern und preventDefault():

<a href="/berichte" id="reportsLink">Berichte</a>

<script>
  const link = document.getElementById('reportsLink');
  link.addEventListener('click', (e) => {
    if (shouldIntercept()) {
      e.preventDefault();     // Standardaktion unterbinden
      loadReportsAjax();      // Alternative Aktion
    }
  });
</script>

So bleibt die Semantik erhalten, Fallbacks existieren, und deine App bleibt robust (Progressive Enhancement).

3) Kein `href="#"` als „Fake-Link“

href="#" führt oft dazu, dass die Seite nach oben scrollt, wenn preventDefault() nicht greift (z. B. bei deaktiviertem JS). Auch Varianten wie #0 oder #! sind Krücken. Nutze stattdessen Buttons für Aktionen – oder gib einem Link ein sinnvolles Ziel.

4) `return false` richtig verstehen

Inline-Handler: <a onclick="doX(); return false"> verhindert die Standardaktion des Elements.
DOM-Listener: Bei addEventListener hat return false keine Wirkung. Du musst event.preventDefault() und ggf. event.stopPropagation() aufrufen.
jQuery: return false entspricht dort preventDefault() + stopPropagation().

Empfehlung: Nutze moderne Listener und rufe gezielt die gewünschten Methoden auf:

el.addEventListener('click', (e) => {
  e.preventDefault();   // wenn nötig
  e.stopPropagation();  // nur falls du Bubbling explizit unterbinden willst
});

Fehlerdiagnose: Wenn „javascript:void(0)“ nichts tut

In der Praxis melden Nutzer manchmal „javascript:void(0) funktioniert nicht“. Häufige Ursachen und Lösungen:

JavaScript ist deaktiviert: Prüfe die Browser-Einstellungen, aktiviere JavaScript.
Script-/Content-Blocker aktiv: Erweiterungen wie Script-Blocker oder strenge Privacy-Tools verhindern die Ausführung. Whitelisten oder testweise deaktivieren.
Strikte Content Security Policy (CSP): javascript:-URLs gelten als Inline-Ausführung und können blockiert sein. Lösung: Entferne javascript:-URLs und nutze Event-Listener.
Fehler im Code: Öffne die DevTools-Konsole (F12) und prüfe Fehlermeldungen. Ein JavaScript-Error vor dem onclick verhindert die Ausführung.
Proxy/Netzwerkprobleme: Fehlkonfigurationen in Proxys oder captive Portals können Skripte/Assets blockieren. Teste ein anderes Netzwerk.
Cache/Kookies: Veraltete Dateien im Cache oder korrupte Cookies können zu merkwürdigen Effekten führen. Leere Cache und Cookies.
Seiten-Bugs: Das Problem kann serverseitig/seitenspezifisch sein. Teste eine frische Seite oder ein anderes Profil.

Langfristige Lösung: Entferne javascript:-URLs aus dem Code und stelle auf semantische, eventgesteuerte Muster um.

Vergleich: Patterns im Überblick

Pattern	Semantik	A11y	SEO	CSP-Kompat.	Beispiel	Empfehlung
`href="javascript:void(0)"`	Link ohne Ziel	Problematisch	Kein Mehrwert	Oft geblockt	`<a href="javascript:void(0)">`	Vermeiden
`<button type="button">`	Korrekt für Aktionen	Sehr gut	Nicht relevant	Sehr gut	`<button id="x">`	Bevorzugt
Echter Link + `preventDefault()`	Navigation optional	Gut	Gut	Sehr gut	`<a href="/ziel">`	Empfohlen, wenn Navigation vorgesehen
`href="#"/"#0"/"#!`	Künstlich	Inkonsistent	Neutral	OK	`<a href="#">`	Nur mit Sorgfalt; besser Button
`return false` in Inline-Handlern	Vermischt Logik & Markup	OK	Neutral	Schwach (inline)	`<a onclick="...;return false">`	Legacy, besser modernisieren

Technische Details zu `void` und undefined

void verwirft Werte und liefert garantiert undefined.
undefined als globale Eigenschaft war in sehr alten JS-Umgebungen überschreibbar; heute ist es schreibgeschützt. Historisch war void 0 daher eine sichere Referenz auf undefined.
Kurzschreibweise: void 0 statt void(0) – beide gleichbedeutend. In minifiziertem Code sieht man häufig void 0.

// Beispiele
void (1 + 1);        // undefined
void alert('Hi');    // zeigt Alert, Rückgabe wird verworfen (undefined)
console.log(void 0); // undefined

Barrierefreiheit (A11y) und Eingabeverhalten: Link vs. Button

Für Nutzerinnen und Nutzer mit Screenreadern und Tastaturen ist die richtige Semantik entscheidend:

Links: Aktivierung mit Enter, Erwartung: führt zu einer anderen Ressource.
Buttons: Aktivierung mit Enter und Leertaste, Erwartung: führt eine Aktion aus.

Siehe auch Steam achievement manager

Wenn du aus Designgründen einen Button wie einen Link aussehen lassen willst, style ihn mit CSS – ändere aber nicht seine Semantik. Vermeide role="button" auf <a>, außer du bist zu 100 % sicher, auch die gesamte Tastaturlogik korrekt zu polyfillen (inkl. Space/Enter, Fokus-Management, ARIA-States). Der Aufwand lohnt selten; nutze stattdessen gleich einen Button.

SEO-Überlegungen

Links ohne Ziel tragen nicht zur internen Verlinkung bei.
Suchmaschinen folgen javascript:-URLs nicht zuverlässig, der Linkjuice verpufft.
Bessere Wahl: Echte href-Ziele für Navigation, Buttons für reine Aktionen.

Security und Policies

Content Security Policy (CSP): javascript:-URLs gelten wie Inline-Skripte; eine restriktive CSP (script-src ohne 'unsafe-inline') kann deren Ausführung blockieren.
Audits/Compliance: Tools und Security-Guidelines werten javascript:-URLs oft als Anti-Pattern.
Empfehlung: Löse Logik über JavaScript-Dateien und Event-Listener, nicht über URL-Schemata.

„Void“ in anderen Sprachen – und warum dich das interessiert

Das Konzept „kein Wert“ gibt es auch außerhalb von JavaScript:

C/C++: void als Rückgabetyp von Funktionen ohne Rückgabewert; void* als generischer Pointer.
Java: void markiert Methoden ohne Rückgabewert.

Der Grundgedanke ist ähnlich: Diese Operation liefert keinen sinnvollen Wert zurück. In JavaScript ist void ein Operator, der genau diese Absicht ausdrückt – unabhängig vom eigentlichen Ausdrucksresultat.

Checkliste: Best Practices für heutige Projekte

Nutze Buttons für Aktionen, Links für Navigation.
Kopple Event-Listener über addEventListener, nicht über Inline-Handler.
Verwende preventDefault() gezielt, wenn du Standardaktionen unterdrücken willst.
Stelle sicher, dass Tastatursteuerung (Enter/Space), Fokus und ARIA-Attribute korrekt sind.
Vermeide href="javascript:void(0)", href="#" und ähnliche Krücken.
Denke an CSP und Security: keine javascript:-URLs einsetzen.
Für Navigation: echte Ziele im href; für SPAs: sauberes Router-Handling.
Teste mit JS deaktiviert (Progressive Enhancement), wenn die Seite auch ohne JS funktionieren soll.

Refactoring: So ersetzt du `javascript:void(0)` in Legacy-Code

Finde alle Vorkommen von href="javascript:…" (Suche im Code). Dokumentiere, welche davon Navigation vortäuschen und welche echte Navigation implementieren sollten.
Kategorisiere nach Absicht:
- Reine Aktionen → Umstellen auf <button type="button">.
- Optionale Navigation → Echte href-Ziele, Abfangen via preventDefault(), wenn nötig.
Extrahiere Inline-Logik in modulare JS-Funktionen. Verknüpfe sie über addEventListener.
Implementiere A11y: aria-* für Zustände, Fokusmanagement bei geöffneten Panels/Modals, Tastatursteuerung.
Härte mit CSP ab (keine Inline-Skripte, keine javascript:-URLs). So erkennst du Reststellen früh.
Testen: Tastatur, Screenreader, ohne JS, mit langsamen Netzwerken, auf Mobilgeräten.

Beispiel-Refactoring eines „Fake-Links“:

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

<!-- Nachher -->
<button type="button" id="menuToggle" aria-expanded="false" aria-controls="mainMenu">Menü</button>
<nav id="mainMenu" hidden>...</nav>

<script>
  const t = document.getElementById('menuToggle');
  const m = document.getElementById('mainMenu');
  t.addEventListener('click', () => {
    const open = t.getAttribute('aria-expanded') === 'true';
    t.setAttribute('aria-expanded', String(!open));
    m.hidden = open;
  });
</script>

Praxisnahe Code-Muster

Bookmarklet mit `void(0)` (sinnvoller Einsatz)

javascript:(function(){ alert('Seiten-Titel: ' + document.title); void(0); })();

Bei Bookmarklets ist void(0) legitim, um sicherzustellen, dass kein „Ergebnis-HTML“ die Seite ersetzt. Moderne Projekte im DOM hingegen sollten darauf verzichten.

Explizites Verwerfen einer Rückgabe (Lesbarkeit)

// Du willst eine Funktion nur wegen ihres Side-Effects aufrufen
void logAnalyticsEvent('nav:open'); // Ergebnis egal, Semantik klar

Das ist optional, erhöht aber die Lesbarkeit: „Rückgabewert ist bewusst egal“.

Siehe auch Arcor Mail richtig einrichten: Server, Sicherheit, Clients und Troubleshooting

Häufige Anti-Patterns – und bessere Lösungen

Anti-Pattern: <a href="javascript:void(0)" onclick="doX()">
Besser: <button type="button" id="x"> + addEventListener
Anti-Pattern: <a href="#" role="button"> ohne vollständige Tastaturlogik
Besser: <button> verwenden; wenn absolut nötig, vollständige Key-Events (Enter/Space) implementieren
Anti-Pattern: return false in DOM-Listenern erwarten
Besser: event.preventDefault() und event.stopPropagation() gezielt verwenden

Fazit

Void(0) ist technisch gesehen ein klar definierter Operator, der immer undefined liefert und historisch eine sinnvolle Rolle in Verbindung mit dem javascript:-URL-Schema spielte. In modernen Webanwendungen ist diese Kombination jedoch kaum noch angebracht. Sie unterminiert Semantik, Barrierefreiheit, SEO, Wartbarkeit und kann von Sicherheitsrichtlinien blockiert werden.

Setze stattdessen auf:

Buttons für Aktionen (mit sauberem Event-Handling und A11y),
echte Links für Navigation (ggf. bedarfsweise abgefangen),
klare Trennung von Markup und Logik (Event-Listener statt Inline-Handler),
und robuste Policies (CSP) für eine sichere, wartbare Codebasis.

Für Legacy- und Spezialfälle (etwa Bookmarklets) kann void(0) weiterhin nützlich sein. Für neue Projekte sollte es jedoch nicht dein Werkzeug der Wahl sein.

FAQ

Was bedeutet `void(0)` genau?

Es wertet den Ausdruck 0 aus und gibt garantiert undefined zurück. Damit wird der Rückgabewert verworfen. In Kombination mit javascript:-URLs verhindert das, dass der Browser die Seite durch ein Rückgabe-HTML ersetzt.

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

Ja. void 0 ist nur kürzer. Beide liefern undefined.

Warum ist `href="javascript:void(0)"` problematisch?

Es ist semantisch ein Link ohne Ziel, erschwert Barrierefreiheit und Wartbarkeit, bringt keinen SEO-Nutzen, kann durch CSP blockiert werden und vermischt Logik mit Markup. Moderne Alternativen sind Buttons und Event-Listener.

Kann ich stattdessen `href="#">` nehmen?

Davon ist abzuraten. Ohne preventDefault() springt die Seite nach oben. Es bleibt ein Link ohne echtes Ziel – ein Anti-Pattern. Nutze Buttons für Aktionen.

Wann ist `void(0)` noch sinnvoll?

In Bookmarklets, damit die Seite nicht durch einen Rückgabewert ersetzt wird. Im normalen DOM deiner App ist es selten notwendig.

Wie unterscheidet sich `return false` von `event.preventDefault()`?

Bei Inline-Handlern verhindert return false die Standardaktion. In addEventListener-Handlern hat es keine Wirkung – hier brauchst du event.preventDefault(). In jQuery bewirkt return false sowohl preventDefault() als auch stopPropagation().

Bringt die Nutzung eines Buttons wirklich A11y-Vorteile?

Ja. Buttons sind für Aktionen gedacht, unterstützen Enter/Space out of the box, und Screenreader interpretieren sie korrekt. Du musst keine eigene Tastaturlogik nachrüsten.

Warum ersetzte der Browser früher manchmal die Seite bei `javascript:`-Links?

Weil das Ergebnis der javascript:-Auswertung als Dokumentinhalt interpretiert werden kann, wenn es kein undefined ist. void(0) sorgt für undefined und verhindert so dieses Verhalten.

Was ist mit SEO, wenn ich `javascript:void(0)` nutze?

Solche Links liefern keinen Mehrwert für die interne Verlinkung. Für Navigation solltest du echte Ziele verwenden. Für reine Aktionen sind Buttons die bessere Wahl.

Wie modernisiere ich ein großes Projekt mit vielen `javascript:void(0)`-Links?

Identifiziere die Absicht je Link (Aktion vs. Navigation), ersetze Aktions-Links durch Buttons, verschiebe Inline-Logik in JS-Module, nutze Event-Listener, füge A11y-Attribute hinzu und härte mit einer CSP nach. Teste Tastatursteuerung und Screenreader.

Ist die Nutzung von `void` ohne `javascript:`-URLs sinnvoll?

Ja, wenn du explizit zeigen willst, dass ein Rückgabewert verworfen wird (Lesbarkeit) oder in Edge-Cases wie Bookmarklets. In der Regel ist es aber nicht nötig; schreibe einfach klaren Code mit gut benannten Funktionen.

Was der void-Operator in JavaScript wirklich macht

Operator-Priorität verstehen

javascript:-URL-Schema + void(0): Warum das so oft zusammen vorkommt

Typische Anwendungsfälle – und warum sie historisch Sinn ergaben

Warum du heute in der Regel auf javascript:void(0); verzichten solltest

Moderne Alternativen – konkret und praxistauglich

1) Button statt Link

2) Echte Links mit Event-Handling – nur wenn Navigation optional ist

3) Kein href="#" als „Fake-Link“

4) return false richtig verstehen

Fehlerdiagnose: Wenn „javascript:void(0)“ nichts tut

Vergleich: Patterns im Überblick

Technische Details zu void und undefined

Barrierefreiheit (A11y) und Eingabeverhalten: Link vs. Button

SEO-Überlegungen

Security und Policies

„Void“ in anderen Sprachen – und warum dich das interessiert

Checkliste: Best Practices für heutige Projekte

Refactoring: So ersetzt du javascript:void(0) in Legacy-Code

Praxisnahe Code-Muster

Bookmarklet mit void(0) (sinnvoller Einsatz)

Explizites Verwerfen einer Rückgabe (Lesbarkeit)

Häufige Anti-Patterns – und bessere Lösungen

Fazit

FAQ

Was bedeutet void(0) genau?

Ist void 0 dasselbe wie void(0)?

Warum ist href="javascript:void(0)" problematisch?

Kann ich stattdessen href="#"> nehmen?

Wann ist void(0) noch sinnvoll?

Wie unterscheidet sich return false von event.preventDefault()?