void(0): o que é, para que serve e por que evitar no seu código

Se você já abriu o código-fonte de um site e encontrou algo como href="javascript:void(0)" dentro de um link, não está sozinho. É um dos trechos mais copiados e colados da história do front-end, e também um dos mais mal compreendidos: a maioria de quem usa sabe que “funciona”, mas poucos sabem exatamente por que funciona, e menos ainda sabem que ele carrega problemas reais de acessibilidade e SEO.

Este guia explica o que void(0) realmente é, por que ele aparece tanto em atributos href, o que muda em relação a usar apenas #, quais riscos técnicos ele traz e, principalmente, o que usar no lugar dele em cada situação. A ideia é sair daqui sabendo não só copiar a solução certa, mas entender o motivo por trás dela.

O que é void(0), tecnicamente

void é um operador da linguagem JavaScript, não uma função, ainda que os parênteses logo depois dele confundam quem está começando. Segundo a documentação oficial do MDN Web Docs, ele pega qualquer expressão colocada à sua direita, manda o motor JavaScript executá-la normalmente e, no fim, joga fora o resultado, entregando sempre undefined no lugar. Ou seja: o código roda de verdade, só o valor devolvido é descartado de propósito.

Na prática, essas três linhas fazem a mesma coisa:

void(0);
void 0;
void(minhaFuncao());

O (0) não tem nenhum poder especial. Poderia ser void(1), void("qualquer coisa") ou void(document.title) que o resultado seria sempre o mesmo: undefined. A convenção de usar 0 pegou porque é o valor mais curto e mais óbvio de digitar, não porque o número zero signifique algo para o interpretador.

Por que isso importa dentro de um link

O uso mais comum de void(0) aparece dentro do pseudo-protocolo javascript:, colado no atributo href de um elemento <a>:

<a href="javascript:void(0)">Clique aqui</a>

Quando o navegador encontra javascript: no href, ele interpreta o que vem depois dos dois-pontos como código JavaScript a ser executado, em vez de uma URL para navegar. Se esse código retornar algum valor diferente de undefined, o navegador tenta usar esse valor como o novo conteúdo da página, o que pode até apagar tudo o que estava na tela. É exatamente esse comportamento indesejado que void(0) evita: ao forçar o retorno para undefined, o navegador não faz nada com o resultado, e o link simplesmente não navega para lugar nenhum.

Em resumo, void(0) dentro de um href não é mágica. É um jeito de dizer ao navegador: “essa expressão vai rodar, mas por favor, ignore o que ela devolve”.

Por que o void(0) virou tão comum

Esse padrão surgiu de uma necessidade real do início dos anos 2000: elementos que precisavam de comportamento interativo (abrir um menu, disparar um modal, expandir um acordeão) mas que, visualmente, deveriam se parecer com um link. Como o elemento <a> já vinha com o estilo de link pronto e o cursor de “mãozinha” no CSS, virou hábito usá-lo para qualquer coisa clicável, mesmo quando não havia navegação nenhuma envolvida.

O problema é que o HTML exige um href para que o <a> seja focável pelo teclado e reconhecido como link por leitores de tela. Sem um destino real para apontar, href="javascript:void(0)" virou o preenchimento padrão: satisfaz o navegador, não navega para lugar nenhum e mantém a aparência visual esperada.

O hábito se espalhou tanto que ferramentas populares da época, como bibliotecas baseadas em jQuery, chegaram a usar esse padrão em exemplos oficiais de documentação, o que ajudou a consolidá-lo como “a forma certa de fazer” durante anos, mesmo sem ser.

void(0) vs. apenas #: qual a diferença

Outro padrão comum é usar só a cerquilha como valor do href:

<a href="#">Clique aqui</a>

Os dois evitam recarregar a página inteira, mas o comportamento não é idêntico:

Comportamento	href="#"	href="javascript:void(0)"
Rola a página para o topo	Sim, sempre	Não
Adiciona # na URL visível	Sim	Não
Aciona um evento de navegação	Sim (para uma âncora vazia)	Não
Some do histórico do navegador ao usar “voltar”	Pode gerar uma entrada extra	Não gera

Se a sua página é longa e o usuário está no meio dela, clicar num link com href="#" manda ele de volta ao topo, o que costuma ser um efeito colateral indesejado quando a intenção era só, por exemplo, abrir um menu suspenso. É por isso que void(0) ficou tão popular: ele evita esse salto brusco. Só que resolver esse sintoma com esse método específico cria outros problemas maiores, que valem a pena entender antes de copiar o padrão de novo.

Os problemas reais de usar javascript:void(0)

1. Acessibilidade prejudicada

Um link que não leva a lugar nenhum é, para um leitor de tela, um link quebrado. A pessoa ouve “link, clique aqui” e, ao ativá-lo, nada muda, sem nenhuma pista sobre o que deveria ter acontecido. As diretrizes de acessibilidade da web (WCAG), mantidas pelo W3C, tratam elementos interativos sem uma função de navegação real como candidatos a serem marcados de outra forma, justamente para não confundir tecnologias assistivas.

2. Falha ao clicar com o botão do meio ou Ctrl+clique

Um recurso básico de qualquer link é poder abri-lo em uma nova aba, seja com o botão do meio do mouse, seja segurando Ctrl (ou Cmd no Mac) ao clicar. Como não existe uma URL de verdade no href, esse comportamento simplesmente não funciona. Para o usuário, o link “quebra” de um jeito que ele nem sabe explicar direito.

3. Risco de segurança (XSS)

O time do MDN chega a recomendar, na própria página do operador, que se prefira anexar o comportamento por JavaScript separado (o padrão conhecido como unobtrusive event handlers) em vez de embutir código direto no href via javascript:. A razão prática é a seguinte: se o valor desse href for montado dinamicamente, por exemplo, concatenando um parâmetro que veio da URL, de um formulário ou de um campo preenchido por outro usuário, um atacante pode conseguir injetar o próprio JavaScript ali dentro. Como o navegador executa literalmente o que está depois de javascript:, esse trecho vira um vetor clássico de Cross-Site Scripting (XSS): o código malicioso roda no navegador de quem clicar, com todas as permissões daquela sessão.

4. Deixa de funcionar sob Content Security Policy (CSP)

Sites que adotam uma política de segurança de conteúdo mais rígida (o cabeçalho Content-Security-Policy, com a diretiva script-src sem unsafe-inline) bloqueiam por padrão qualquer link com href="javascript:...". Não existe uma exceção específica para isso: o navegador trata esse conteúdo como script inline, e script inline é exatamente o que uma CSP bem configurada existe para impedir. Na prática, um site protegido dessa forma pode simplesmente ignorar o clique em qualquer link void(0), sem erro visível no console para quem não sabe procurar. É mais um motivo técnico, além dos de acessibilidade e SEO, para tirar esse padrão do código antes que ele vire um bug silencioso.

5. Prejuízo real de SEO e rastreamento

Este é o ponto que mais interessa a quem cuida de um site pensando em tráfego orgânico. O Google e outros mecanismos de busca seguem links para descobrir e indexar páginas novas, um processo que depende de encontrar URLs válidas no atributo href. Um link com href="javascript:void(0)" não tem URL nenhuma para seguir, então, para efeitos de rastreamento, ele não existe.

Isso tem duas consequências práticas:

• Páginas ficam órfãs. Se a única forma de chegar a uma página do seu site é clicando em um link javascript:void(0) associado a um evento de JavaScript, o rastreador do Google pode nunca encontrar aquela página, o que compromete a indexação dela.
• A linkagem interna perde força. Parte da autoridade de uma página se distribui pelos links internos que apontam para outras páginas do mesmo site. Um link que não é um link de verdade, na visão do rastreador, não transmite nada disso, mesmo que visualmente pareça um link normal para quem está navegando.

Se você já revisou um site e encontrou menus, paginação ou categorias de produto usando esse padrão, vale investigar com uma auditoria de SEO: é um erro clássico que passa despercebido justamente porque, no navegador, tudo parece funcionar normalmente.

A única situação em que void(0) continua sendo uma boa escolha

Vale abrir uma exceção honesta aqui, porque nem tudo em torno de void(0) é problema: em bookmarklets (aqueles favoritos do navegador que guardam um trecho de JavaScript em vez de uma URL comum, executado na página aberta no momento), o próprio time do MDN recomenda envolver o código em void antes de salvá-lo como favorito.

O motivo é técnico e específico desse contexto: quando um javascript: digitado na barra de endereço ou salvo como favorito termina em uma expressão que devolve uma string, o navegador substitui a página inteira por esse texto, exatamente o comportamento indesejado que void(0) neutraliza dentro de um href. Como um bookmarklet não é markup permanente do seu site, mas um script pessoal que você mesmo aciona, os problemas de acessibilidade, rastreamento e CSP discutidos acima simplesmente não se aplicam:

javascript:void(document.body.style.filter='invert(1)')

A regra prática, então, não é “nunca use void(0)”, é mais específica: não use javascript:void(0) como valor de href em código de produção. Como ferramenta pontual de bookmarklet, ele continua cumprindo exatamente a função para a qual foi pensado.

O que usar no lugar, para cada situação

A escolha certa depende de uma pergunta simples: o elemento leva para algum lugar, ou ele só dispara uma ação na página atual?

Quando existe um destino real: use um link de verdade

Se clicar deve levar a outra página, ou até para outra seção da mesma página, o href precisa apontar para lá.

<!-- Errado -->
<a href="javascript:void(0)" onclick="location.href='/contato/'">Fale conosco</a>

<!-- Certo -->
<a href="/contato/">Fale conosco</a>

Isso garante rastreamento, indexação, abertura em nova aba e navegação sem depender de JavaScript estar carregado.

Quando a ação não navega: use um <button>

Se o clique só dispara uma função, como abrir um modal, expandir um acordeão ou enviar dados por uma chamada assíncrona, o elemento correto é o <button>, não o <a>. Botões já são focáveis, acionáveis pelo teclado (Enter e Espaço) e comunicam corretamente para leitores de tela que ali existe uma ação, não uma navegação.

<!-- Errado -->
<a href="javascript:void(0)" onclick="abrirModal()">Ver detalhes</a>

<!-- Certo -->
<button type="button" onclick="abrirModal()">Ver detalhes</button>

Se o visual precisa continuar parecendo um link de texto, dá para estilizar o <button> com CSS para remover a borda e o fundo padrão, mantendo a semântica correta por baixo:

button.link-estilizado {
  background: none;
  border: none;
  padding: 0;
  color: inherit;
  text-decoration: underline;
  cursor: pointer;
}

Quando você precisa impedir a navegação padrão de um link real

Às vezes o elemento é mesmo um <a> com destino, mas você quer capturar o clique em JavaScript antes de navegar, por exemplo, para validar um formulário ou registrar um evento de analytics. Nesse caso, o método correto é preventDefault(), chamado a partir do próprio evento:

<a href="/checkout/" id="btn-checkout">Finalizar compra</a>

document.getElementById('btn-checkout').addEventListener('click', function (event) {
  const formularioValido = validarFormulario();

  if (!formularioValido) {
    event.preventDefault();
    mostrarErro();
  }

  // Se o formulário for válido, o clique segue normalmente para /checkout/
});

Repare que o href continua apontando para uma URL real. O JavaScript só entra em ação para decidir, no momento do clique, se aquela navegação deve ou não ser cancelada. Isso é bem diferente de nunca ter um destino, como acontece com void(0).

Em frameworks modernos, o princípio é o mesmo

Trabalhando com React ou frameworks parecidos, a lógica não muda, só a sintaxe:

// Errado
<a href="javascript:void(0)" onClick={handleClick}>Ver mais</a>

// Certo, quando não há navegação
<button type="button" onClick={handleClick}>Ver mais</button>

// Certo, quando há navegação que pode ser interceptada
<a href="/produtos" onClick={(e) => {
  e.preventDefault();
  handleClick();
}}>Ver mais</a>

Em projetos com roteamento client-side, como os que usam o componente Link do Next.js ou o <a> nativo do Astro com View Transitions, o próprio framework já cuida de interceptar a navegação corretamente por baixo dos panos, então o href continua sendo uma URL de verdade o tempo todo, e não algo como void(0).

Checklist rápido para revisar seu código

• Procure por javascript:void(0), javascript:void 0 e href="#" combinados com onclick no seu HTML.
• Para cada ocorrência, pergunte: esse clique navega para algum lugar? Se sim, coloque a URL real no href. Se não, troque por <button>.
• Se o elemento precisa continuar visualmente parecido com um link, resolva isso com CSS, não trocando a tag por um <a> sem destino.
• Teste a navegação por teclado (Tab e Enter) e confira se o botão do meio do mouse consegue abrir links reais em nova aba.
• Se o site depende de menus ou categorias montados nesse padrão, rode uma checagem de rastreamento (o próprio Google Search Console mostra páginas que o Google não conseguiu encontrar) para confirmar que nada ficou órfão de link interno.
• Se o projeto usa (ou pretende usar) uma Content Security Policy restritiva, teste esses links com a CSP ativada: é comum descobrir cliques silenciosamente quebrados só nesse momento.

Perguntas frequentes sobre void(0)

O que void(0) faz de verdade?

É o operador void do JavaScript aplicado ao valor 0. Ele avalia a expressão e força o retorno para undefined, independentemente do valor original. Dentro de um href="javascript:...", isso impede que o navegador tente carregar algo diferente no lugar da página atual.

void(0) e void 0 são a mesma coisa?

Sim. Os parênteses são só estilo de escrita; o operador void funciona igual com ou sem eles. void(0), void 0 e até void("qualquer valor") retornam sempre undefined.

Por que não simplesmente usar href=”#”?

Porque href="#" rola a página até o topo e ainda gera uma entrada extra no histórico de navegação, dois efeitos colaterais que a maioria dos casos de uso não quer. O problema é que a solução comum para isso, void(0), resolve esse sintoma criando problemas maiores de acessibilidade e SEO.

javascript:void(0) prejudica o SEO do site?

Pode prejudicar, sim, principalmente quando é a única forma de acesso a uma página. Rastreadores como o do Google seguem URLs reais encontradas em atributos href; um link sem URL de verdade não é seguido, o que pode deixar páginas fora do índice e enfraquecer a linkagem interna do site.

Qual é a alternativa correta para um menu suspenso ou acordeão?

Um <button>, não um <a>. Esses elementos não levam a lugar nenhum, então a tag semanticamente correta é a de botão, que já vem com foco por teclado e leitura correta por tecnologias assistivas.

E se eu precisar cancelar a navegação de um link de verdade?

Use event.preventDefault() dentro do listener de clique daquele link, mantendo um href com uma URL real. Isso permite cancelar a navegação condicionalmente sem abrir mão de nenhuma das vantagens de um link verdadeiro.

Trocar void(0) por button muda o visual do site?

Não precisa mudar. Um <button> pode ser estilizado em CSS para se parecer exatamente com um link de texto (sem borda, sem fundo, com sublinhado), mantendo por baixo a semântica correta.

Existe algum caso em que usar javascript:void(0) continua correto?

Sim, em bookmarklets: scripts salvos como favorito do navegador e disparados manualmente por quem os criou. Fora desse contexto pessoal e pontual, especialmente como valor de href em páginas de produção, não há cenário em que ele seja a melhor escolha.

void(0) para de funcionar se o site tiver uma Content Security Policy?

Sim. Com uma CSP que restringe script-src sem a diretiva unsafe-inline, o navegador bloqueia por padrão qualquer href="javascript:...", tratando-o como script inline. O clique simplesmente não faz nada, sem erro visível para quem não sabe onde procurar.

Conclusão

void(0) não é um erro de sintaxe nem um recurso exótico do JavaScript: é um operador simples, que sempre retorna undefined, usado historicamente para neutralizar o comportamento do pseudo-protocolo javascript: dentro de um href. O problema nunca foi o operador em si, e ele continua tendo um lugar legítimo em bookmarklets. O problema é o hábito de usá-lo para remendar um elemento <a> sem destino real dentro do código de produção, em vez de escolher a tag certa para cada situação: link de verdade quando há navegação, botão quando há só uma ação, e preventDefault() quando é preciso interceptar um clique sem abrir mão do link.

Corrigir esse padrão no seu código deixa o site mais acessível, mais seguro contra injeção de script e, o que mais pesa no dia a dia de quem depende de tráfego orgânico, mais fácil de ser rastreado e indexado corretamente pelo Google.

Se você quer confirmar se o seu site tem esse tipo de link “invisível” para os buscadores, o SEO técnico é o caminho mais direto para mapear isso e outros pontos de rastreamento e indexação.

Referências

• MDN Web Docs. “void operator”. Documentação oficial do operador void, incluindo a recomendação contra o uso do pseudo-protocolo javascript: em favor de manipuladores de evento discretos.

• Google Search Central. “Como o Google descobre, rastreia e serve páginas”. Explica como o Googlebot encontra páginas novas seguindo links, e por que um link sem URL real não é rastreado.

• W3C Web Accessibility Initiative (WAI). “Understanding WCAG”. Diretrizes sobre foco por teclado, semântica de elementos interativos e o motivo pelo qual links e botões devem ser usados de acordo com sua função real.

• Content-Security-Policy.com. “script-src”. Referência técnica confirmando que links href="javascript:..." são bloqueados por padrão sob uma Content Security Policy, sem exceção fora de unsafe-inline.