Minificar/Formatear JavaScript
Optimiza el tamaño de tus bundles JavaScript. Minifica o formatea al instante.
Por qué usarlo
JavaScript más ligero, apps más rápidas
Reducción 40–60%
Elimina espacios, comentarios y acorta variables sin alterar la funcionalidad.
Privado
El JS se procesa en tu navegador. Nunca se sube a ningún servidor.
Bidireccional
Minifica para producción o formatea JS minificado para leerlo y depurarlo.
Instantáneo
Resultado en milisegundos. Sin procesamiento en servidor.
Cómo funciona
Tres pasos, sin complicaciones
Pega o sube tu JavaScript
Pega el código JS directamente o arrastra un archivo .js. Sin límite de tamaño.
Elige: minificar o formatear
Minifica para producción (reduce variables, elimina espacios) o formatea JS minificado para leerlo.
Copia o descarga el resultado
El JavaScript optimizado aparece al instante. Copia al portapapeles o descarga como archivo.
Preguntas frecuentes
¿Tienes dudas?
La minificación de JavaScript elimina espacios en blanco, comentarios y saltos de línea, acorta los nombres de variables y funciones locales (renaming), y en algunos casos elimina código muerto (dead code elimination). El resultado es funcionalmente idéntico pero significativamente más pequeño, reduciendo el tiempo de descarga y el tiempo de parsing del motor JS.
UglifyJS (2010) fue el primer minificador JavaScript ampliamente adoptado, que introdujo la compresión y el mangling (renombrar variables). Terser es el sucesor moderno de UglifyJS, compatible con ES2015+ y módulos ES. 'Minify' es el término genérico para reducir tamaño. Terser es hoy el estándar de facto, usado internamente por webpack, Vite, Rollup y esbuild.
Típicamente entre un 40% y un 60% del tamaño original para código JavaScript bien comentado y formateado. Un archivo de 200 KB puede reducirse a 80–120 KB solo con minificación. Combinado con compresión gzip/Brotli, el ahorro total puede superar el 80%. El renaming de variables aporta una reducción adicional del 10–20% respecto a la simple eliminación de espacios.
El JavaScript minificado puede formatearse (beautify) para recuperar una estructura legible, pero los nombres de variables y funciones renombrados no pueden recuperarse: 'calculateMontlyPayment' puede haberse convertido en 'a' o 'b'. Sin los source maps originales, el código formateado es funcional pero difícil de entender. Los source maps mapean el código minificado al original y son indispensables para depuración en producción.
Los source maps son archivos .js.map que crean una correspondencia entre el código minificado/transpilado y el código fuente original. Cuando ocurre un error en producción, el navegador usa el source map para mostrar el stack trace con los nombres y números de línea originales en lugar de la versión minificada. Se generan automáticamente con webpack (devtool: 'source-map'), Vite (build.sourcemap: true) o Terser (--source-map).
Historia de la minificación JavaScript y optimización de bundles
La minificación de JavaScript tiene su origen en JSMin, creado por Douglas Crockford en 2001. Crockford observó que el código JavaScript enviado al cliente contenía enormes cantidades de whitespace y comentarios que consumían ancho de banda innecesariamente. JSMin fue el primer comprobador sistemático: eliminaba comentarios y espacios preservando la semántica del lenguaje. Poco después, YUI Compressor (Yahoo, 2007) introdujo el renaming básico de variables, sentando las bases del minificado moderno.
El tree-shaking (sacudida de árbol) es una técnica relacionada pero distinta: mientras la minificación reduce el código existente, el tree-shaking elimina el código que nunca se ejecuta (dead code) analizando el grafo de importaciones ES modules. Rollup popularizó el tree-shaking en 2015; webpack lo adoptó en la versión 2. El code splitting complementa estas técnicas dividiendo el bundle en fragmentos cargados bajo demanda (dynamic import()), reduciendo el JavaScript inicial que el navegador debe parsear y ejecutar.
La herramienta Lighthouse de Google incluye el análisis de cobertura JavaScript (Coverage tab en Chrome DevTools) que identifica qué porcentaje del JS descargado realmente se ejecuta en la carga inicial. Estudios de HTTP Archive muestran que la página web mediana carga más de 400 KB de JavaScript comprimido (1+ MB sin comprimir), siendo el recurso que más daña el tiempo de interactividad (Time to Interactive, TTI). La adopción de ESM nativo en navegadores modernos y el patrón de módulos con importmaps representa la próxima evolución en la distribución eficiente de JavaScript.