Ofuscador de JavaScript

Funciones

• Quita todos los comentarios y el espacio sobrante
• Escapa las cadenas en hexadecimal o Unicode (el texto no latino usa \u, sin romper bytes)
• Escribe los literales numéricos en hexadecimal
• Renombra las variables locales a `a`, `b`, `c` … y deja intactos los nombres de nivel superior
• Opcional: quita las llamadas a `console.*`
• Indica cuánto cambia el tamaño y cuántos nombres se renombraron
• ⚠️ No protege el código; la página también lo dice, con los motivos más abajo

Cómo se usa

1. Pega tu JavaScript en el panel izquierdo
2. Ajusta el renombrado, la codificación de cadenas, los números y el trato de console
3. Pulsa Ctrl/⌘ + Enter o haz clic en «Ejecutar»
4. Copia el resultado con el botón de la derecha de la primera fila

Preguntas frecuentes

¿El código queda a salvo una vez ofuscado?

No. Es lo que más conviene dejar claro de esta clase de herramientas. Para que JavaScript corra en el navegador de un usuario, el código fuente tiene que entregarse a ese navegador, y lo que se entrega a un navegador el usuario lo puede obtener. La ofuscación hace que el código sea *más difícil de leer*, no imposible de obtener. Las dos cosas se confunden constantemente. En concreto, para lo que hace esta herramienta: renombrar solo cambia las etiquetas; las relaciones de llamada, los bucles y las ramas quedan exactamente igual. Los escapes de cadena los descodifica el navegador al ejecutarse, así que pegar la salida en la consola muestra los originales. Una ofuscación más fuerte (aplanado del flujo de control, arrays de cadenas cifradas, anti-depuración) sí cuesta unas horas al lector, pero los desofuscadores van al mismo ritmo, y el precio es que tus trazas de error en producción se convierten en `a`, `b`, `c`, lo que dificulta mucho diagnosticar un incidente real. La conclusión: lo que tenga que seguir siendo secreto no debe enviarse al front end. Las claves, la lógica de firma y las reglas de negocio van en el servidor, y el cliente llama a una API.

¿Por qué se dejaron algunas variables sin cambiar?

Cada caso es deliberado. Las declaraciones de nivel superior no se tocan nunca: pueden ser exportaciones del módulo (a las que se hace referencia por su nombre desde fuera) o globales compartidos con otros scripts de la página, y ninguna de las dos cosas se ve en el código. Los nombres importados se dejan en paz, porque apuntan a la exportación de otro módulo. Los nombres de propiedad se dejan en paz (el `userName` de `obj.userName`): renombrarlo leería una propiedad que no existe, y si se cambiara `obj.userName` pero no `obj["userName"]`, los dos discreparían. Aparte, si el código contiene `eval`, `with` o un `import()` dinámico, el renombrado se abandona para todo el archivo: esos tres pueden armar nombres de variable en tiempo de ejecución y el análisis estático no llega. El panel de resultados dice cuál lo provocó.

¿El código ofuscado seguirá funcionando bien?

Sí: la semántica no cambia. Renombrar y escapar son transformaciones que conservan el significado; la salida es equivalente en comportamiento a la entrada. Dicho esto, aquí la corrección no se da por fe. La única forma en que el renombrado puede fallar es tocar algo que no debía, y ese fallo no lanza nada: cambia un resultado en silencio. Por eso la batería de pruebas se basa en ejecutar cada fragmento antes y después y exigir resultados idénticos, cubriendo cierres, desestructuración (incluidas la forma corta `{x}` y los valores predeterminados `{x = 1}`), enlaces por iteración de `for (let)`, saltos con etiqueta, getters de `class`, encadenamiento opcional, plantillas, expresiones regulares y BigInt, que son los puntos que primero se rompen. Aun así, conviene pasar tus propias pruebas sobre la salida ofuscada antes de publicarla: puede que saque a la luz un camino que tus pruebas nunca cubrieron.