Saltar al contenido
ConvertOwl
Tecnología5 minutos de lecturaEscrito por ConvertOwl

Qué Ocurre Realmente al Convertir un SVG a PNG

Tres cosas deciden tu PNG: cómo se calcula el tamaño, por qué desaparecen las fuentes y qué se elimina del archivo antes que nada.

Escena de pixel art en la que un dibujo vectorial se convierte en una cuadrícula de píxeles

Convertir un SVG a PNG parece una operación única y evidente. No lo es, porque un SVG no contiene píxeles: contiene instrucciones para dibujar algo. En el momento en que pides un PNG estás haciendo tres preguntas que el archivo quizá no responda: de qué tamaño, con qué fuente y con permiso para ejecutar qué.

Todos los conversores responden a esas tres preguntas. Casi ninguno te cuenta cómo. Esto es lo que ocurre en realidad, medido en las versiones actuales de Chrome, Firefox y Safari.

Pregunta uno: ¿de qué tamaño es un SVG?#

Pregúntale a un navegador el tamaño de un SVG y te dará con total seguridad una cifra equivocada.

Lo probamos en Chromium 149, Firefox 151 y WebKit 26.5 con tres archivos:

Lo que declara el SVGLo que informa el navegador
width="120" height="60"120 x 60
viewBox="0 0 200 50", sin width ni height300 x 75
nada en absoluto300 x 150

Los tres motores coinciden, y la segunda y la tercera fila son el problema. 300 x 150 es un valor por defecto de CSS para elementos sin tamaño intrínseco: el mismo que recibe un <img> que falta. Cuando hay una viewBox, el navegador mantiene esos 300 px de ancho y deduce la altura a partir de la proporción.

Así, un icono que su diseñadora dibujó a 200 x 50 sale como un PNG de 300 x 75, y en ningún sitio se te avisa de que un valor por defecto ha sustituido al tamaño real de tu obra.

La regla que sí funciona#

Lee el archivo, no el DOM:

  1. Si width y height están presentes en unidades absolutas - sin unidad, px, pt, mm, in - ese es el tamaño real. Conviértelo a 96 ppp, de modo que 1in son 96 píxeles.
  2. Si no, y hay una viewBox, usa su ancho y su alto. Es el sistema de coordenadas de quien lo dibujó. Y es el caso que más importa, porque width="100%" height="100%" con viewBox es justo lo que producen Illustrator y Figma por defecto.
  3. Si no, el archivo realmente no declara ningún tamaño. Hay que elegir algo, y lo honesto es decirlo en vez de inventar 300 x 150 en silencio.

Nuestro conversor de SVG a PNG te indica cuál de los tres casos se ha dado en cada archivo que sueltas, y en el tercero recurre a 512 x 512 en lugar del valor no cuadrado del navegador.

Pregunta dos: ¿qué ha pasado con mis fuentes?#

El texto de un SVG no es una imagen de texto. Es una cadena, más el nombre de una fuente que se supone que existe en otro sitio. Un SVG que dice font-family="Brandon Grotesque" no contiene nada de Brandon Grotesque.

Cabría esperar que una regla @font-face dentro del SVG lo resolviera. No lo hace. Probamos un SVG con una fuente web remota en los tres navegadores, vigilando la red: cero peticiones de la fuente, en todos los motores. El texto se dibujó igualmente, en una tipografía de reserva y con otro ancho.

Ese es todo el mecanismo detrás de "por qué mi texto se ve mal después de convertir". Solo dos clases de texto sobreviven intactas:

  • Las fuentes instaladas en la máquina que hace la conversión. Es decir, tu PNG puede salir distinto en tu portátil y en el de tu compañera.
  • El texto ya convertido a contornos. En Illustrator es Texto > Crear contornos; en Figma, Flatten. Cuando cada letra es un trazado, no hay ninguna fuente que pueda faltar.

Si el texto importa, conviértelo a contornos antes de exportar. Es la única respuesta fiable, y conviene saber que se trata de una propiedad del formato y no del defecto de un conversor concreto.

Pregunta tres: ¿qué tiene permiso para ejecutarse?#

SVG no es un formato de imagen en el sentido en que PNG lo es. Es un documento XML, y los documentos XML pueden contener scripts. Un SVG puede llevar etiquetas <script>, manejadores onload, referencias a imágenes remotas y reglas @import que arrastran hojas de estilo externas.

Por eso algunos gestores de contenidos rechazan de plano la subida de SVG.

La buena noticia, que también medimos: renderizar un SVG a través de una etiqueta <img> en vez de inyectarlo en la página es una caja de arena real. Con un archivo que llevaba un <script> incrustado, un <image href> remoto, un xlink:href, un @import y un @font-face remoto, los tres navegadores no ejecutaron ningún script y no hicieron ninguna petición de red - confirmado tanto desde dentro de la página como desde fuera.

Así que a un conversor que renderiza tu SVG de esta forma no se le puede hacer ejecutar nada. El nuestro informa igualmente de lo que ha encontrado, porque que te digan que tu logo llevaba un píxel de seguimiento es más útil que eliminarlo en silencio.

Lo único que sigue pintándose es una URI data:, una imagen incrustada directamente en el SVG como texto. Es intencionado: es autocontenida, así que no hay nada que descargar.

Dónde muerde esto de verdad#

No en la conversión. Muerde cuando coges el código fuente SVG y lo pegas en tu propia página, en línea, donde ninguna de esas protecciones se aplica. Si haces eso, con un set de iconos o con la salida de un optimizador, el archivo hay que limpiarlo antes. Por eso nuestro optimizador de SVG sanea en cada pasada, se lo pidas o no: te devuelve código fuente, y el código fuente acaba en un DOM.

Lo que nada de esto cambia#

Dos cosas sobreviven exactas a la conversión, y conviene saberlo para no buscar problemas que no existen.

La transparencia. PNG lleva un canal alfa completo, así que todo lo que tu SVG no pinta sigue siendo realmente transparente, y los rellenos semitransparentes conservan su opacidad parcial. Verificado píxel a píxel en los tres motores.

La nitidez en cualquier tamaño que pidas. Esta es la ventaja real de partir de un vector. Una exportación a 2x no es una imagen duplicada: el dibujo se vuelve a renderizar desde la geometría al tamaño mayor, así que las curvas siguen siendo matemáticamente nítidas. Por eso exportar a 2x gana a ampliar el PNG después, y por eso un icono de 16 px renderizado desde el vector gana a uno reducido desde 512 px.

Eso último se puede medir. En una marca con bordes alineados a la rejilla, dibujar directamente a 16 x 16 dio 141 píxeles sólidos y ninguno semitransparente; la misma obra reducida desde un render de 512 px dio 98 sólidos y 64 borrosos. El cuarenta por ciento de la tinta se convirtió en papilla, y por eso nuestro generador de favicons renderiza cada tamaño por separado en lugar de encoger uno grande.

La versión corta#

  • Tamaño: analiza width/height, recurre a la viewBox y no te fíes nunca de lo que informa el navegador.
  • Fuentes: no viajan. Convierte el texto a contornos antes de exportar si importa.
  • Scripts: no pueden ejecutarse durante la conversión, pero sí en cuanto pegas código SVG en una página.
  • Transparencia y nitidez: ambas sobreviven. Exporta al tamaño que necesitas en vez de redimensionar después.

Prueba las herramientas

Gratis, privado e instantáneo. Todo funciona en tu navegador.