Codificador y Decodificador Base64

Para qué sirve Base64

Base64 reescribe bytes arbitrarios con 64 caracteres que sobreviven a cualquier canal de texto. Toma tres bytes cada vez, divide esos 24 bits en cuatro grupos de seis y asigna a cada grupo un carácter de A-Z, a-z, 0-9 y dos símbolos. Salen cuatro caracteres por cada tres bytes de entrada, así que el resultado ocupa alrededor de un 33 % más que el original, sin contar saltos de línea.

Su finalidad es el transporte, no el secreto. Base64 se diseñó para canales que estropean los bytes en bruto: sistemas de correo que eliminan el bit más alto, protocolos que interpretan ciertos caracteres de control como órdenes, formatos que tienen que ser texto plano. No es cifrado ni compresión, y cualquier cosa codificada puede leerla sin esfuerzo quien quiera decodificarla. Tratar una cadena Base64 como si estuviera protegida es un malentendido, y este decodificador lo demuestra con facilidad.

El relleno y los dos alfabetos

Cuando la entrada no se divide exactamente en grupos de tres bytes, la salida se rellena con uno o dos caracteres = para que su longitud sea múltiplo de cuatro. Algunos generadores omiten el relleno, y este decodificador lo vuelve a añadir en lugar de rechazar la entrada, ya que la cantidad correcta se deduce de la longitud.

El alfabeto estándar termina en + y /, que tienen significado en una URL y se convierten en %2B y %2F al escaparlos, algo feo y propenso a errores en una query string o un nombre de archivo. Por eso la sección 5 de la RFC 4648 define una variante segura para URL que usa - y _, normalmente sin relleno, ya que = también necesita escaparse. Es la variante que usan los JWT en todos sus segmentos. Al codificar puedes elegir cualquiera de las dos; al decodificar, la herramienta detecta qué alfabeto has pegado sin que tengas que indicarlo.

Unicode y la trampa de btoa

Los navegadores incluyen la función btoa desde hace décadas, y no hace lo que la mayoría supone. Trabaja con Latin-1: cada carácter de la entrada debe tener un punto de código inferior a 256, y cualquier otro lanza InvalidCharacterError. Pásale un solo carácter japonés, un nombre en cirílico o un emoji y falla directamente.

El primer apaño que suele encontrarse es aplicar escape a la cadena antes de codificarla, lo que convierte todo lo que no es ASCII en otra secuencia de bytes que al otro lado se decodifica como basura. La forma correcta, y la que se usa aquí, es convertir primero el texto a bytes UTF-8 con TextEncoder y codificar esos bytes. Por eso cualquier sistema de escritura hace el viaje de ida y vuelta por esta herramienta sin cambios.

La decodificación hace lo contrario y se niega a adivinar. Si los bytes decodificados no son UTF-8 válido, se te indica que son binarios en lugar de mostrarte una cadena llena de caracteres de sustitución. Eso suele significar que el contenido es una imagen, un archivo comprimido, un mensaje protobuf o un texto cifrado, y lo que procede es guardar los bytes, no leerlos como texto.

Cuándo no usarlo

Base64 no sirve para guardar secretos, porque no protege nada. Tampoco es una buena opción por defecto para incrustar recursos grandes: un data URI de una imagen aumenta su tamaño en un tercio, no puede almacenarse en caché por separado del documento que lo contiene y bloquea la página mientras se analiza.

Donde se gana su sitio es en los casos pequeños e incómodos: un certificado en formato PEM, una firma, un campo binario dentro de un cuerpo JSON, un icono corto incrustado, un segmento de un token.

Entran tres bytes, salen cuatro caracteres

La codificación resulta más fácil de creer cuando la haces a mano una vez. Toma las tres letras ASCII de Man: sus valores de byte son 77, 97 y 110, que en binario son 01001101, 01100001 y 01101110. Escribe esos 24 bits seguidos y córtalos en cuatro grupos de seis en lugar de tres grupos de ocho: 010011, 010110, 000101, 101110. Lee cada grupo como un número - 19, 22, 5, 46 - y búscalo en el alfabeto A-Z, a-z, 0-9, + y /, donde el índice 0 es A y el 26 es a. El resultado es TWFu.

Todas las propiedades de Base64 salen de esa aritmética. Seis bits por carácter es la razón de que el alfabeto tenga exactamente 64 entradas. Cuatro caracteres por cada tres bytes es la razón de que la salida sea un tercio más grande. Y el relleno existe porque el último grupo puede quedarse corto: un byte sobrante produce dos caracteres más ==, y dos bytes sobrantes producen tres caracteres más =.

Decodificar es la misma operación al revés, y por eso cualquier cadena Base64 cuya longitud no sea múltiplo de cuatro está rellenada, truncada, o la produjo un codificador que quitó el relleno a propósito.

Dónde te lo encuentras en sistemas reales

Los archivos PEM - certificados, CSR, claves privadas - son Base64 con una línea de cabecera y otra de cierre y un salto de línea cada 64 caracteres. Esa longitud de línea es una convención de MIME y no algo que Base64 requiera, y se espera que los decodificadores ignoren los saltos.

La autenticación HTTP Basic envía usuario:contraseña codificado en Base64 en la cabecera Authorization, que es exactamente por qué Basic auth sobre HTTP sin cifrar equivale a mandar la contraseña en claro. Los adjuntos de correo usan Base64 desde que se definió MIME en 1992, por el motivo original: no se podía confiar bytes arbitrarios a los servidores de correo de la época.

Los data URI incrustan un archivo entero en un documento - data:image/png;base64, seguido del contenido - y las API JSON usan Base64 siempre que un campo debe transportar bytes, ya que JSON no tiene tipo binario. Los segmentos de un JWT usan la variante segura para URL sin relleno, y la configuración de Docker, los secretos de Kubernetes y muchos sistemas de CI almacenan credenciales codificadas en Base64, lo cual es almacenamiento, no protección.

Tamaño, memoria y archivos grandes

La expansión del 33 % es el coste más visible y normalmente el menor. El texto Base64 se comprime peor que los bytes de los que salió, porque la codificación destruye los patrones a nivel de byte que un compresor aprovecharía, así que un payload Base64 comprimido con gzip suele ser mayor que el original comprimido.

En un navegador la memoria es la restricción más dura. Codificar un archivo implica mantener a la vez los bytes y la cadena resultante, y la cadena es un tercio mayor, así que un archivo de 100 MB puede necesitar varios cientos de megabytes antes de enviar nada. Las API de streaming - leer el archivo por trozos y codificar cada uno - lo evitan, siempre que cada trozo sea múltiplo de tres bytes para que el relleno solo aparezca al final.

Para cualquier cosa grande, la mejor respuesta suele ser no codificar: envía el archivo como multipart form data o como cuerpo en bruto, y reserva Base64 para los valores pequeños e incómodos que tienen que viajar dentro de un formato de texto.

Los alfabetos emparentados y por qué existen

Base32 usa 32 caracteres y produce una salida un 60 % mayor que la entrada, lo que parece mal negocio hasta que necesitas algo que una persona pueda leer en voz alta o teclear. No distingue mayúsculas de minúsculas, evita los caracteres que se confunden con facilidad, y es lo que usan los secretos TOTP y las direcciones onion.

Base58 descarta 0, O, I, l y los dos símbolos para que una cadena pueda copiarse a ojo sin ambigüedad; las direcciones de Bitcoin son el uso más conocido. Base85, o Ascii85, mete cuatro bytes en cinco caracteres y es más denso que Base64, a costa de usar signos de puntuación que muchos formatos tendrían que escapar, y por eso sobrevive sobre todo dentro de PDF y PostScript.

El patrón es constante: todos ellos intercambian densidad por las restricciones del canal. Base64 está donde está porque es lo bastante denso como para merecer la molestia y seguro en el mayor número de canales de texto.

Investigar un payload que te han pasado

Una primera pregunta útil ante cualquier cadena opaca es si de verdad es Base64. Hay tres señales fiables: la longitud es múltiplo de cuatro o termina en uno o dos signos igual, el alfabeto se limita a letras, dígitos y dos símbolos, y al decodificar aparece texto legible o una cabecera de archivo reconocible en lugar de ruido.

Merece la pena reconocer esas cabeceras también en su forma codificada, porque identifican el contenido antes de guardarlo. Un payload decodificado que empieza por los bytes 89 50 4E 47 es un PNG; FF D8 FF es un JPEG; 50 4B 03 04 es un zip, lo que incluye cualquier documento de Office; 25 50 44 46 es un PDF. En forma Base64, una cadena que empieza por iVBORw0KGgo es un PNG y /9j/ es un JPEG, y las dos aparecen constantemente en payloads de API y data URI.

Cuando la decodificación no da ni texto ni una cabecera conocida, las explicaciones habituales son que la cadena es Base64 seguro para URL y se está decodificando con el alfabeto estándar, que está codificada dos veces, o que no es Base64 sino hexadecimal o base32. Cada caso se distingue en un segundo: las cadenas seguras para URL contienen guion o guion bajo, las doblemente codificadas decodifican a otra cadena con aspecto de Base64, y el hexadecimal solo usa dieciséis caracteres.