Optimizador y simplificador de SVG

Preguntas frecuentes

¿Cuánto puede reducir el tamaño del archivo?

Normalmente entre 40% y 80% en SVG exportados desde Illustrator, entre 40% y 70% en exportaciones de Figma, entre 35% y 55% en Sketch y entre 10% y 25% en SVG escritos a mano. Las mayores ganancias vienen de los metadatos de Illustrator, que se eliminan por completo. El ahorro exacto de tu archivo aparece en el resultado.

¿Cambiará el aspecto de mi SVG?

No. Toda optimización por defecto es sin pérdida: los píxeles renderizados quedan idénticos. La vista previa a la derecha muestra el SVG limpio con las mismas dimensiones; úsala para comprobarlo antes de descargar. Si alguna vez ves una diferencia, es que una opción agresiva (por ejemplo una precisión muy baja) está simplificando demasiado un path: sube la precisión.

¿Qué diferencia hay entre optimizar y minificar un SVG?

Minificar solo quita espacios en blanco y acorta nombres de atributos. Optimizar (lo que hace esta herramienta) también elimina metadatos sin usar, colapsa paths, convierte las formas a su equivalente más corto y redondea la precisión numérica. La optimización suele dar un ahorro de 3 a 5 veces mayor que la minificación sola.

¿Elimina los metadatos de Illustrator, Inkscape y Figma?

Sí, por defecto. Quita el elemento <sodipodi:namedview> (Inkscape), los atributos <inkscape:*>, el espacio de nombres xmlns:a de Illustrator, los ID numéricos generados por Figma y los comentarios “Generator” o “Created with”. El navegador no ve nada de esto, pero puede suponer entre el 30% y el 50% de un SVG sin optimizar.

¿Puedo conservar el viewBox o los ID?

Sí, los dos son interruptores. El viewBox se CONSERVA por defecto porque quitarlo rompe el escalado con CSS y HTML; solo ahorra unos 25 bytes, así que desactívalo únicamente en un SVG de tamaño fijo que nunca cambias de escala. Los ID se ELIMINAN por defecto porque suelen ser ruido de las capas de Figma; activa “Conservar los atributos id” en sprites SVG o cuando tu CSS o JavaScript selecciona nodos por id.

¿Es lo mismo que ejecutar SVGO desde la línea de comandos?

Sí. Es el propio SVGO v4, la misma librería que usan la línea de comandos, webpack, Vite y svgr, ejecutándose en tu navegador en lugar de en Node. Con los mismos ajustes la salida es idéntica, byte a byte, a `npx svgo input.svg`. La diferencia es la comodidad: no hay que instalar nada, ni archivo de configuración, y ves en vivo lo que cuesta cada ajuste.

¿Por qué muestra el tamaño con gzip?

Porque es lo que de verdad viaja hasta tus usuarios: todo servidor web sirve el SVG con compresión gzip o brotli. El ahorro en bytes sin comprimir puede engañar, porque SVGO elimina mucho texto repetitivo que gzip ya comprimía bien, así que una reducción del 70% puede quedarse en 45% tras gzip. La cifra con gzip es la medida honesta de lo que has ganado en tiempo de carga.

¿Qué precisión numérica debo usar?

3 es el valor por defecto y es seguro para casi todo. Baja a 2 en iconos y gráficos de interfaz, donde suele ser invisible y ahorra otro 10–15%. Baja a 1 o 0 solo en formas pequeñas y simples, y vigila la vista previa lado a lado: con precisión baja las curvas empiezan a aplanarse de forma visible. Las ilustraciones de lienzo grande (mapas, dibujos detallados) pueden necesitar 4 o más.

¿Puedo recuperar el SVG original después de optimizar?

No. La optimización es destructiva por diseño: los metadatos eliminados, los nodos colapsados y las coordenadas redondeadas no se pueden recuperar. Guarda el original en tu control de versiones antes de optimizar.

¿Se sube mi SVG a algún sitio?

No. SVGO se ejecuta como JavaScript dentro de la pestaña de tu navegador. Tu archivo nunca se sube a un servidor; puedes comprobarlo en la pestaña Red de las herramientas para desarrolladores: al optimizar no sale ninguna petición. Es importante para logotipos y recursos sujetos a confidencialidad.

¿Puedo optimizar específicamente los paths de un SVG?

Sí. La optimización de los paths es la mayor fuente de bytes en casi todos los iconos. Los plugins centrados en paths (convertPathData, mergePaths, removeUselessStrokeAndFill) reducen la precisión numérica (de 6 decimales a 2 o 3), unen elementos `<path>` consecutivos con los mismos estilos, convierten los comandos absolutos (`M L`) en relativos (`m l`) cuando son más cortos y eliminan subpaths redundantes. Ahorro típico en paths: entre 30% y 60% del tamaño total en SVG de iconos.

¿Sirve para sprites SVG y sets de iconos?

Sí, y es especialmente útil en sprites, porque el ahorro se acumula en muchos iconos. Puedes optimizar cada icono antes de empaquetarlos o el sprite ya montado. En los sprites, deja `cleanupIDs` desactivado para que sigan funcionando los selectores de CSS o JavaScript que hacen referencia a los ID de cada icono.

¿Es un simplificador de SVG? ¿Reduce el número de puntos de un path?

No. No elimina nodos. Un path que llega con 4000 puntos de anclaje sale con 4000 puntos de anclaje. Lo que hace es que cada uno de esos puntos ocupe menos bytes: las coordenadas se redondean a la precisión elegida, los comandos absolutos pasan a relativos, los segmentos `L` redundantes se colapsan en `H` y `V` y los paths consecutivos con el mismo estilo se unen. En un path vectorizado o autogenerado suele suponer una reducción de entre 50% y 70% de bytes con una salida idéntica al píxel. Si de verdad necesitas menos nodos, porque el path viene de una vectorización de imagen y pesa para animarlo o editarlo, eso es reajuste de curvas (Ramer–Douglas–Peucker) y por definición tiene pérdida: la forma cambia un poco. Usa Trazado → Simplificar de Inkscape (Ctrl+L), Objeto → Trazado → Simplificar de Illustrator o la librería `simplify-js`. Hazlo primero y trae aquí el resultado para el paso de bytes sin pérdida. Los dos pasos se complementan, no son alternativas.

¿Cómo simplifico un path SVG con esta herramienta?

Baja el control de precisión. Es, con diferencia, la palanca más potente sobre los datos de un path. Las herramientas de diseño exportan las coordenadas con 6 decimales (`M 12.847362 4.019283`), unas mil veces más finas de lo que puede resolver cualquier pantalla. Bajar a 2 decimales suele reducir a la mitad los datos del path por sí solo. Como regla general: precisión 3 es segura para todo (es el valor por defecto y no pierde nada visible a ningún zoom), la precisión 2 es la adecuada para iconos y logotipos por debajo de unos 200 px, y la precisión 1 sirve para iconos de interfaz pequeños y monocromos, aunque puede empezar a desplazar curvas de forma visible. Activa multipass para que el proceso se repita hasta que la salida deje de reducirse; en paths complejos encuentra otro 3–8% que la primera pasada no ve. La vista previa lado a lado se actualiza en vivo: baja el valor hasta que notes una diferencia y vuelve un paso atrás.

¿Es un SVGO online?

Sí. Ejecuta el SVGO v4 real dentro de la pestaña de tu navegador en lugar de en Node: la misma librería que instalarías con `npm i -D svgo`, la misma cadena de plugins, el mismo `preset-default` y el mismo resultado para la misma entrada. Lo único que cambia es dónde se ejecuta el código. No hay servidor, así que no se sube nada y funciona sin conexión una vez cargada la página. Si ya tienes un `svgo.config.js` en un proyecto, los ajustes de aquí se corresponden con los plugins que configura.

¿En qué se diferencia de SVGOMG?

SVGOMG es la herramienta de Jake Archibald y la implementación de referencia. Si la conoces y te gusta, sigue usándola. Las dos ejecutan SVGO en el navegador y producen resultados casi idénticos, porque ambas delegan en la misma librería. Esta se diferencia en que muestra el tamaño con gzip junto al tamaño sin comprimir, que es el que de verdad viaja por la red y a menudo cuenta otra historia (un ahorro del 40% sin comprimir puede ser un 15% con gzip, porque gzip ya colapsaba la repetición que SVGO elimina). También ofrece la precisión como un único control en lugar de una lista de plugins, que es más rápido cuando la precisión es lo único que quieres ajustar. SVGOMG expone más interruptores de plugins individuales y tiene un set de demostración más vistoso. Ninguna sube tu archivo.

¿Puede reparar un SVG roto?

Solo en un sentido muy limitado. SVGO tiene que interpretar tu archivo antes de hacer nada, así que el XML debe estar bien formado: una etiqueta sin cerrar o un `&` suelto hará que falle en lugar de arreglarlo. Es un optimizador, no una herramienta de recuperación. Lo que sí limpia con fiabilidad: restos de editores que rompen el renderizado en otros sitios (los envoltorios `<foreignObject>` de Illustrator, los grupos vacíos y los clip paths de Figma), ID duplicados o en conflicto que rompen una página cuando dos SVG incrustados los comparten, y problemas de escalado por falta de viewBox. Lo que no hará: reconstruir marcado mal formado, recuperar un archivo truncado ni convertir una imagen incrustada de nuevo en vectores. Si el XML está realmente roto, abre el archivo en un editor de texto y corrige primero el error de análisis; la consola del navegador suele señalar la línea exacta.