voltar à visão geral Mais artigos

Sites Detectam o Inspecionar Elemento e o DevTools Aberto?

Questionável
Abra o DevTools (F12) e veja esta página perceber

Tudo roda no seu navegador e nada é enviado. Abra o DevTools, edite o preço, aperte o botão.

Últimos eventos registrados pela página

  • nada ainda

O que esta página consegue captar

  • Painel acoplado (diferença de tamanho da janela) aguardando
    acople o DevTools na lateral ou embaixo
  • Custo do console (tempo) aguardando
    abra o DevTools (F12), qualquer painel, qualquer posição de acoplamento
  • Tempo do debugger aguardando
    abra o DevTools e depois aperte o botão abaixo
  • Edições na página aguardando
    inspecione o preço abaixo e edite o texto dele
  • Atalhos e clique direito aguardando
    aperte F12 ou clique com o botão direito nesta página
Preço: $49.00

Clique com o botão direito no preço, escolha Inspecionar e edite o texto. O botão executa uma instrução debugger: com o DevTools aberto, a página trava até você apertar Retomar (F8).

O que nenhum evento informa

  • Qual elemento você escolheu com Inspecionar invisível
  • Qual painel você está lendo (Rede, Origens, …) invisível
  • Que uma aba de view-source foi aberta invisível

As contagens ficam na memória e somem quando você fecha a aba. O widget só observa: nunca bloqueia um atalho nem esconde nada de você.

Você apertou F12 e a página ficou em branco. Ou mandou você de volta para a home, ou travou atrás de um aviso “Pausado no depurador”, ou exibiu “developer tools detected” e parou de carregar. De qualquer forma, o site percebeu, e nenhum evento avisou.

Os scripts de uma página não recebem sinal nenhum quando você abre o DevTools, escolhe um elemento ou lê um painel. O que eles conseguem é notar o que um DevTools aberto faz com a página. O widget desta página roda essas verificações no seu próprio navegador, então abra o DevTools agora e veja a reação.

Versão resumida: nenhum script de página é avisado de que você inspecionou alguma coisa. Os scripts deduzem que o DevTools está aberto a partir de efeitos colaterais: um painel acoplado encolhe a página, o console fica mais lento para registrar, uma instrução debugger trava a página enquanto o relógio continua correndo. Para duas dessas três existe um jeito barato de contornar (desacoplar o painel, desativar os pontos de interrupção). A medição de tempo do console não tem nenhum desses atalhos, e dispara também no Puppeteer. Nada disso identifica uma pessoa, e as verificações do widget rodam inteiramente no seu navegador.

Um site consegue ver você usar o Inspecionar Elemento?

Não pelos scripts. Os navegadores não disparam nenhum evento de “DevTools aberto”, e escolher um elemento ou ler um painel não diz nada à página. O servidor ainda enxerga as requisições comuns. Ver o código-fonte é uma requisição simples da página ou uma leitura do seu cache, e o Chrome busca os source maps de um site quando o DevTools abre, então um servidor que os publica pode registrar isso. Ele nunca fica sabendo qual elemento você escolheu nem qual painel você leu.

Editar uma página no Inspecionar Elemento não muda nada para mais ninguém. Você altera a cópia mantida na sua aba, a cópia do servidor continua intacta, e recarregar a página traz o original de volta. A página pode perceber que um dos seus elementos mudou, porque um MutationObserver registra edições assim como mudanças comuns no DOM. Confirmei isso para edições de texto e de atributos no Chrome, e o registro não diz nada sobre quem fez a mudança. Experimente com o preço no widget: clique nele com o botão direito, escolha Inspecionar, edite o texto. O diagrama mostra em qual cópia a mudança acontece.

Qual cópia você editou?
O servidor do site
$49.00
o que a loja vai cobrar
Seu navegador, esta aba
$49.00
uma cópia da página, mantida na memória
O MutationObserver da própria página nada mudou ainda
Uma simulação do que uma edição no painel Elementos (Elements) faz. Ela altera a cópia na sua aba. A página pode perceber que os próprios elementos mudaram, mas não que foi o DevTools, e o servidor continua cobrando $49.00. Recarregar descarta a edição.

Como uma página percebe que o DevTools está aberto

Três dos truques funcionam do mesmo jeito. A página não consegue perguntar “o DevTools está aberto?”, então monta uma medição e espera por um efeito colateral. É a mesma ideia da detecção de bloqueadores de anúncio: a página não enxerga a ferramenta, então mede o que a ferramenta muda.

A diferença de tamanho da janela. Acoplar o DevTools na lateral ou embaixo tira espaço da página, então window.outerWidth - window.innerWidth (ou o equivalente na altura) dá um salto. Os scripts tratam como sinal uma diferença de uns 160 a 170 pixels. No meu Windows 11, acoplar o DevTools à direita levou a diferença de largura de 14 para 569 pixels, e desacoplá-lo trouxe a diferença de volta a 14. A verificação dispara por engano quando você dá zoom na página ou abre uma barra lateral. A biblioteca mais conhecida para isso, o devtools-detect, foi arquivada em maio de 2026, e o README dela admite que o método gera muitos falsos positivos.

O custo do console. O truque clássico manda ao console um objeto com um getter e espera para ver se o console o lê. Muitas respostas antigas ainda o descrevem, e ele não dispara mais no Chrome atual: no meu teste no Chrome 155 para Windows, um getter em Error.stack e outro no id de um elemento ficaram em silêncio com o DevTools aberto. Outras variantes, como um toString personalizado, disparam com o DevTools aberto ou não, então não dizem nada.

O que ainda aparece é o tempo. Registrar no log é quase de graça até que um cliente de console seja anexado, e então o Chrome precisa montar uma prévia de cada objeto. Quarenta chamadas de console.debug com um objeto de 40 chaves levaram menos de um milissegundo com o DevTools fechado e alguns milissegundos com ele aberto, um salto de cerca de dez vezes na minha máquina. Não fez diferença o painel estar acoplado ou em janela própria. O mesmo salto apareceu com uma sessão avulsa do Chrome DevTools Protocol, sem mais nada, que é o que o Puppeteer e o Playwright abrem por padrão. Uma página que cronometra o próprio log e compara com uma linha de base percebe. A verificação também não distingue um desenvolvedor de um script, e é por isso que a detecção de bots usa esse sinal. Não testei Firefox nem Safari.

A instrução debugger. Sem o DevTools, ela não faz nada. Com o DevTools aberto e os pontos de interrupção ativos, ela trava a página até você apertar Retomar. Um script lê o relógio antes e depois, e um intervalo acima de uns 100 ms é lido como pausa. Os scripts entendem isso como alguém olhando, embora uma aba limitada pelo navegador ou uma máquina lenta possam simular o mesmo efeito. É também o aviso “Pausado no depurador”. O botão do widget a executa uma vez para você sentir.

O vigia de edições. O quarto sinal não é uma verificação de DevTools. É o MutationObserver da seção acima, apontado para o que um script quer proteger, como um preço ou um elemento de paywall. Ele informa a mudança, não o DevTools.

Três verificações, dois jeitos baratos de driblar
  • Diferença de tamanho da janela
    Janela externa menos a área da página
    detectado
  • Custo do console
    Cronometrar 40 chamadas de console e comparar com uma linha de base
    detectado
  • Tempo do debugger
    Uma instrução debugger e um cronômetro
    detectado
Verificações que percebem o DevTools: 3 / 3
Nenhuma verificação sozinha cobre todas as formas de abrir o DevTools. Duas têm um jeito barato de driblar (desacoplar o painel, desativar os pontos de interrupção), e é por isso que os scripts de detecção empilham várias, e que o custo do console é o mais difícil de evitar.

Por que um site trava, redireciona ou diz “developer tools detected”

Os sites que reagem não usam um truque só. Christian Heilmann desmontou um desses scripts em Cracking a “Developer Tools Killer” script. Ele bloqueia o clique direito e os atalhos F12, Ctrl+Shift+I e Ctrl+U, depois roda um loop de debugger a cada 100 ms e redireciona a página se uma pausa durar mais de 200 ms. A função de verificação não está dentro de um closure, então ele simplesmente a sobrescreveu.

A motivação costuma ser incomodar quem copia ou faz scraping. Não protege nada, porque tudo o que o servidor envia já está no seu navegador. Copiar, colar, trocar de aba e tirar print são um conjunto à parte de sinais, tratado no artigo Sites Veem Você Trocar de Aba, Copiar ou Tirar Print?

Um site consegue bloquear o Inspecionar Elemento ou o F12?

Uma página pode cancelar os eventos de tecla F12 e Ctrl+Shift+I e o menu do clique direito, e a maioria dos scripts de “bloqueio” faz exatamente isso. É cosmético. O menu do navegador (Mais ferramentas, Ferramentas do desenvolvedor) roda fora da página e não dá para impedi-lo. A última linha do widget registra quais desses eventos chegam à página no seu navegador. Ele só observa, nunca os cancela.

Como contornar a detecção de DevTools e acabar com o travamento

O DevTools é um recurso padrão do navegador, então uma verificação que dispara por causa dele é problema do site. Escolha a solução de acordo com a verificação:

  1. Desative os pontos de interrupção no painel Origens (Sources) (Ctrl+F8, ou Cmd+F8 no Mac). Toda instrução debugger passa a não fazer nada e a verificação de pausa não vê intervalo nenhum.
  2. Desacople o painel para uma janela própria, o que neutraliza a verificação de tamanho.
  3. Lide com o script em si quando o que dispara é o tempo do console. Não existe configuração que esconda o console de uma página. Dá para sobrescrever ou bloquear o script de detecção, como o passo a passo do Heilmann faz ao sobrescrever a função de verificação, ou inspecionar uma cópia salva da página, que não roda script nenhum.

Não recorra a uma extensão que falsifica window.outerWidth ou altera o console. Uma função nativa substituída deixa de exibir [native code], e isso já entrega a troca, assim como acontece com as funções nativas alteradas na detecção de bots.

Usar o Inspecionar Elemento é ilegal?

Não. Todos os grandes navegadores o incluem e o documentam, e ele edita só a sua cópia local. O problema começa no que você faz depois: um print adulterado e apresentado como recibo, nota fiscal ou extrato bancário de verdade pode configurar falsificação ou fraude, dependendo de onde você mora e da sua intenção, seja qual for a ferramenta que o criou.

Se você roda navegadores em escala

Para um desenvolvedor, ser detectado significa uma página quebrada até desativar os pontos de interrupção. Para quem roda navegadores em escala, significa uma marca em todo site que cronometra o console, porque o custo muda quando um canal de automação se conecta, não só quando uma pessoa abre o DevTools. Se você controla perfis com Puppeteer ou Playwright, teste cada configuração no widget acima, sem nenhuma janela do DevTools aberta, antes de confiar nela.

Os perfis do Incogniton são builds reais do Chromium, então as verificações acima valem para eles como valem para o Chrome. Se o tempo do console fica quieto ou não depende de como você controla o perfil, então teste essa parte você mesmo. Se um determinado site permite automação é definido pelas regras dele, então leia-as antes.

Teste agora: abra o DevTools com o widget observando, depois desacople o painel e desative os pontos de interrupção. Duas linhas ficam quietas. A do console não. O scan completo do navegador cobre o resto do que uma página consegue ler, da rede ao fingerprint.

Logotipo da Incogniton

Eleve o nível da sua privacidade

Seta