Un souci avec cet outil ?
À propos de « Obfuscation JavaScript En Ligne »
Cet outil obfusque du code source JavaScript en préservant sa fonctionnalité. Les noms de variables sont renommés en identifiants courts ou aléatoires, les chaînes littérales sont encodées, le flux de contrôle peut être aplati, et du code mort peut être inséré pour brouiller l'analyse statique.
L'obfuscation ne remplace pas une vraie sécurité — quelqu'un de motivé peut désobfusquer. Mais elle dissuade l'inspection casual de la logique métier, ralentit les tentatives de contournement de licence, et décourage le copier-coller de scripts payants.
Notez que l'obfuscation augmente généralement la taille du fichier et peut ralentir l'exécution. N'obfusquez pas le code à déboguer en production ; utilisez des source maps pour préserver le lien avec le source original.
Comment utiliser cet outil
Obfusquer un code JavaScript pour le rendre plus dur à lire
Coller le JS
Source dans « JS ». L’outil traite la syntaxe ES2020+ standard ; les imports de module restent structurellement intacts, le résultat se charge donc encore comme un module, mais l’intérieur est très différent.
Exécuter
Résultat : champ unique `obfuscated`. Les identifiants sont renommés en chaînes courtes ou aléatoires, les littéraux de chaîne sont sortis dans une table de recherche, le code mort est réorganisé, et le control flow est aplati quand c’est sûr.
Pourquoi ce n’est pas de la sécurité
L’obfuscation ralentit un reverse-engineer motivé ; elle ne rend pas le code secret. Tout ce que le navigateur exécute, un debugger peut le suivre pas à pas. Pour les vrais secrets (clés API, logique métier), gardez-les côté serveur — obfusquer du JS livré ne fait que repousser l’inévitable.
Effets de bord à surveiller
Le JS obfusqué est plus gros ET plus lent que l’original — typiquement 30–80 % plus lent sur les boucles serrées. Cela casse aussi le debug par source-map sauf si vous générez une map à part. Pour la prod, préférez la minification à l’obfuscation.