¿Cuándo conviene usar imágenes en Base64?

La regla general

Incrusta una imagen cuando el coste de una petición aparte supera el coste de los bytes extra. Con las conexiones HTTP/2 y HTTP/3 actuales, las peticiones adicionales son baratas, así que ese punto llega pronto: un buen límite de trabajo es de 2 a 4 KB por imagen. Las herramientas de build más usadas coinciden; Vite incrusta por defecto los recursos de menos de 4 KB y los asset modules de webpack los de menos de 8 KB.

La herramienta de abajo convierte un PNG (o cualquier imagen) en un data URI. Suelta la imagen o ábrela y luego elige cómo copiarla en Copiar como: Data URI, Base64 sin más, una línea CSS background-image lista, una etiqueta img de HTML con ancho y alto, o Markdown. Muestra el tamaño del data URI y cuánto más ocupa que el archivo, y avisa cuando el resultado es tan grande que puede hacer más lenta la página. Las imágenes se convierten en tu navegador y nunca se suben.

Qué pasa al incrustar una imagen

Un data URI como data:image/png;base64,iVBORw0KGgo... mete los bytes de la imagen dentro del HTML, CSS o JSON que la usa. El navegador recibe la imagen junto con ese archivo, sin una descarga aparte. Esa es toda la ventaja. Los costes nacen del mismo hecho:

• Tamaño: Base64 escribe 3 bytes como 4 caracteres, así que la imagen crece cerca de un tercio. La compresión gzip o Brotli del servidor recupera parte de eso durante la transferencia, pero no todo, y las imágenes ya comprimidas (PNG, JPG, WebP) ganan poco.
• Caché: un archivo de imagen aparte se guarda en caché una vez y se reutiliza en todas las páginas. Una imagen incrustada solo se guarda como parte del archivo que la contiene. Cambia una línea del CSS y todos los iconos incrustados se descargan otra vez.
• Bloqueo del renderizado: el CSS bloquea el primer pintado. Cada kilobyte de imágenes incrustadas en una hoja de estilos retrasa el momento en que aparece algo en pantalla, aunque esas imágenes estén al final de la página.
• Sin carga diferida: loading="lazy" y la elección de imagen con srcset pierden sentido, porque los bytes ya llegaron con la página.
• Mantenimiento: una cadena Base64 larga es ilegible en una revisión de código y se rompe fácilmente con una copia mal hecha.

Guía de tamaños: ¿incrustar o archivo aparte?

Buenos usos de las imágenes en Base64

• Iconos pequeños en CSS, como flechas, marcas de verificación, una casilla personalizada o la flecha de un desplegable, que deben aparecer junto con los estilos y nunca de forma tardía.
• Entregables de un solo archivo: un informe HTML, una factura exportada, una página de documentación o un prototipo que debe funcionar al abrirlo desde el disco o al enviarlo como un único adjunto.
• API y bases de datos: JSON no tiene un tipo binario, así que las imágenes en peticiones y respuestas de API (firmas, avatares, documentos escaneados, imágenes de producto en algunas integraciones con marketplaces) suelen enviarse como cadenas Base64.
• Marcadores de imagen de baja calidad: una versión diminuta y borrosa incrustada en el HTML aparece al instante mientras carga la imagen completa.
• Iconos SVG: el SVG es texto, así que muchas veces no necesita Base64. La opción Codificación URL en lugar de Base64 de la herramienta mantiene el SVG legible y suele dar un resultado más corto.

Cuándo evitarlas

• Fotos y cualquier imagen de más de unos 10 KB en una página web. Usa un archivo normal en WebP o AVIF, con ancho y alto definidos y carga diferida para las imágenes que quedan fuera de la primera pantalla.
• La imagen más grande de la parte superior de la página (el elemento LCP). Una imagen grande incrustada vuelve pesado el propio HTML y retrasa todo lo que contiene; precargar un archivo aparte suele ser más rápido.
• Imágenes que se repiten entre páginas, como el logotipo del sitio o un patrón de fondo. Aquí la caché vale más que ahorrar una petición.
• Correos HTML para el público general. Muchos clientes de correo no muestran imágenes en data URI; Gmail y Outlook para Windows son los más conocidos. Usa imágenes alojadas en un servidor o adjuntos referenciados por Content-ID (CID). Los data URI incrustados funcionan sobre todo en Apple Mail y algunas apps móviles, algo insuficiente para un boletín.
• Data URI muy grandes en general. El antiguo Internet Explorer 8 los limitaba a 32 KB; los navegadores actuales aceptan tamaños mucho mayores, pero el rendimiento se resiente mucho antes de llegar a cualquier límite.

Cómo hacerlo bien

Reduce la imagen antes de convertirla. Cada byte que ahorras se multiplica por 4/3 en el data URI, así que comprime los iconos PNG, redimensiona las imágenes más grandes que el tamaño al que se muestran y, para fotos que debas incrustar, como en un JSON, usa JPG o WebP con una calidad razonable. El compresor y el redimensionador de imágenes de este sitio lo hacen en el navegador, y luego puedes traer aquí el archivo más pequeño.

Incluye las dimensiones. Una etiqueta img sin ancho ni alto hace que el diseño salte cuando aparece la imagen. Por eso la salida HTML de esta herramienta incluye el ancho y el alto reales de la imagen.

Conserva el archivo fuente. Guarda el PNG o SVG original en tu proyecto y genera el data URI a partir de él, con tu herramienta de build o con esta herramienta cuando algo cambie. No trates nunca la cadena Base64 como la copia maestra.

Mide. Compara la página con y sin las imágenes incrustadas en el panel Red (Network) del navegador o con Lighthouse. Si el CSS o el HTML crecen bastante y nada va más rápido, vuelve al archivo aparte.