Perguntas frequentes
Perguntas gerais
Dúvidas comuns sobre ofuscação de JavaScript e como ela funciona.
Há vários motivos para proteger seu código: impedir que qualquer pessoa simplesmente copie e cole o seu trabalho (algo especialmente importante em projetos que rodam no cliente, como jogos em HTML5), remover comentários e espaços em branco para deixar o código mais rápido de carregar e mais difícil de entender, e proteger um trabalho que ainda não foi pago, para que você possa mostrá-lo ao cliente sem entregar o código-fonte.
A ofuscação VM (máquina virtual) transforma seu código JavaScript em bytecode personalizado, executado por um interpretador embutido. Diferentemente da ofuscação padrão, que ainda gera JavaScript legível, a ofuscação VM esconde completamente a estrutura do seu código original. Ferramentas de análise estática não conseguem entender a lógica sem antes fazer engenharia reversa de toda a máquina virtual. Saiba mais no nosso guia de ofuscação VM.
Sim! Oferecemos uma opção para aplicar a ofuscação VM seletivamente a funções ou métodos específicos. Basta anotar a função desejada com um comentário especial (/* javascript-obfuscator:vm */) e somente ela passará pelo ofuscador VM. Isso é ideal para proteger apenas seus algoritmos mais sensíveis, mantendo o restante do código com ofuscação padrão ou intacto, o que minimiza a perda de desempenho.
Não. Chaves de API, segredos e credenciais NUNCA devem ser armazenados em código de frontend. Mesmo com o maior nível de ofuscação, qualquer dado presente no JavaScript do frontend pode ser extraído por um atacante determinado. A ofuscação dificulta a engenharia reversa, mas não é criptografia e não deve ser usada para proteger segredos. Em vez disso, armazene os segredos no seu servidor de backend, use variáveis de ambiente no lado do servidor, faça proxy das chamadas de API pelo seu backend para esconder as chaves ou use tokens de curta duração emitidos pelo seu servidor.
Nenhuma ofuscação é 100% infalível — o JavaScript acaba rodando em um ambiente controlado pelo atacante (navegador ou Node.js) e, ali, a inspeção da memória em tempo de execução é sempre possível. Nenhuma ofuscação de JavaScript consegue eliminar isso; o que ela pode fazer é elevar o custo de chegar lá. Hoje não existem serviços online de desofuscação automatizada para código ofuscado por VM — cada ofuscação compila o código em um bytecode personalizado com uma máquina virtual única, o que torna impossível criar ferramentas universais. A ofuscação padrão é muito mais fácil de derrotar: ela costuma ser parcialmente revertida com ferramentas automatizadas e beautifiers. Já a ofuscação VM exige fazer a engenharia reversa completa da máquina virtual, descriptografar e decodificar o bytecode, entender o conjunto de instruções e rastrear a execução — um processo que pode levar semanas de trabalho dedicado. Sem o VM Self Defending, agentes de IA poderosos (ex.: Claude Opus 4.7) conseguem rastrear o bytecode e reconstruir aproximadamente o código original em bases de código menores. Com o VM Self Defending ativado, defesas anti-LLM em camadas — anti-hooking, verificação de integridade entre realms e checagens de nativeness do bytecode — atrapalham as técnicas dinâmicas que um agente usa para entender o bytecode: instrumentação, hooking e execução em sandbox. A leitura estática do arquivo continua possível, mas expõe apenas bytecode opaco, e toda tentativa de observar o runtime que o interpreta dispara uma verificação de integridade. Só a partir do arquivo, a desofuscação automatizada por IA se torna inviável. Para reforçar ainda mais seu código: envolva as funções sensíveis em uma IIFE para que os nomes sejam totalmente transformados e ative opções de blindagem como a criptografia do bytecode. Saiba mais sobre como a VM transforma o código.
A ofuscação VM é uma tecnologia complexa e alguns casos extremos podem não ter suporte completo. Se o seu código quebrar após a ofuscação VM, você pode isolar o problema usando vmTargetFunctionsMode: 'comment' para ofuscar funções específicas. Veja nosso guia de solução de problemas para instruções passo a passo sobre como identificar o código problemático e reportar o problema.
O ofuscador insere código novo para proteger contra depuração e engenharia reversa. As strings são convertidas para hexadecimal e, na ofuscação VM, um interpretador de máquina virtual inteiro é embutido junto com o seu bytecode. Não se preocupe demais com o tamanho — o código ofuscado comprime muito bem com GZIP, que a maioria dos servidores já habilita por padrão.
Qualquer ofuscação tem algum impacto no desempenho. A ofuscação padrão tem sobrecarga mínima. A ofuscação VM tem impacto bem maior, e ele depende muito do código — por exemplo, código com muita recursão convertido em bytecode fica visivelmente mais lento. Em média, a predefinição low adiciona cerca de 10x de impacto, e a predefinição anti-LLM com Self Defending e Debug Protection fica cerca de 12x mais lenta. Você pode ajustar esse equilíbrio alterando as opções ou aplicando a ofuscação VM apenas aos trechos sensíveis do código. Veja nosso guia de boas práticas para dicas de otimização.
Não, isso não é recomendado e, em alguns casos, vai quebrar o código (especialmente se você ativar o self-defending). Mas você pode passar seu código por um minificador antes da ofuscação.
Para arquivos com menos de 4.4 MB, o código-fonte é processado inteiramente em memória e devolvido imediatamente como saída ofuscada. Para arquivos maiores (planos Team/Business), nós os enviamos temporariamente para um armazenamento seguro e os excluímos assim que a ofuscação termina. Como proteção adicional, uma rotina de limpeza roda a cada 5 minutos para remover qualquer arquivo com mais de 5 minutos. Seu código nunca é retido.
Não, é impossível reverter o código ofuscado de volta ao código original, então guarde o original em local seguro.
Sim. Você pode selecionar "Node" como target nas opções de ofuscação para otimizar a saída para ambientes Node.js.
Suportamos ES2015 (ES6) e todos os recursos modernos do JavaScript, incluindo sintaxe ES2022+, campos privados de classe, async/await, optional chaining e mais. TypeScript e JSX precisam ser compilados para JavaScript antes da ofuscação. Com um plano pago, você também pode ofuscar arquivos HTML — adicione o atributo data-javascript-obfuscator às tags <script> que quiser proteger, e elas serão ofuscadas individualmente, preservando a estrutura do HTML. Observe que o código de cada script marcado precisa ser autocontido (sem referências a outros scripts) e que scripts de módulos ES são ignorados.
A saída ofuscada — incluindo o interpretador da VM e a camada Self Defending — tem suporte ativo e é testada em navegadores desktop evergreen e no iOS 16+ (aproximadamente os últimos 3 anos). Navegadores mais antigos funcionam em regime de melhor esforço, até um piso rígido de suporte a módulos ES2015; abaixo disso, incluindo o Internet Explorer, está fora de escopo.
Confira nossos planos e preços para proteção VM ou experimente o ambiente de testes online gratuito para ofuscação padrão. Leia o guia de primeiros passos para um passo a passo completo.
Preços e conta
Dúvidas sobre planos, faturamento e limites de uso.
pricing.faq.usageMeasured.answer
pricing.faq.exceedLimit.answer
pricing.faq.upgradeDowngrade.answer
pricing.faq.cancel.answer
pricing.faq.paymentMethods.answer
