Base64
Codificar y decodificar Base64 online
Escribe a un lado y ve el resultado al otro, en los dos sentidos y al momento. Con los acentos y los emojis en su sitio, la variante segura para URL y una pestaña para convertir archivos e imágenes con su data URL listo para pegar.
Ni el texto ni los archivos salen de tu equipo: se convierten aquí dentro.
Por qué importa que esto no se suba
Lo que se pega en un codificador de Base64 casi nunca es inocente: una cabecera de autenticación con usuario y contraseña, un token de acceso, la clave de un certificado, el logotipo de un cliente o un PDF interno. Y como Base64 no cifra nada, mandar esa cadena al servidor de una web cualquiera para que te la traduzca es entregarla en claro. Aquí no hay a dónde mandarla: el texto y los archivos se convierten en tu pestaña y se quedan ahí.
Cómo funciona, en 3 pasos
-
Elige el lado
Escribe texto a la izquierda y sale el Base64; pega Base64 a la derecha y sale el texto. No hay que pulsar nada: la herramienta detecta sola en cuál estás escribiendo.
-
O suelta un archivo
En la pestaña de archivos, arrastra una imagen o un PDF y obtienes la cadena, el data URL y el peso resultante. El camino inverso también: pega un data URL y descarga el archivo.
-
Cópialo
Con el formato que necesites: solo la cadena, el data URL entero, la línea de CSS o la etiqueta de HTML. Si el Base64 está roto, primero te decimos dónde.
Para qué se usa Base64 de verdad
-
Cabeceras de autenticaciónLa autenticación HTTP Basic manda
usuario:contraseñaen Base64 dentro de la cabeceraAuthorization. Decodificarla es la forma más rápida de ver qué credenciales está usando de verdad una integración. - Imágenes dentro del CSS o del correoUn icono pequeño incrustado como data URL se ahorra una petición, y en un correo HTML se ve aunque el cliente bloquee las imágenes externas.
- Tokens JWTLas dos primeras partes de un JWT son JSON en Base64 para URL. Decodificarlas enseña qué caduca cuándo y con qué permisos, sin instalar nada.
- Archivos dentro de un JSONMuchas APIs solo aceptan texto, así que un adjunto viaja como cadena Base64 dentro del cuerpo de la petición. Convertirlo a mano para probar es el uso diario.
- Adjuntos de correoEl correo nació hablando solo texto de 7 bits, así que todos los adjuntos van en Base64 cortado en líneas de 76 caracteres. De ahí esa opción de la herramienta.
- Certificados y clavesUn archivo PEM es exactamente eso: bytes en Base64 entre dos líneas de guiones. Por eso se pueden pegar en un correo sin que se rompan.
Qué hace Base64 exactamente
Base64 coge un archivo o un texto y lo reescribe usando solo 64 caracteres que sobreviven a cualquier canal: las 26 letras mayúsculas, las 26 minúsculas, los diez dígitos y los signos + y /. La mecánica es simple: se agarran 3 bytes seguidos, que son 24 bits, y se reparten en 4 grupos de 6 bits; cada grupo de 6 bits es un número del 0 al 63, y ese número es una posición en el alfabeto. Cuando el total no es múltiplo de 3 se añaden uno o dos signos = al final para que el que reciba la cadena sepa cuántos bytes reales había.
De ahí sale la única cifra que conviene recordar: 4 caracteres por cada 3 bytes, es decir, un 33 % más de peso. No es un efecto secundario ni depende de la implementación; es la definición.
¿Y para qué molestarse? Porque hay canales que solo entienden texto. El correo electrónico nació hablando ASCII de 7 bits y sigue igual por dentro; una URL no admite cualquier byte; un campo de JSON es una cadena. Meter los bytes crudos de un PNG en cualquiera de esos sitios los destroza: alguien por el camino reinterpreta un salto de línea o corta en el byte cero. Base64 es el peaje que se paga para que los datos lleguen enteros.
Los acentos y los emojis, que es donde se cae media internet
Prueba a escribir ñ en cualquier codificador de Base64 y verás que una buena parte devuelve algo raro, o directamente falla. El motivo es siempre el mismo: usan btoa, la función que trae el navegador, que solo admite caracteres del 0 al 255. Con una eñe lanza una excepción, y el apaño que lleva veinte años circulando es btoa(unescape(encodeURIComponent(texto))), que se apoya en una función obsoleta y se rompe con los emojis, porque en JavaScript ocupan dos unidades y no una.
Esta herramienta no usa btoa. El texto se convierte primero a bytes UTF-8 y son esos bytes los que se codifican, que es el camino correcto y el que espera cualquier otro sistema al otro lado. Al decodificar se hace lo mismo al revés en modo estricto: si los bytes no son texto UTF-8 válido se te dice, en lugar de devolverte una fila de rombos con interrogación y dejar que lo descubras cuando ya está en producción. El resultado está comprobado contra los vectores de prueba de la norma RFC 4648 y contra acentos, emojis con uniones de ancho cero y japonés.
Cuándo incrustar una imagen y cuándo no
Convertir una imagen a Base64 sirve para meterla dentro del propio código, como data:image/png;base64,…, y ahorrarse la petición. Es una buena idea con archivos pequeños que hacen falta ya: un icono, una textura repetida, el logotipo de una firma de correo —que es justo por lo que las firmas usan Base64: así la imagen se ve aunque el cliente de correo bloquee lo externo—.
Con archivos grandes es mala idea, y por cuatro motivos que se suman: pesa un tercio más; viaja dentro del CSS o del HTML, que son lo primero que bloquea el pintado de la página; no se guarda en la caché por separado, así que tocar una coma de la hoja de estilos obliga a volver a bajar la imagen entera; y no se puede servir en varios tamaños ni en formatos modernos. Una foto de 300 KB incrustada son casi 400 KB pegados a tu CSS que se descargan siempre, la vea el visitante o no. La línea práctica está alrededor de los 5 o 10 KB, y por eso la herramienta te enseña el peso del data URL con un aviso antes de que copies nada.
Si lo que te sobra es peso en las imágenes, el sitio equivocado para arreglarlo es este: eso lo hace el compresor de imágenes, también sin subir nada.
Y si lo que necesitas es la huella de unos bytes en vez de su reescritura —el SHA-256 de un archivo, o el SHA-384 en Base64 de una cabecera de integridad—, eso lo hace el generador de hash, que también trabaja sin subir nada.
Cuando la cadena está rota, decimos dónde
La función atob del navegador acepta cadenas mal formadas y devuelve bytes que no son los que se codificaron, sin decir nada. Aquí se valida de verdad: si aparece un carácter que no existe en el alfabeto, si el relleno está en medio, si la longitud no cuadra o si sobra un carácter suelto, se te dice cuál es el problema, en qué línea y columna está y se te enseña el trozo con el carácter marcado, con un botón que te lleva ahí.
Y hay un caso que casi ninguna herramienta comprueba: una cadena cuyo último carácter deja bits sueltos distintos de cero. Se decodifica sin protestar, pero los bytes que salen no son los que entraron. Significa que alguien la editó a mano o que se copió mal. También se avisa.
Cuando el fallo tiene una causa típica, se dice: una cadena que llega codificada para URL con %2B y %3D, un data URL pegado entero, unas comillas que se colaron al copiar del código, o —la más frecuente de todas— una cadena cortada al copiarla de una terminal.
Preguntas frecuentes
¿Base64 es cifrado? ¿Protege una contraseña?
No, y es el malentendido más extendido que hay con Base64. Cifrar significa que hace falta una clave para volver atrás. Base64 no tiene clave: es una forma de escribir los mismos datos con otros 64 caracteres.
Cualquiera que vea la cadena la puede leer en un segundo. Pruébalo: pega arriba cualquier cadena Base64 «secreta» y ahí está. Por eso una contraseña «en Base64» dentro de un archivo de configuración no está protegida, solo está disimulada.
El ejemplo clásico es la autenticación HTTP Basic, donde usuario y contraseña viajan en Base64 en una cabecera. Lo único que los protege ahí es HTTPS. Si necesitas que nadie pueda leerlo, lo que buscas es cifrado.
¿Cuándo conviene incrustar una imagen y cuándo no?
Sí compensa con archivos pequeños que hacen falta desde el primer momento: por debajo de unos 5 o 10 KB. Iconos, texturas repetidas, el logotipo de una firma de correo, imágenes dentro de un correo HTML que muchos clientes no descargarían de fuera.
No compensa con archivos grandes, por cuatro motivos que se acumulan: pesa un tercio más; viaja dentro del CSS o del HTML, que bloquean el primer pintado; no se guarda en la caché por separado, así que cambiar una coma del CSS obliga a volver a bajar la imagen entera; y no se puede servir en varios tamaños ni en formatos modernos.
Una foto de 300 KB incrustada son casi 400 KB pegados a tu hoja de estilos que se descargan siempre, la vea el visitante o no.
¿Por qué crece alrededor de un tercio?
Porque cada 3 bytes (24 bits) se convierten en 4 caracteres de 6 bits. Cuatro entre tres es 1,333: un 33,3 % más, más uno o dos caracteres de relleno.
Si además se corta en líneas de 76 caracteres, como manda el formato del correo, hay que sumar otro 1,4 % de saltos. La fórmula exacta es 4 × techo(n/3) caracteres para n bytes.
¿Por qué otras herramientas me estropean los acentos y los emojis?
Porque usan btoa, que solo admite caracteres del 0 al 255: con una eñe lanza una excepción. El parche que circula desde hace veinte años es btoa(unescape(encodeURIComponent(texto))), que se apoya en una función obsoleta y se rompe con los emojis.
Aquí el texto se convierte primero a bytes UTF-8 y son esos los que se codifican. Al leer se usa el modo estricto, así que si los bytes no son texto válido se te dice en vez de enseñarte rombos con interrogación.
¿Qué es la variante segura para URL?
El alfabeto normal acaba en + y /, y los dos significan algo dentro de una URL: la barra separa rutas y el más se lee como un espacio en los parámetros. La norma RFC 4648 define una variante que sustituye + por - y / por _, muchas veces sin relleno.
Es la que llevan dentro los tokens JWT, muchos identificadores de sesión y bastantes APIs. Se activa con una casilla, y al decodificar se aceptan las dos sin que tengas que decir cuál es.
¿Para qué sirven los signos igual del final?
Son relleno. Como se trabaja en bloques de 3 bytes, cuando el total no es múltiplo de 3 sobra hueco: con 1 byte de resto se añaden dos = y con 2 bytes de resto, uno. Sirven para saber cuántos bytes reales había al final.
Muchas implementaciones los omiten, sobre todo en la variante para URL. Aquí puedes generar con relleno o sin él, y la lectura acepta las dos formas.
¿Se sube mi archivo a algún servidor?
No. El archivo se lee con la interfaz del propio navegador, se convierte en tu equipo y el resultado se queda en la página. No hay cuentas ni base de datos. Carga la página, desconecta internet y compruébalo: sigue funcionando igual.
¿Hay algún límite de tamaño?
Al soltar un archivo, 12 MB. Por encima, montar en memoria una cadena de más de dieciséis millones de caracteres deja colgado a cualquier navegador, y preferimos decirlo.
En la práctica el límite útil es mucho más bajo: si estás pensando en incrustar varios megas en una página, la respuesta casi siempre es que no conviene. Para el texto del panel dividido no hay tope fijado.
¿Por qué me dice que mi cadena «no es canónica» si se decodifica?
Porque el último carácter lleva bits que sobran y que hay que descartar, y esos bits deberían ser cero. Cuando no lo son, la cadena se decodifica igual pero los bytes que salen no son los que entraron: se editó a mano, se pegó mal o se cambió un carácter.
Casi ninguna herramienta lo comprueba: devuelven los bytes sin decir nada, que es la peor forma de perder un dato.