javascript:void(0): What It Actually Does and When to Remove It

Learn what javascript:void(0) actually does, why it still appears in modern codebases, and when you should replace it with event.preventDefault() or a button.

Ekin Yalgın

April 29, 2026·7 min read

javascript:void(0): What It Actually Does and When to Remove It

The script-src directive in modern Content Security Policies immediately blocks javascript:void(0) executions, throwing console errors that break the user interface. Relying on this legacy pattern from the pre-ES5 era forces you to enable unsafe-inline, completely crippling your application's security posture.

Operator Result: Returns absolute undefined
Legacy Usage: Preventing default link navigation
Modern Security Risk: Fails CSP strict constraints and requires unsafe-inline
Minification Value: Saves 3 bytes over the word undefined
Modern Alternative: Semantic <button> elements or e.preventDefault()

Two Different Worlds: href vs. void 0

Developers often conflate two entirely separate technical concepts under the same umbrella. Placing href='javascript:void(0)' inside an HTML anchor tag is a DOM manipulation trick to prevent page reloads. Using void 0 in pure JavaScript code is a specific operator evaluation. Treating them as the same issue leads to messy refactoring and persistent security vulnerabilities. You need to separate the DOM anti-pattern from the core JavaScript behavior to clean up the codebase effectively.

This confusion is common in older codebases where JavaScript and HTML concerns were mixed together. The same era produced HTML5 AppCache, another pattern that seemed clever at the time and required the same kind of deliberate audit to remove later.

// Use case 1: href trick to stop link navigation (the DOM anti-pattern)
<a href="javascript:void(0)" onclick="openModal()">Click me</a>

// Use case 2: void 0 as undefined alias (the operator usage)
function isEmpty(value) {
  return value === void 0;
}

These two patterns look similar on the surface but have completely different roots and different fix strategies.

The Historical Difference Between 'void 0' and 'undefined'

The void operator evaluates any given expression and explicitly returns undefined. Writing void 0, void 1, or void 'hello' yields the exact same result. The execution phase completely ignores the integer or string provided.

The Global 'undefined' Problem Before ES5

Before the ECMAScript 5 specification in 2009, undefined was not a reserved keyword in JavaScript. Browsers allowed scripts to reassign the global undefined variable to any random value. A third-party script could easily set undefined = true, breaking all subsequent logic relying on strict equality checks across your application.

// Pre-ES5: this was actually possible
undefined = true;
console.log(undefined === true); // true -- global was overwritten

// void 0 always returned real undefined, regardless of global state
console.log(void 0 === undefined); // true -- safe even if undefined was reassigned

ES5 made the global undefined read-only, rendering this safety measure obsolete for modern development.

Why Modern Minifiers (Terser, UglifyJS) Still Use void 0

You might notice void 0 appearing in your production bundles even if you never wrote it in your source files. Build tools like Terser and UglifyJS actively replace the word undefined with void 0 during the minification process. The reason is purely mathematical and highly pragmatic. The word undefined consumes nine bytes of file size. The expression void 0 consumes only six bytes. Saving three bytes across thousands of variable checks significantly reduces the final payload size.

// Your source code
function checkValue(x) {
  return x === undefined;
}

// After Terser minification
function checkValue(x){return x===void 0}

This transformation is intentional, highly efficient, and perfectly safe for production environments. If you see void 0 in a .min.js or a dist/ file, leave it alone.

The Damage of Using href='javascript:void(0)' in Modern Web

Historical quirks justify the operator in minified scripts, but placing it directly inside HTML attributes creates massive technical debt.

CSP (Content Security Policy) and the unsafe-inline Vulnerability

Browsers treat javascript: URIs exactly like inline script tags. A strict Content Security Policy with a robust script-src directive automatically blocks these URIs to prevent Cross-Site Scripting attacks. Bypassing this block requires adding the unsafe-inline keyword to your server headers.

# A tight CSP policy -- javascript:void(0) breaks here
Content-Security-Policy: script-src 'self' 'nonce-abc123'

# What you'd have to add to make void(0) work -- bad trade-off
Content-Security-Policy: script-src 'self' 'unsafe-inline'

Enabling unsafe-inline completely invalidates the primary defense mechanism of your CSP. You expose the entire application to malicious payload injections just to stop a simple link from navigating.

Accessibility (A11y) and the Screen Reader Dead End

Screen readers process the DOM sequentially and announce the href attribute value to visually impaired users. A navigational element containing javascript:void(0) provides zero context about its destination or purpose. Users tabbing through the interface hear a meaningless string of technical jargon. This creates a confusing, inaccessible experience that directly violates basic Web Content Accessibility Guidelines.

What to Use Instead of javascript:void(0)

Removing the legacy syntax requires a fundamental shift in semantic HTML structure and event handling. You must align the element type with its actual user interaction.

The Semantic Approach: Link vs Button

HTML elements have distinct, built-in behaviors that browsers natively understand. If interacting with the element changes the URL or navigates to a new view, use an anchor <a> tag with a valid, descriptive href attribute. If interacting with the element triggers an action like opening a modal, submitting a form, or toggling a dropdown, use a <button> element. The same reasoning applies when structuring forms with nested or alternative HTML patterns: reach for the element that matches the intent, not the one that happens to render similarly.

<!-- Before: the legacy pattern -->
<a href="javascript:void(0)" onclick="openModal()">Open modal</a>

<!-- After: correct semantic HTML -->
<button type="button" onclick="openModal()">Open modal</button>

Buttons do not require href attributes and do not refresh the page by default when placed outside a form element. They are keyboard-accessible, screen-reader-friendly, and CSP-safe out of the box.

Using Event Listeners and e.preventDefault()

When you must keep an <a> tag for layout or styling reasons, handle the logic inside your JavaScript files instead of the HTML markup.

// Attach the listener in JS, keep the href meaningful or use #
document.querySelector('#my-link').addEventListener('click', function(e) {
  e.preventDefault();
  openModal();
});

// React pattern: button is preferred, but if you need <a>
function MyComponent() {
  const handleClick = (e) => {
    e.preventDefault();
    openModal();
  };
  return <a href="#" onClick={handleClick}>Open modal</a>;
}

This approach keeps your markup clean, satisfies strict security policies, and maintains a clear separation of concerns between structure and behavior.

How to Find javascript:void(0) in Your Codebase

Before you can fix it, you need to locate every instance. Run these from your project root:

# Find void(0) in all template and component files
grep -r "javascript:void" . --include="*.html" --include="*.jsx" --include="*.tsx" --include="*.vue"

# Find developer-written void 0 in source files (not dist)
grep -r "void 0" src/ --include="*.js" --include="*.ts"

For automated enforcement, add ESLint's no-script-url rule to your config. It flags javascript: URIs and prevents new ones from getting into the codebase:

{
  "rules": {
    "no-script-url": "error"
  }
}

Any void 0 that appears only in dist/ or build/ folders is minifier output. Skip those. Focus on src/ occurrences where a developer made the choice explicitly.

If you have hundreds of instances, prioritize by impact: fix href="javascript:void(0)" first since it breaks CSP enforcement and WCAG compliance. Operator-level void 0 in source files has no runtime effect and can wait for a dedicated cleanup pass.

Quick Decision Reference

Where you see void 0	What to do
Inside `href="javascript:void(0)"`	Replace with `<button>` or `e.preventDefault()`
In a minified bundle (`dist/`)	Leave it, minifier put it there
In source code as `undefined` check	Replace with `undefined` directly
In a bookmarklet	Acceptable, bookmarklets predate modern patterns

If the void 0 is in your source code and you are not writing a bookmarklet, replace it. If it is in a compiled output file, it belongs there and removing it would break the build.

The two things that keep javascript:void(0) alive in codebases are old Stack Overflow answers and copy-paste habits. Neither of those is a technical reason to keep it. Once you understand that the href trick fails CSP, breaks screen readers, and has a one-line replacement, the refactor becomes a short afternoon of grep and git commit.

FAQ

Frequently Asked Questions

It executes the void operator on the value 0, which always returns undefined. When placed in an href attribute, it tells the browser to run JavaScript instead of navigating to a URL, effectively stopping the link from doing anything.

No. Modern Content Security Policy headers block javascript: URIs by default. Making it work requires adding unsafe-inline to your CSP, which undermines your site's XSS protection. Use a button element or event.preventDefault() instead.

The href attribute of that anchor contains the literal string javascript:void(0). The browser displays whatever the href value is in the status bar. It means the link was written to prevent navigation rather than point to a real URL.

If the click triggers an action (modal, toggle, form submit), use a button element with type="button". If you must keep an anchor tag, attach a click event listener in JavaScript and call event.preventDefault() inside it.

Minifiers like Terser replace the word undefined (9 bytes) with void 0 (6 bytes) to save file size. This is intentional and safe since ES5 made the global undefined read-only. If you see void 0 in a dist file, leave it alone.

void is a unary operator that evaluates any expression and always returns undefined. void 0, void 1, and void 'anything' all produce the same result. Its main use today is in minifiers; in application code, writing undefined directly is clearer.

Slightly, because it does not conflict with Content Security Policy. But it still has problems: it scrolls the page to the top and adds an entry to browser history. The correct solution is a button element or a real URL in the href.

Published in

Web Development