La codificación Base64 explicada: cómo funciona, dónde se usa y mitos comunes

Por qué existe Base64

Todos los datos de un ordenador son, en última instancia, bytes. Sin embargo, muchos canales solo transportan texto de forma segura: cuerpos de correo, cabeceras HTTP, documentos JSON y URL. Si se envían por ellos bytes de imagen en bruto o texto cifrado, los caracteres de control y los saltos de línea pueden corromper los datos, o un sistema intermedio puede reescribirlos.

Base64 resuelve el problema traduciendo cualquier secuencia de bytes a un alfabeto de 64 caracteres formado por letras mayúsculas y minúsculas, dígitos, más + y /. Esos caracteres se consideran seguros casi en todas partes, por lo que los datos binarios pueden viajar intactos por canales de solo texto. El formato está estandarizado en la RFC 4648.

Tres bytes se convierten en cuatro caracteres

La idea central es sencilla. La entrada se toma de tres en tres bytes (24 bits) y esos 24 bits se dividen en cuatro grupos de seis bits. Con seis bits se representan 64 valores, de 0 a 63, así que cada grupo corresponde a un carácter: 0–25 son A–Z, 26–51 son a–z, 52–61 son 0–9, 62 es + y 63 es /.

Tomemos la palabra Man. Sus bytes son 77, 97 y 110. Al dividir esos 24 bits en grupos de seis se obtienen 19, 22, 5 y 46, que corresponden a TWFu. El texto en otros idiomas funciona igual una vez convertido en bytes: el carácter coreano 한 ocupa tres bytes en UTF-8 (ED 95 9C) y, por tanto, se convierte exactamente en cuatro caracteres, 7ZWc.

Man   → TWFu
Hi    → SGk=
한    → 7ZWc
안녕  → 7JWI64WV

Como tres bytes siempre se convierten en cuatro caracteres, la salida Base64 es aproximadamente un 33 % más grande que la entrada. Un archivo de 1.000 bytes se convierte en 1.336 caracteres. Por eso incrustar imágenes grandes como data URI hace que una página pese notablemente más.

Qué significa el = final

Cuando la longitud de la entrada no es múltiplo de tres, el último grupo tiene solo uno o dos bytes. Los bits que faltan se rellenan con ceros y se añaden uno o dos caracteres = para que la longitud de salida siga siendo múltiplo de cuatro. Un byte sobrante produce ==, dos bytes sobrantes producen un solo =. Por eso Hi (dos bytes) se convierte en SGk=.

El relleno es solo una pista que ayuda al decodificador a recuperar la longitud exacta; no contiene datos. Algunos sistemas lo omiten, y los decodificadores estrictos pueden rechazar la cadena con un error de longitud no válida. Añadir caracteres = hasta que la longitud sea múltiplo de cuatro suele solucionarlo.

Base64URL para enlaces y nombres de archivo

Los caracteres + y / tienen significados especiales en las URL: + puede interpretarse como un espacio y / separa los segmentos de la ruta. Por eso la variante Base64URL sustituye + por - y / por _. Los mismos dos bytes FB FF se codifican como +/8= en Base64 estándar y como -_8= en Base64URL.

Las tres partes de un JSON Web Token están codificadas en Base64URL, normalmente sin relleno. Decodificar la parte central de un JWT muestra en texto plano datos como el ID de usuario y la fecha de caducidad, lo que nos lleva directamente al punto más importante sobre Base64.

El gran mito: Base64 no es cifrado

La salida de Base64 parece aleatoria, por eso a menudo se confunde con cifrado. Pero no hay clave: cualquiera puede revertirla al instante con las mismas reglas públicas. Guardar o enviar contraseñas o claves de API en Base64 no ofrece más protección que el texto plano.

La autenticación HTTP Basic es un buen ejemplo. El nombre de usuario y la contraseña se unen con dos puntos y se codifican en Base64, pero eso es solo un formato de transporte; la protección real la aporta HTTPS. Si necesitas ocultar datos, usa cifrado como AES. Si necesitas detectar manipulaciones, usa un hash o una firma.

Dónde encontrarás Base64 en la práctica

Saber dónde se usa Base64 te ayuda a identificar rápidamente cadenas desconocidas.

• Adjuntos de correo: MIME codifica los adjuntos binarios en Base64 dentro del cuerpo del mensaje.
• Data URI: los iconos pequeños pueden incrustarse como data:image/png;base64,... en CSS o HTML. Limítalo a imágenes de pocos kilobytes.
• JWT y OAuth: las cabeceras y cargas útiles de los tokens usan Base64URL.
• Cuerpos de API: JSON no puede contener bytes en bruto, así que los archivos y las firmas se envían como cadenas Base64.
• Certificados y claves: el cuerpo de un archivo PEM que empieza por -----BEGIN CERTIFICATE----- es Base64.

Qué revisar cuando una cadena no se decodifica

La mayoría de los errores de decodificación tienen pocas causas. Primero, busca saltos de línea o espacios; los correos y los archivos PEM suelen cortar la línea cada 76 caracteres. Segundo, si ves - o _, la cadena es Base64URL y debe decodificarse como tal. Tercero, si la longitud no es múltiplo de cuatro, falta el relleno.

Si la decodificación funciona pero el texto aparece con caracteres extraños, el problema es la codificación de caracteres original. Las letras con tilde o la ñ, por ejemplo, producen bytes distintos en UTF-8 y en ISO-8859-1, así que debes interpretar el resultado con el mismo juego de caracteres que se usó al codificar. La herramienta Base64 de AIBIZAP usa UTF-8, por lo que los acentos, el japonés, el coreano y los emoji se convierten correctamente en ambos sentidos.