Decodificador de imagen Base64
Pega una cadena Base64 para previsualizar y descargar la imagen.
Cómo usar
- Pega una cadena de imagen codificada en Base64 en la zona de entrada. Puede incluir el prefijo
data:image/…o contener solo los datos Base64 en bruto. - Haz clic en Decodificar la imagen para previsualizarla.
- Haz clic en Descargar la imagen para guardarla como archivo PNG.
Preguntas frecuentes
¿Qué formatos Base64 se admiten?
Puedes pegar una cadena Base64 en bruto (la herramienta detecta el formato automáticamente) o un URI de datos completo como data:image/png;base64,iVBOR…. Tipos de imagen admitidos: PNG, JPEG, WebP, GIF, BMP y SVG.
¿Hay un límite de tamaño?
No hay un límite estricto, pero las cadenas Base64 muy voluminosas (más de 5-10 MB) pueden tardar en procesarse según tu dispositivo.
¿Cómo codificar una imagen a Base64?
Usa nuestra herramienta Conversor de imágenes a Base64 · simplemente arrastra y suelta una imagen para obtener su cadena Base64.
Qué es realmente Base64
Base64 es un esquema de codificación de binario a texto definido en el RFC 4648 (octubre de 2006). Usa un alfabeto de 64 caracteres (A-Z, a-z, 0-9, más + y /) para representar bytes arbitrarios como ASCII imprimible. Cada tres bytes de entrada binaria se convierten en exactamente cuatro caracteres de salida, porque el mínimo común múltiplo de 6 bits (un carácter Base64) y 8 bits (un byte) es 24. Esa proporción de cuatro a tres es también la razón por la que un archivo codificado en Base64 es aproximadamente un 33 % más grande que el binario original.
Cuando la longitud de la entrada no es un múltiplo de tres, Base64 rellena con = para que la salida sea siempre un múltiplo de cuatro caracteres: un byte final produce dos caracteres más ==; dos bytes finales producen tres caracteres más =. Algunos codificadores eliminan el relleno, así que un decodificador robusto necesita volver a rellenar antes de pasar la cadena a atob().
El RFC 4648 también define una variante segura para URL (a veces llamada base64url) que intercambia + por - y / por _. Los JWT la usan. Este decodificador normaliza ambos alfabetos para que no tengas que pensar en cuál te han pasado.
El esquema de URI de datos
El RFC 2397 (agosto de 1998) define el esquema de URL data:. La gramática completa es:
data:[<mediatype>][;base64],<data>Un PNG en línea típico tiene este aspecto: data:image/png;base64,iVBORw0KGgo…. El token ;base64 es un marcador (nota la ausencia de un signo =) que le dice al navegador que decodifique la carga útil desde Base64 en lugar de tratarla como texto codificado por porcentajes. Si omites ;base64, los datos se interpretan como texto codificado para URL. Si omites el tipo de medio por completo, la especificación usa por defecto text/plain;charset=US-ASCII.
Este decodificador acepta cualquiera de las dos formas: pega una URI de datos completa o solo la carga útil Base64. Cuando solo se proporciona la carga útil, el formato se detecta a partir de los primeros bytes decodificados, como se ve más abajo.
Cómo se detecta el formato
Si pegas una cadena Base64 en bruto sin el prefijo data:image/…, la única forma de saber qué tipo de imagen es consiste en mirar los primeros bytes decodificados: cada formato de imagen común empieza con una firma reconocible, formalmente llamada «número mágico». Los navegadores hacen exactamente la misma comprobación cuando detectan los tipos MIME (el procedimiento está en el estándar MIME Sniffing de WHATWG). El atajo es que esas firmas se traducen a prefijos Base64 predecibles:
| Formato | Primeros bytes (hex) | Prefijo Base64 |
|---|---|---|
| PNG | 89 50 4E 47 0D 0A 1A 0A | iVBORw0KGgo |
| JPEG | FF D8 FF | /9j/ |
| GIF89a | 47 49 46 38 39 61 | R0lGODlh |
| WebP | 52 49 46 46 … 57 45 42 50 | UklGR |
| BMP | 42 4D («BM») | Qk |
| SVG (texto XML) | empieza por <?xml o <svg | PD94bWwg o PHN2Zw |
La firma de PNG es una de las más ingeniosas del zoológico de formatos. El byte 89 tiene el bit alto activado, de modo que un repetidor de correo de solo 7 bits lo corrompe de forma visible. Los tres bytes siguientes deletrean PNG en ASCII, así que una persona que ejecute head sobre el archivo puede reconocerlo. Luego vienen un final de línea de DOS (0D 0A), un Ctrl-Z de MS-DOS que impide que el antiguo comando TYPE siga imprimiendo, y un avance de línea de Unix (0A): entre ellos detectan cualquier transporte común que «amablemente» reescriba los finales de línea.
De dónde vienen las imágenes Base64
La mayoría de las personas que llegan a una herramienta como esta están depurando algo. Situaciones comunes:
- Respuestas de API JSON. JSON no tiene un tipo binario nativo, así que las API envían imágenes, PDF firmados, fotos de perfil y capturas de pantalla subidas como cadenas Base64 dentro de campos JSON. Pegar el valor aquí te permite ver qué era en realidad.
- CSS y activos empaquetados. Webpack y Vite tienen un umbral de activos pequeños (Vite usa 4 KB por defecto) que incorpora en línea automáticamente las imágenes pequeñas como URI de datos en el CSS o JS empaquetado. Al depurar «¿de dónde viene este icono?», la URI de datos acaba aquí.
- Firmas de correo HTML. Gmail, Outlook y Apple Mail incorporan en línea las imágenes de las firmas como URI de datos para que la imagen sobreviva al reenvío. A veces los diseñadores necesitan recuperar el logotipo original.
- Exportaciones de CMS y Notion. Las exportaciones XML de WordPress, las exportaciones de Notion y las copias de seguridad de Confluence incrustan las miniaturas en línea como Base64 para mantener la exportación autocontenida.
- Códigos QR y paneles de firma. Las bibliotecas de navegador que generan códigos QR (qrcode.js) o capturan firmas manuscritas (signature_pad) suelen exponer su salida como una cadena
data:image/png;base64,…. - Generación de PDF del lado del servidor. Herramientas como Puppeteer, openhtmltopdf e iText aceptan HTML con URI de datos en línea. Cuando un logotipo «no aparece» en el PDF renderizado, decodificar la URI es la forma más rápida de ver si los bytes eran siquiera una imagen.
¿Deberías incorporar las imágenes en línea como Base64?
La disyuntiva solía ser más interesante. Bajo HTTP/1.1, cada imagen era una petición bloqueante independiente, e incorporar en línea un icono diminuto podía ahorrar una ida y vuelta real. Bajo HTTP/2 y HTTP/3, el argumento se ha estrechado mucho. Resumen honesto:
Ganas: cero peticiones HTTP adicionales, entrega atómica y artefactos autocontenidos que funcionan sin dependencias externas (demos de un solo archivo, correo, PDF renderizados en el servidor).
Pierdes: el navegador no puede almacenar en caché por separado una URI de datos en línea, así que la misma imagen en diez páginas se vuelve a descargar con cada respuesta HTML. El activo codificado es aproximadamente un 33 % más grande que el equivalente binario. Las CDN no pueden deduplicar las imágenes incrustadas en varias páginas. Las canalizaciones de optimización de imágenes (Cloudinary, Vercel, <Image> de Next.js) no pueden inspeccionar, comprimir, redimensionar ni servir formatos modernos como AVIF o WebP para los activos en línea. El navegador también tiene que decodificar primero el Base64 y la imagen en segundo lugar, lo que supone CPU adicional en cada renderizado.
Reglas generales razonables: incorpora en línea las imágenes de menos de unos 4 KB usadas en un solo lugar, los marcadores de posición de un solo píxel y las imágenes que necesitan viajar dentro de un archivo autocontenido. No incorpores en línea nada usado en más de una página, nada de más de unos 4 KB, nada que deba cargarse de forma diferida ni nada que se beneficie de la negociación de formato.
Seguridad: lo que Base64 no hace
Base64 es codificación, no cifrado. El §12 del RFC 4648 advierte explícitamente que «oculta visualmente» los datos, pero no proporciona «ninguna confidencialidad computacional»: cualquiera puede decodificarlo al instante. No codifiques contraseñas ni claves de API en Base64 pensando que es una medida de seguridad.
Dos detalles de seguridad que conviene conocer:
- La navegación de nivel superior a las URL
data:está bloqueada en los navegadores modernos (abrir una en una pestaña nueva no funcionará) para mitigar los ataques de phishing que renderizaban páginas de inicio de sesión falsas a partir de URI de datos. El uso como subrecurso (<img src="data:…">,url(data:…)en CSS) sigue estando permitido. - El SVG es especial. El SVG es XML, y los documentos SVG pueden contener elementos
<script>y manejadores de eventos. Cargar un SVG en una etiqueta<img>es seguro (los navegadores ejecutan un renderizador con scripts deshabilitados), pero cargar el mismo SVG en un<object>o un<iframe>puede ejecutar JavaScript arbitrario. Este decodificador solo establece<img src>, que es la vía segura. Si decodificaste un SVG de una fuente no confiable, trata el archivo como cualquier otro documento no confiable.
Más preguntas
¿Por qué mi cadena Base64 falla con «InvalidCharacterError»?
Tres causas habituales: espacios en blanco o saltos de línea perdidos de un copiar y pegar (el antiguo perfil MIME de Base64 ajusta las líneas a 76 caracteres, lo que el atob() de JavaScript rechaza); Base64 segura para URL con - y _ en lugar de + y /; o un relleno = final eliminado, de modo que la longitud no es un múltiplo de cuatro. Este decodificador limpia los espacios en blanco, normaliza el alfabeto y vuelve a rellenar antes de decodificar, pero las cadenas muy corruptas aún fallan.
¿Pierdo calidad al decodificar?
No. La decodificación es el inverso exacto de la codificación: recuperas byte a byte la imagen original. La descarga está en el formato que estuviera en el Base64 (PNG, JPEG, WebP, GIF, BMP o SVG), sin paso de recodificación.
¿Cuál es la URI de datos más grande que aceptará un navegador?
Según MDN, los límites actuales rondan los 512 MB en Chromium y Firefox, y los 2 GB en Safari/WebKit. En la práctica, el cuello de botella es la memoria y la CPU más que la especificación de la URL: los pegados de más de unos 10 MB empiezan a notarse lentos en un portátil típico.
¿Se envía algo a un servidor?
No. La decodificación ocurre íntegramente en tu navegador mediante la función nativa atob() y un Blob o una URI de datos asignada a una etiqueta <img>. No se sube nada; la página funciona sin conexión una vez cargada.
¿Por qué el Base64 de todos los JPEG empieza por /9j/?
Casi todos los archivos JPEG del mundo empiezan con los bytes FF D8 FF (el marcador de inicio de imagen seguido de otro byte de marcador). Cuando codificas en Base64 tres bytes que son todos FF con un D8 en medio, el patrón de bits 11111111 11011000 11111111 se divide en grupos de 6 bits 111111 111101 100011 111111: las posiciones 63, 61, 35, 63 del alfabeto Base64, que deletrean /9j/. El cuarto carácter varía entonces según el marcador que siga (E0 para JFIF, E1 para Exif), pero los tres primeros son universales.