Imagen a Base64 — generador de data URI
Suelta una imagen y obtén un data URI que puedes pegar en una hoja de estilos, en un atributo HTML o en un archivo Markdown. La codificación ocurre en tu navegador, así que la imagen nunca se sube — y eso importa, porque un data URI es el archivo entero escrito en texto plano.
Arrastra una imagen aquí o elige un archivo
PNG, JPG, SVG, GIF, WebP, ICO · una a la vez · no se sube nada
Vista previa
La cadena completa, lista para pegar en un atributo src.
Convertir un data URI de vuelta en una imagen
Qué es en realidad un data URI
Un data URI es un archivo entero escrito como una URL. La forma es fija: el esquema data:, después el tipo de medio, después opcionalmente ;base64, después una coma y después la carga útil. Así que data:image/png;base64,iVBORw0KGgo… dice "lo que sigue es un PNG, codificado en Base64". No se descarga nada de ningún lado; los bytes ya están ahí.
Base64 existe porque una URL no puede contener bytes arbitrarios. Convierte cada tres bytes en cuatro caracteres tomados de un alfabeto de 64 caracteres que sobrevive a ser pegado dentro de un texto. Cuatro caracteres por cada tres bytes es de donde sale la sobrecarga del 33%, y no hay forma de evitarla: es aritmética, no un detalle de implementación. El relleno con = al final redondea la entrada hasta un múltiplo de tres.
Vale la pena decirlo claro: Base64 no es compresión y no es cifrado. Hace el archivo más grande y cualquiera puede volver a leerlo. Las estadísticas de arriba muestran el costo real.
Cuándo vale la pena incrustar
El argumento a favor de un data URI es que elimina una petición de red. Ese argumento era mucho más fuerte antes de HTTP/2, cuando los navegadores abrían un puñado de conexiones por host y cada archivo extra hacía cola detrás de los demás. Hoy la multiplexación abarata las peticiones pequeñas, y los motivos para incrustar se redujeron a unas pocas situaciones:
- Recursos diminutos —iconos, patrones, un degradado de 1 px— por debajo de uno o dos kilobytes, más o menos.
- Algo que tiene que existir aunque el resto del sitio esté inalcanzable, como una página sin conexión.
- Un único archivo que necesitas entregarle a alguien sin nada de hosting detrás: una plantilla de correo HTML que vas a pegar en otro lado, un bookmarklet, un informe autocontenido.
El argumento en contra es el caché. Una imagen referenciada por URL se guarda en caché una sola vez y se reutiliza en todas partes. Esa misma imagen incrustada en una hoja de estilos se vuelve a descargar cada vez que esa hoja cambia, no se puede cargar de forma diferida, no se puede servir en otro formato a los navegadores que lo soporten, y ocupa lugar en la ruta crítica bloqueando el primer renderizado. Incrusta una foto de 200 KB en tu CSS y acabas de hacer que cada página del sitio tarde 270 KB más en empezar a renderizarse.
El SVG no debería ir en Base64, nunca
El SVG ya es texto. Codificarlo en Base64 le suma un tercio de tamaño sin ningún beneficio y lo vuelve ilegible. Codificar con porcentajes el puñado de caracteres que romperían un url() de CSS lo mantiene corto, lo mantiene legible y comprime mucho mejor al viajar, porque gzip encuentra repeticiones en el XML y no encuentra ninguna en Base64. Esta herramienta lo hace automáticamente cuando le das un SVG.
Cosas que te van a complicar la vida
- Los clientes de correo. Gmail y varios otros se niegan a mostrar una imagen que viene de un data URI. Si el destino es un correo, aloja la imagen y enlázala.
- La Content Security Policy. Una política
img-src 'self'bloquea los data URI. Hay que agregarledata:de forma explícita, y algunos equipos no lo van a permitir. - No puedes abrir uno en la barra de direcciones. Los navegadores llevan años bloqueando la navegación de nivel superior hacia las URL
data:, porque era un truco de phishing fácil. Usa el panel del decodificador que está más arriba. - El soporte en Markdown es irregular. Funciona en muchos renderizadores y GitHub lo elimina en los comentarios.
- Las cadenas largas son lentas de editar. Un megabyte de Base64 en una caja de texto va a volver lento tu editor, y también esta página. Eso es una pista de lo que le va a hacer a tu build.
El decodificador es deliberadamente permisivo: si pegas una carga útil sin el prefijo data:, mira los primeros caracteres y adivina el formato a partir de ellos, porque los bytes iniciales de PNG, JPEG, GIF y WebP son lo bastante distintivos como para sobrevivir a la codificación Base64. Una carga útil que un cliente de correo cortó en varias líneas sigue funcionando; una que quedó truncada se va a decodificar y después no se va a poder mostrar.
Preguntas frecuentes
¿Por qué la versión en Base64 es más grande que el archivo original?
Porque Base64 gasta cuatro caracteres por cada tres bytes, lo que da un aumento fijo del 33%, más unos pocos caracteres del prefijo. Es una codificación, no un formato de compresión. Si necesitas que el archivo pese menos, comprime la imagen antes de codificarla.
¿Conviene incrustar imágenes como data URI?
Solo las pequeñas. Por debajo de uno o dos kilobytes, la petición que te ahorras lo justifica. Por encima de eso, perder el caché por separado, la carga diferida y la negociación de formato cuesta más de lo que jamás costó esa petición, sobre todo con HTTP/2.
¿Puedo usar un data URI en un correo?
Normalmente no. Gmail y varios otros clientes bloquean los data URI en las etiquetas de imagen, así que quien lo reciba ve una imagen rota. Aloja el archivo en algún lado y usa una URL normal, por incómodo que resulte.
¿Cuál es el largo máximo de un data URI?
En los navegadores actuales no hay límite para una imagen en un src o en un url() de CSS. El límite práctico es tu paciencia: las cadenas muy largas hacen más lento el análisis, la edición y cada paso del build que toque el archivo.
¿Se sube mi imagen cuando la codifico?
No. El archivo se lee con la API FileReader del navegador y se codifica localmente. Nunca sale de tu dispositivo, algo que aquí importa más que de costumbre, porque un data URI es una copia completa del archivo en texto plano.
Última actualización 19 de septiembre de 2026