Convertir Imagen a Base64

Qué es en realidad un data URI

Un data URI es una URL que lleva su propia carga dentro en lugar de apuntar a un archivo que está en otro sitio. El esquema se estandarizó allá por 1998 y tiene una forma sencilla, data:<tipo>;base64,<carga>: un tipo MIME que le dice al navegador cómo interpretar lo que viene detrás, y luego los bytes reescritos con los 64 caracteres imprimibles A-Z, a-z, 0-9, + y /. No tiene nada de específico de las imágenes. El mismo mecanismo transporta tipografías, PDFs, JSON y texto plano; las imágenes son solo el caso con el que casi todo el mundo se topa primero.

Como el resultado es texto corriente, cabe en cualquier sitio donde quepa texto. En eso consiste todo su atractivo. Un atributo src de HTML, un url() de CSS, un valor en un JSON de configuración, un archivo Markdown, un secreto de Kubernetes: ninguno de ellos puede contener un archivo binario, y todos pueden contener una cadena larga.

Cuando eliges un archivo arriba, la codificación la hace el propio FileReader.readAsDataURL de tu navegador, y por eso la salida aparece en cuanto termina la lectura y por eso no hay ninguna subida de por medio. Después la herramienta vuelve a extraer el tipo MIME de la cadena que produjo el navegador, así que el tipo que ves es el que tu propio navegador le asignó al archivo, no uno deducido de la extensión.

El recargo del 33 % que cobra todo data URI

Base64 gasta cuatro caracteres por cada tres bytes, y la aritmética es exacta: ceil(bytes / 3) * 4. Un favicon de 300 bytes se convierte en 400 caracteres. Un icono de 3 KB se convierte en 4 KB de texto. Una foto de 1,5 MB se convierte en unos 2 MB de caracteres encajados en mitad de una hoja de estilos, que es exactamente por lo que nadie debería hacer eso. La nota que hay bajo la previsualización informa de las cifras reales del archivo que has elegido, no de la regla general, para que veas el coste antes de comprometerte con él.

La compresión del transporte recupera parte del recargo, porque el texto Base64 se comprime mejor de lo que se comprimían los bytes originales, pero nunca te devuelve al tamaño de partida y no hace nada por el coste de memoria y de análisis de una hoja de estilos con un megabyte de texto dentro.

Incrustarlo o dejar el archivo: cómo decidir

El intercambio de verdad no es el tamaño, es la caché. Una imagen enlazada es un recurso aparte con su propia entrada de caché: cambias el logotipo y solo se vuelve a descargar el logotipo. Una imagen incrustada vive dentro del archivo que la referencia, así que tocar el icono invalida la hoja de estilos entera para todos los visitantes que vuelven, y el navegador tiene que terminar de leer esa hoja de estilos antes de poder pintar nada.

Eso apunta a una recomendación clara. Incrusta sin reparos por debajo de unos 4 KB, que cubre de sobra favicons, iconos SVG pequeños, un píxel de seguimiento de 1x1, una flechita, un indicador de carga. Trata la franja de 4 KB a 10 KB como un juicio de valor según cuántas páginas necesiten ese recurso. Por encima de 10 KB, deja el archivo donde está. Y la excepción que la gente espera que funcione, incrustar imágenes en el correo, es justo la que normalmente no funciona: el cliente web de Gmail rechaza las imágenes en data:, así que un recurso incrustado en un correo se ve como un hueco vacío para una parte importante de los destinatarios.

Las tres salidas, y cómo copiarlas

1. Deja seleccionado Imagen → Base64 y elige un archivo en Subir una imagen para convertir a Base64.
2. Copia el data URI en Base64 por separado si vas a pegarlo tú en un atributo, en un valor de configuración o en un fixture de test.
3. Rellena el texto alternativo antes de copiar el fragmento <img> de HTML. El texto alternativo se escapa por ti, así que Tom & Jerry "reunión" sigue siendo HTML válido en lugar de cerrar el atributo antes de tiempo.
4. Llévate el fragmento background-image de CSS para una hoja de estilos. La URL va entre comillas dobles a propósito: el alfabeto de Base64 no contiene ninguna comilla, así que entrecomillar es siempre seguro y sobrevive a los minificadores y preprocesadores que estropean un url(...) sin comillas.

Convertir una cadena Base64 misteriosa de vuelta en una imagen

El sentido inverso existe porque el Base64 aparece en sitios donde no puedes saber qué es: un informe de error, la respuesta de una API, un CSS que escribió otra persona, una columna de una base de datos. Un data URI completo declara su propio tipo y se puede renderizar sin más. Una carga suelta no declara nada, porque el Base64 no tiene cabecera.

Así que la herramienta decodifica solo los primeros bytes y los compara con las firmas de imagen conocidas: 89 50 4E 47 para PNG, FF D8 FF para JPEG, el GIF8 en ASCII para GIF, BM para BMP, y el contenedor RIFF con un marcador WEBP ocho bytes más adelante. Eso es detección de verdad, no una suposición. Cuando no encaja nada, recurre a image/png y lo dice con todas las letras, porque un recurso de reserva honesto es mejor que uno equivocado en silencio. Las cargas en la variante segura para URLs, que usan - y _ en lugar de + y /, se traducen de vuelta antes de decodificar, y un data URI legítimo cuya carga no es Base64 en absoluto, como data:text/plain,hola, recibe una explicación en vez de un icono de imagen rota.

Dónde se detiene esta herramienta

Merece la pena conocer tres límites. El primero, el SVG. Tu navegador produce siempre una carga Base64 para él, pero el Base64 es la menos eficiente de las dos codificaciones legales para SVG: porcentaje-codificar un SVG suele salir más pequeño y además se queda legible y editable dentro de la hoja de estilos. Si prefieres enviar un ráster, convertir SVG a PNG lo hace. El segundo, aquí no se encoge tu imagen. Como cada byte que quitas elimina alrededor de 1,33 caracteres de salida, pasar el archivo antes por comprimir imágenes o redimensionar imagen es muchísimo más eficaz que buscar una codificación más corta. El tercero, trabaja con un archivo por conversión, y es deliberado; el sentido de esta página es una única cadena que inspeccionas y copias, no un lote.