Conversor de imágenes a Base64

Convierte cualquier imagen en una cadena Base64 o en un URI de datos.

Arrastra y suelta una imagen aquí, o haz clic para seleccionar

PNG, JPG, GIF, SVG, WebP

Acerca de la imagen a Base64

La codificación Base64 convierte los datos binarios de una imagen en texto ASCII, lo que permite integrar imágenes directamente en HTML, CSS o JSON sin archivos externos. El formato URI de datos (data:image/png;base64,…) puede usarse en los atributos src de los <img> y las propiedades CSS background-image. Ten en cuenta: las imágenes codificadas en Base64 son aproximadamente un 33 % más voluminosas que el archivo original.

Cómo funciona

  1. Arrastra o elige una imagen. El navegador lee el archivo localmente con la API FileReader. No se sube nada a ningún sitio.
  2. El codificador convierte los bytes usando el alfabeto Base64 estándar: cada 3 bytes de entrada se convierten en 4 caracteres ASCII tomados de A-Z a-z 0-9 + /, con hasta dos caracteres de relleno = al final cuando la longitud de la entrada no es múltiplo de 3.
  3. Copia lo que necesites. «Copiar el Base64» te da solo la cadena codificada (útil para cargas útiles JSON o procesamiento en el backend). «Copiar el URI de datos» te da la forma completa data:image/png;base64,… lista para colocar en un atributo <img src> o en un background-image: url(…) de CSS.
  4. Pégalo donde corresponda. La salida es texto plano: funciona en HTML, CSS, JSON, JavaScript, Markdown o en cualquier otro lugar donde pueda existir una cadena.

Qué hace realmente Base64

Base64 está definido en RFC 4648 (octubre de 2006). La codificación toma 24 bits de entrada cada vez (tres bytes) y los reescribe como cuatro índices de 6 bits en un alfabeto de 64 caracteres. Las matemáticas son exactas: 3 bytes (24 bits) → 4 caracteres (cada uno con 6 bits). Cuando la longitud de la entrada no es múltiplo de 3, el codificador añade caracteres de relleno = para que la longitud de la salida sea múltiplo de 4.

Dos consecuencias prácticas:

El RFC 4648, en su §12, expone una limitación importante: «La codificación Base64 oculta visualmente información que de otro modo sería fácilmente reconocible, como las contraseñas, pero no proporciona ninguna confidencialidad computacional». Cualquiera puede decodificar una cadena Base64 en dos líneas de código en cualquier lenguaje. Es codificación, no cifrado.

Los URI de datos: la forma de imagen en línea

Un «URI de datos» es el formato contenedor que permite que una cadena Base64 ocupe el lugar de la URL de una imagen. RFC 2397 (1998) define la sintaxis:

data:[<mediatype>][;base64],<data>

Para las imágenes, eso significa data:image/png;base64,iVBORw0KGgo… en un atributo <img src> o background-image: url("data:image/svg+xml;utf8,<svg…>") en CSS. El token ;base64 le dice al navegador que la parte de datos está codificada; sin él, los datos se toman como texto codificado en porcentajes. El propio RFC 2397 señala que los URI de datos «solo son útiles para valores cortos», una indicación que ha envejecido hasta convertirse en una regla de rendimiento estricta.

Cuándo deberías incrustar una imagen como Base64

Cuándo no deberías incrustar una imagen como Base64

Para la mayoría de los sitios web de producción, una imagen Base64 incrustada es más lenta que una referencia <img> normal. Cinco razones que se acumulan:

  1. Un 33 % de sobrecarga de tamaño, siempre. Cada byte cuesta 4/3 de byte después de codificar. Una vez que se aplica gzip, la sobrecarga aparente se reduce (porque Base64 es repetitivo), pero los bytes que el navegador analiza siguen siendo un 33 % más grandes que el original.
  2. La imagen no se puede almacenar en caché por separado. Un image.png externo se descarga una vez y se reutiliza en todas las páginas que enlazan con él. Una imagen Base64 vive dentro del HTML o el CSS y se vuelve a descargar con cada cambio de ese archivo.
  3. Ralentiza el análisis de HTML y CSS. Las cadenas largas incrustadas dentro de un CSS que bloquea el renderizado alejan aún más la ruta crítica. Harry Roberts (CSS Wizardry) midió una hoja de estilos real de un cliente con 925 KB con imágenes Base64 frente a 708 KB sin ellas, y 232 KB comprimidos con gzip frente a 68 KB. Eliminar Base64 redujo el CSS comprimido con gzip en un 70,68 %.
  4. No se puede aplicar carga diferida. El atributo loading="lazy" aplaza la descarga de una imagen hasta que el usuario se desplaza cerca de ella. Las imágenes Base64 ya están en el documento: no hay nada que aplazar.
  5. HTTP/2 y HTTP/3 ya resolvieron el problema de «demasiadas peticiones». La multiplexación permite que una sola conexión entregue cientos de archivos en paralelo, así que la justificación original para incrustar ha desaparecido en su mayor parte.

Una regla práctica de PageSpeed de Google y de la mayoría de los autores sobre rendimiento: incrusta solo si la imagen pesa menos de ~1-2 KB codificada, y solo si aparece en la parte visible dentro del CSS crítico. Cualquier cosa más grande casi con seguridad rinde mejor como archivo aparte.

SVG: usa codificación UTF-8, no Base64

El SVG ya es texto, así que codificarlo como Base64 desperdicia ~33 % de bytes sin ningún beneficio. La forma más pequeña es UTF-8 codificado para URL:

/* Base64 SVG (longer) */
background-image: url("data:image/svg+xml;base64,PHN2ZyB4bWxucz0i…");

/* URL-encoded SVG (shorter, also human-readable) */
background-image: url("data:image/svg+xml;utf8,<svg xmlns='http://www.w3.org/2000/svg' …>");

La mayoría de las herramientas de compilación modernas (postcss-inline-svg de PostCSS, svg-url-loader de Webpack) emiten la forma codificada para URL de manera predeterminada. Para el SVG en línea, prefiere esa forma antes que Base64, salvo que un consumidor concreto requiera ;base64.

Tipos MIME que esta herramienta reconoce

El prefijo de tipo de medio del URI de datos es lo que le indica al consumidor cómo interpretar los bytes. El navegador lo detecta a partir del archivo que eliges:

ArchivoPrefijo MIME
PNGdata:image/png;base64,…
JPEGdata:image/jpeg;base64,…
GIFdata:image/gif;base64,…
SVGdata:image/svg+xml;base64,… (considera codificar para URL en su lugar)
WebPdata:image/webp;base64,…
AVIFdata:image/avif;base64,…
BMPdata:image/bmp;base64,…
ICOdata:image/x-icon;base64,…

Notas de privacidad y seguridad

La mayoría de los sitios de «imagen a Base64» en línea suben tu archivo a su servidor, lo codifican allí y te devuelven el resultado. Eso significa que las capturas de pantalla de una interfaz no publicada, los diseños sujetos a NDA, las fotos de menores, las exploraciones médicas o las firmas en contratos atraviesan la infraestructura de un tercero. Esta herramienta codifica localmente: el FileReader del navegador lee el archivo en memoria, el codificador se ejecuta en JavaScript en tu dispositivo, y lo único que sale de la página es la cadena codificada cuando la copias.

Dos notas sobre la Política de Seguridad de Contenido (CSP) que conviene conocer si publicas imágenes Base64 en producción:

Errores frecuentes

  1. Tratar Base64 como ofuscación. No lo es. Cualquiera puede decodificarlo en dos líneas de cualquier lenguaje. No pongas credenciales, claves de API ni datos sensibles dentro de cadenas Base64 «para ocultarlos».
  2. Incrustar una imagen principal de 200 KB. La imagen se convierte en 266 KB codificada, se queda atascada dentro del HTML, no se puede almacenar en caché por separado, no se puede cargar de forma diferida y el primer pintado de la página es visiblemente más lento. Sírvela como un archivo normal.
  3. Copiar el Base64 sin procesar cuando necesitabas el URI de datos. Una cadena Base64 desnuda en un atributo <img src> se muestra como rota: necesitas el prefijo data:image/png;base64,. Usa el botón «Copiar el URI de datos».
  4. Codificar SVG como Base64. El SVG ya es texto. Codifícalo para URL en su lugar y ahorra el 33 % de sobrecarga.
  5. Olvidar la CSP. Un img-src 'self' estricto bloquea los URI de datos. Añade data: a la directiva si publicas imágenes Base64.
  6. Intentar decodificar una cadena Base64 con un prefijo data: inicial. La parte data:image/...;base64, son metadatos; quítala antes de pasar la cadena a un decodificador de Base64.
  7. Pegar imágenes confidenciales en un codificador del lado del servidor. Si la URL dice «codificar» pero la pestaña de red muestra un POST, tu imagen acaba de salir de tu máquina.

Preguntas frecuentes

¿Cuál es la diferencia entre «Base64» y «URI de datos»?

Base64 es la codificación (una cadena como iVBORw0KGgo…. Un URI de datos es el contenedor que convierte una cadena Base64 en algo que puede sustituir a la URL de una imagen) data:image/png;base64,iVBORw0KGgo…. El contenedor le indica al navegador el tipo de medio y la codificación para que sepa cómo interpretar los bytes. Los dos botones de esta herramienta te dan cada forma por separado.

¿Es seguro Base64?

No, y no es para eso. Base64 es codificación, no cifrado. El RFC 4648, en su §12, lo dice directamente: «no proporciona ninguna confidencialidad computacional». Cualquiera puede decodificar una cadena Base64 al instante. Si necesitas privacidad, cifra primero los datos (con AES, etc.) y luego codifica en Base64 el texto cifrado para el transporte.

¿Cómo de grande puede ser la imagen?

No hay un límite estricto impuesto por la herramienta, ya que la codificación ocurre en la memoria de tu navegador. El techo práctico es lo que tu dispositivo pueda contener; normalmente, decenas de MB están bien en los portátiles modernos. La mayor restricción es la compatibilidad del consumidor: muchos clientes de correo electrónico, navegadores y API tienen sus propios límites de tamaño de URI de datos, e incrustar cualquier cosa de más de unos pocos KB rara vez tiene sentido por rendimiento.

¿Por qué mi cadena Base64 es un 33 % más grande que el archivo?

Porque cada carácter Base64 lleva 6 bits, mientras que cada byte de entrada lleva 8 bits. La unidad más pequeña que Base64 puede representar sin resto es 3 bytes (24 bits = cuatro caracteres de 6 bits), por lo que la proporción de salida es exactamente 4/3 ≈ 1,33. No hay ninguna variante de Base64 que evite esto: está matemáticamente integrado en la codificación.

¿Funcionará la imagen codificada en el correo electrónico HTML?

Casi siempre, pero no siempre. Apple Mail, el Gmail moderno y la mayoría de los clientes de correo web muestran las imágenes data: sin problemas. Microsoft Outlook de escritorio ha tenido históricamente una compatibilidad inconsistente: algunas versiones muestran los URI de datos bien, otras los eliminan por completo. Prueba en tu lista de clientes de destino antes de depender de imágenes Base64 en correos transaccionales. Para una amplia compatibilidad, las URL de imágenes alojadas siguen siendo la apuesta más segura.

¿Debería usar base64url (con - y _) en su lugar?

Solo si vas a poner los datos codificados en una URL o un nombre de archivo donde + y / tendrían que codificarse en porcentajes de otro modo. Para los atributos <img src> de HTML y los valores background-image de CSS, el alfabeto estándar funciona. El RFC 4648, en su §5, define la variante segura para URL explícitamente para esos casos de URL/nombre de archivo, y advierte que «no debería denominarse solo 'base64'» para evitar confusiones con el alfabeto estándar.

Herramientas relacionadas