Cómo funciona la codificación Base64 (y por qué no es cifrado)

Qué hace realmente Base64 a nivel de bits

Base64 convierte 3 bytes de entrada en 4 caracteres de salida volviendo a dividir 24 bits en cuatro grupos de 6 bits cada uno. Un byte contiene 8 bits, así que tres bytes dan 24 bits; 24 se divide de forma exacta entre 6, produciendo cuatro números de 6 bits que van de 0 a 63. Cada uno de esos números indexa en un alfabeto de 64 caracteres: A-Z (0-25), a-z (26-51), 0-9 (52-61) y dos símbolos para el 62 y el 63.

Toma los tres bytes ASCII de «Man»: M=77, a=97, n=110, que en binario son 01001101 01100001 01101110. Concatenada, esa cadena de 24 bits se reagrupa como 010011 010110 000101 101110, o los valores decimales 19, 22, 5, 46. Al indexar el alfabeto se obtiene T, W, F, u, así que «Man» se codifica como «TWFu». La transformación es puramente mecánica y sin pérdidas.

La sobrecarga del 33 % es la estadística que define el formato: 4 bytes de salida por cada 3 bytes de entrada es una proporción de 4/3, un aumento del 33,3 % antes de cualquier relleno por saltos de línea. La codificación MIME estándar añade una penalización pequeña adicional al insertar un salto de línea cada 76 caracteres, empujando la sobrecarga real ligeramente por encima del 33 %.

Por qué Base64 NO es cifrado ni seguridad

Base64 es una codificación, no un cifrado, porque no usa clave y cualquiera puede decodificarlo al instante con un algoritmo público y estandarizado. El cifrado transforma los datos de modo que solo quien tenga la clave correcta pueda recuperarlos; Base64 transforma los datos de modo que cualquier dispositivo del planeta pueda recuperarlos, que es el objetivo exactamente opuesto. Tratar una cadena Base64 como un secreto es un error de seguridad clásico.

La confusión surge porque la salida de Base64 le parece ilegible a un humano, todo letras y dígitos con algún que otro +, / o =. Pero que sea ilegible para un humano no es lo mismo que estar protegido. Un solo comando como `base64 -d` en la línea de comandos, o un fragmento de dos líneas en cualquier lenguaje, devuelve los bytes originales sin necesidad de credenciales.

La regla a recordar: nunca guardes contraseñas, claves de API, tokens ni datos personales en Base64 creyendo que oculta algo. Base64 hace que los datos binarios sean seguros de transportar por canales de solo texto; no hace que nada sea seguro frente a ojos curiosos. Si necesitas confidencialidad, necesitas cifrado real como AES, aplicado antes de codificar el texto cifrado en Base64 para su transporte.

El relleno =, los caracteres +/ y la variante Base64URL

El carácter = es relleno que señala cuántos bytes le faltaban al grupo final, y aparece solo al final de una cadena Base64. Cuando la longitud de la entrada no es múltiplo de 3, el último grupo contiene 1 o 2 bytes en lugar de 3; el codificador rellena con ceros los bits que faltan y añade un = (para un resto de 2 bytes) o dos == (para un resto de 1 byte) de modo que la longitud de la salida siga siendo un múltiplo limpio de 4.

El Base64 estándar usa + y / para los valores 62 y 63, pero esos caracteres son inseguros en URLs y nombres de archivo: + puede interpretarse como un espacio en las cadenas de consulta, y / es un separador de rutas. Base64URL, definido en el RFC 4648, los cambia por - y _ respectivamente, y normalmente omite el relleno =, para que un token pueda viajar dentro de una URL o un nombre de archivo sin tocar. Los JSON Web Tokens usan Base64URL precisamente por esta razón.

La tabla siguiente compara las tres variantes que te encontrarás en la práctica.

Cuándo usar Base64 y cuándo no

Usa Base64 siempre que los datos binarios deban pasar por un canal que solo transporta texto de forma fiable: imágenes en línea como data URIs en CSS o HTML, blobs binarios incrustados en payloads JSON, adjuntos de correo y los segmentos codificados de los JSON Web Tokens. En cada caso, la alternativa —enviar bytes en bruto— sería corrompida o rechazada por sistemas que asumen texto.

Evita Base64 para archivos grandes, porque la penalización del 33 % de tamaño se paga en cada byte. Codificar una imagen de 10 MB produce aproximadamente 13,3 MB de texto, que luego hay que transferir, analizar y decodificar. Para cualquier cosa de tamaño considerable, envía el archivo en bruto por un transporte seguro para binario, como una subida multipart normal o una URL firmada, y reserva Base64 para recursos pequeños, iconos y metadatos.

Un segundo coste es el de CPU y memoria: codificar y decodificar cadenas grandes no es gratis, e incrustar data URIs grandes impide el almacenamiento en caché del navegador, ya que los bytes se vuelven a descargar con cada página que los incrusta en lugar de guardarse una sola vez como archivo separado.

¿Es seguro codificar archivos de forma privada en el navegador?

Sí, la codificación Base64 en una herramienta web moderna ocurre enteramente de forma local en tu navegador, así que los bytes de tu archivo nunca se suben a ningún servidor. La codificación es pura matemática, `btoa()` y la FileReader API se ejecutan en tu propio dispositivo, lo que significa que una herramienta del lado del cliente puede convertir un documento o imagen a Base64 sin ninguna ida y vuelta por la red.

Esto importa cuando la entrada es sensible, una clave privada, un documento interno, la imagen de un cliente, porque un codificador puramente del lado del cliente te da la comodidad de una interfaz web con la privacidad de una herramienta de línea de comandos sin conexión. Nada sale de la máquina en la que estás trabajando.

Preguntas frecuentes