¿Tu SVG no se renderiza en el navegador? Causas comunes
Por qué tu SVG muestra un icono de imagen rota (o nada en absoluto)
Los archivos SVG se supone que son fáciles. Como una alternativa infinitamente escalable a los formatos ráster, suelen ser fiables. Pero cuando un SVG se niega a renderizarse, el fallo suele ser silencioso y confuso. Obtienes un icono de imagen rota, un rectángulo blanco en blanco o simplemente un espacio vacío donde debería estar tu gráfico. Un JPEG corrupto al menos se ve obviamente roto; un SVG defectuoso puede verse perfecto en un editor de texto y aun así no mostrar nada en Chrome, Firefox o Safari. Los problemas suelen reducirse a unos pocos problemas distintos: un tipo MIME incorrecto del servidor web, XML mal formado dentro del archivo, políticas de seguridad que bloquean el código en línea, o problemas de tamaño que hacen que el SVG se renderice con un tamaño visible de cero. Cada uno tiene una solución diferente, y confundirlos te hará perder horas. Esta guía te explica cada causa con la configuración y los atributos específicos que necesitas verificar, no solo consejos vagos como 'valida tu archivo'. Una distinción importante antes de empezar: algunos problemas de SVG comienzan en la herramienta de diseño (Illustrator, Figma) durante la exportación, mientras que otros ocurren durante la conversión del archivo. Si usaste una herramienta en línea para convertir un archivo a SVG y se rompió, ese es un tipo de problema diferente a un SVG perfecto que tu servidor está configurando mal. Nos aseguraremos de distinguir entre ambos.
Tipo MIME incorrecto: El problema del lado del servidor que la mayoría de los desarrolladores pasa por alto
Cuando usas una etiqueta `<img>` o `background-image` de CSS para mostrar un SVG, el navegador inspecciona la cabecera Content-Type enviada por el servidor. Si esa cabecera lee `text/plain` o `application/octet-stream` en lugar del correcto `image/svg+xml`, la mayoría de los navegadores simplemente se negarán a renderizar la imagen. El archivo en sí podría ser impecable. Esta es una de las causas más comunes de SVGs rotos en producción, y es un fantasma en el desarrollo local. ¿Por qué? Porque localmente, probablemente solo estés abriendo el archivo desde el disco, no sirviéndolo. El problema solo aparece después de que implementas. Para diagnosticar esto, abre las DevTools de tu navegador (F12), ve a la pestaña Network y recarga la página. Encuentra tu SVG en la lista de solicitudes, haz clic en él y mira las Response Headers. La línea `Content-Type` debe decir `image/svg+xml`. Si dice cualquier otra cosa, has encontrado tu problema. La solución está en el servidor, no en el archivo. En Apache, puedes solucionar esto añadiendo `AddType image/svg+xml .svg .svgz` a tu archivo `.htaccess`. Para los usuarios de Nginx, añade `image/svg+xml svg svgz;` dentro del bloque `types` de tu `nginx.conf`. Si estás en IIS, necesitarás usar el Administrador de Servicios de Información de Internet para añadir una asignación de tipo MIME para la extensión `.svg` a `image/svg+xml`. Si estás usando una plataforma gestionada como Netlify o Vercel, esto se maneja en un archivo de configuración (`netlify.toml` o `vercel.json`). La sintaxis de Netlify, por ejemplo, utiliza un bloque `[[headers]]` para establecer el `Content-Type` para una ruta dada. Es una solución de cinco minutos que puede ahorrarte horas de frustración, pero solo si sabes dónde buscar en el panel de red.
XML mal formado: Cuando el propio archivo SVG es el problema
Un SVG es un documento XML, lo que significa que sigue reglas de análisis estrictas. Una etiqueta de cierre faltante, un ampersand sin escapar o un `id` duplicado pueden hacer que todo el archivo falle silenciosamente en algunos navegadores. Aquí tienes un consejo: si tu SVG se renderiza en Chrome pero no en Firefox, el XML mal formado es el principal sospechoso. Firefox es mucho más explícito sobre los errores de XML. Para que lo veas por ti mismo, arrastra el archivo SVG directamente a una ventana de Firefox. Si el XML está roto, Firefox te mostrará un mensaje de error claro, completo con un número de línea y columna: 'Error de análisis XML: no bien formado en la línea 47, columna 12.' Ese es tu mapa del tesoro. Abre el archivo en un editor de texto como VS Code y ve a ese punto exacto. ¿Qué estás buscando? A menudo es un ampersand (`&`) en un enlace que debería haber sido escrito como `&`. O podrías encontrar un elemento `<path>` o `<g>` sin cerrar. Los problemas de codificación son otro clásico, donde una herramienta de diseño exporta caracteres fuera del rango ASCII estándar sin declarar UTF-8. Tu archivo SVG siempre debería comenzar con `<?xml version="1.0" encoding="UTF-8"?>` si contiene caracteres no ASCII. Las versiones antiguas de Adobe Illustrator solían exportar archivos con espacios de nombres XML propietarios. Aunque no es técnicamente inválido, esto añade peso inútil y a veces puede confundir a los analizadores. Ejecutar estos archivos a través de un optimizador como SVGO normalmente elimina esos espacios de nombres, lo cual es bueno. El peligro es si la apariencia del gráfico dependía de alguna manera de esos atributos propietarios, en cuyo caso limpiar el archivo podría romperlo inesperadamente. Si convertiste un archivo a SVG usando CocoConvert y el resultado tiene errores XML, por favor, háznoslo saber a través del botón de comentarios en la página de resultados. Buscamos y corregimos activamente este tipo de artefactos de conversión.
SVG en línea y conflictos con la Política de Seguridad de Contenido
Pegar el marcado SVG directamente en tu HTML es una técnica potente, pero tiene una gran desventaja: el SVG se convierte en parte del DOM. Esto significa que ahora está sujeto a la Política de Seguridad de Contenido (CSP) de tu página. Una CSP estricta puede deshabilitar silenciosamente partes de tu SVG, lo que lleva a confusión. Esto es especialmente cierto para los SVGs que contienen elementos `<script>`, bloques `<style>` para animaciones o elementos `<use>` que hacen referencia a definiciones de símbolos externos. Una directiva CSP común como `script-src 'self'` bloqueará cualquier script en línea dentro de tu SVG para que no se ejecute. Una directiva como `img-src 'self'` podría evitar que el SVG cargue una imagen externa referenciada a través de `<image href="https://external-domain.com/...">`. ¿La buena noticia? El navegador te dirá exactamente qué está mal. Abre la consola de desarrollador del navegador (la pestaña Console, no Network) y busca mensajes de error rojos. Las violaciones de CSP son muy explícitas, indicando qué recurso fue bloqueado y qué directiva de política fue responsable, como: 'Se negó a cargar el script porque viola la siguiente directiva de Política de Seguridad de Contenido: script-src self.' Cómo solucionas esto depende de las necesidades de tu SVG. Podrías añadir `'unsafe-inline'` a tu directiva `style-src`, pero esto debilita tu política de seguridad, así que te aconsejaría encarecidamente que no lo hicieras. Una solución mucho mejor para los SVGs animados es mover el CSS a una hoja de estilos externa y vincularla con `<?xml-stylesheet type="text/css" href="styles.css"?>`. Para los elementos `<use>` que apuntan a archivos externos, necesitarás o bien incrustar los símbolos o ajustar tu política `img-src` para incluir el origen en la lista blanca. Los SVGs generados por CocoConvert o herramientas similares no tendrán scripts, por lo que no verás conflictos de script-src con ellos. Sin embargo, los conflictos de style-src aún son posibles si el SVG convertido utiliza CSS en línea para colores o fuentes.
Configuraciones incorrectas de Viewport y ViewBox que hacen que el SVG sea invisible
Este es el tipo de problema SVG más exasperante. El navegador está renderizando el SVG perfectamente, pero lo está haciendo con tamaño cero o en algún lugar fuera de la pantalla. No ves un icono de imagen rota; no ves nada. Cualquiera que haya mirado fijamente un espacio en blanco en DevTools, viendo el elemento `<svg>` allí mismo pero nada en la pantalla, conoce este dolor particular. La clave es la relación entre el atributo `viewBox`, que define el sistema de coordenadas interno del gráfico, y los atributos `width` y `height`, que definen cuánto espacio ocupa el SVG en la página. Cuando faltan o no coinciden, se produce el caos. A menudo verás esto con las exportaciones de Figma: a un SVG se le da `width="100%"` y `height="100%"` pero no tiene `viewBox`. Si colocas ese SVG en un contenedor que no tiene una altura explícita, el SVG se colapsa a altura cero. La solución es añadir un `viewBox` que coincida con las dimensiones originales de la mesa de trabajo (por ejemplo, `viewBox="0 0 800 600"`) o darle al elemento contenedor una altura en tu CSS. Otro clásico es un SVG donde los datos de la ruta se dibujan en coordenadas muy fuera del `viewBox`. Si tu `viewBox` es `"0 0 100 100"` pero los datos de tu ruta comienzan en `M 500 500`, el gráfico se está dibujando 400 unidades fuera de la pantalla. Esto ocurre cuando mueves formas en una herramienta de diseño sin restablecer el origen de la mesa de trabajo. Para solucionarlo, vuelve a tu herramienta de diseño, selecciona todos los objetos y usa un comando 'Restablecer cuadro delimitador' o su equivalente, luego vuelve a exportar. Para diagnosticar esto, inspecciona el SVG en DevTools. Si su ancho o alto calculado es 0, el tamaño es el culpable. También puedes forzar el problema añadiendo temporalmente `style="border: 1px solid red; width: 200px; height: 200px;"` directamente a la etiqueta `<svg>`. Esto creará un cuadro visible y revelará si alguna parte de tu gráfico está apareciendo.
Fallos de carga de fuentes y recursos externos dentro de SVG
Un SVG no siempre es autocontenido. Puede hacer referencia a recursos externos como fuentes, imágenes, gradientes y filtros. Cuando estas llamadas externas fallan, el SVG podría renderizarse parcialmente o verse completamente mal, dependiendo de cuán crítica sea la pieza que falta. Los fallos de las fuentes son un dolor de cabeza frecuente. Un SVG que especifica una fuente personalizada en un elemento `<text>` recurrirá a una fuente predeterminada del sistema si esa fuente no está disponible. Esto generalmente no rompe la renderización por completo, pero puede hacer que el texto se desborde de su contenedor y desajuste todo el diseño. Mi consejo: convierte siempre el texto a contornos (rutas) antes de exportar un SVG para uso web. En Illustrator, es Texto > Crear Contornos; en Inkscape, es Ruta > Objeto a Ruta. Esto elimina por completo la dependencia de la fuente y toda una clase de problemas. Las imágenes externas dentro de un SVG son aún más delicadas. Una etiqueta `<image>` que apunta a una URL puede fallar porque la URL está caída, porque el servidor de imágenes carece de las cabeceras CORS adecuadas o porque una CSP bloquea el origen. El navegador no mostrará un icono de error; simplemente renderizará un espacio en blanco donde debería estar la imagen. Revisa tu pestaña Network en busca de solicitudes con un estado 404 o un estado 0, lo que a menudo indica un bloqueo de CORS o CSP. Si estás convirtiendo un archivo PDF o AI que contiene imágenes ráster, CocoConvert incrustará esas imágenes directamente en el SVG como URIs de datos base64. Esto resuelve el problema de la referencia externa, pero puede hacer que el archivo SVG sea enorme. Un PDF con algunas fotos puede convertirse fácilmente en un SVG de más de 5MB. En esos casos, lo diremos claramente: convertir a PNG o WebP es la opción más práctica. No vamos a fingir que SVG es siempre la respuesta correcta.
Cuando la conversión es la fuente del problema (y qué hacer al respecto)
A veces el problema no es tu navegador o tu servidor. El archivo SVG en sí mismo estaba roto desde el principio, una víctima de un mal proceso de conversión. Es importante reconocer esta posibilidad, porque significa que debes dejar de depurar tu entorno y empezar a examinar el archivo. Los artefactos de conversión comunes incluyen datos de ruta con una precisión absurdamente alta (más de 15 decimales), lo que hincha los archivos y puede agotar el tiempo de espera de los analizadores; conversiones de espacio de color incorrectas de CMYK a valores RGB no compatibles; y codificación de texto rota si un archivo fuente utilizó scripts no latinos. También podrías ver declaraciones de espacio de nombres faltantes al convertir de formatos que dependen de XML propietario. Si sospechas una mala conversión, la forma más rápida de comprobarlo es abrir el SVG en Inkscape. Es gratuito, multiplataforma y tiene un analizador SVG muy tolerante. Si el archivo se ve correcto en Inkscape pero está roto en Chrome, es probable que el problema sea específico del navegador. Si también está roto en Inkscape, entonces el proceso de conversión falló y la salida está corrupta. CocoConvert utiliza bibliotecas de conversión robustas, pero ninguna herramienta automatizada es perfecta. Un archivo AI altamente complejo con cientos de capas, o un PDF que depende en gran medida de los efectos de transparencia, puede producir una salida SVG imperfecta. En estas situaciones, el camino más fiable suele ser abrir el archivo fuente en su aplicación original, exportar directamente a SVG y usar CocoConvert para pares de formatos en los que destacamos, como convertir PNGs simples a SVG o SVG a PDF para impresión. Si obtienes un SVG roto de una conversión, por favor, repórtalo usando el formulario de comentarios en la página de resultados, e incluye el archivo original si puedes. Los ejemplos específicos son cómo mejoramos el proceso de conversión para todos, y nos tomamos esos informes muy en serio.