Qué es la codificación Base64 y cuándo usarla

Si trabajas con APIs, sistemas de email o desarrollo web, te has encontrado con Base64 aunque no lo reconocieras. Esas cadenas largas de letras y números que parecen galimatías al principio de un adjunto de email, en una URL data: en CSS, o en el segmento del medio de un token JWT? Eso es Base64. Es una de las piezas más antiguas y discretamente cargadas de la fontanería de internet, y casi cada pieza de software que usas se apoya en ella en alguna parte.

Breve historia de Base64

Base64 forma parte de una familia llamada «radix-64» o «codificaciones imprimibles», cuyo trabajo es representar bytes arbitrarios usando solo el pequeño alfabeto de caracteres que un sistema basado en texto garantiza pasar sin cambios. El miembro más utilizado primero es uuencode, escrito por Mary Ann Horton en UC Berkeley hacia 1980 para enviar archivos binarios por Usenet y email cuando esos sistemas corrompían cualquier cosa por encima del ASCII de 7 bits.

El alfabeto de Base64 fue estandarizado por primera vez en RFC 989 (1987) para Privacy-Enhanced Mail (PEM), un primer intento de email firmado y cifrado. PEM murió, pero su esquema de codificación sobrevivió y fue canonizado en RFC 1421 (1993) y luego en la especificación MIME (RFC 1521 y 1522 en 1993, revisadas a RFC 2045-2049 en 1996). MIME hizo de Base64 la forma por defecto de adjuntar archivos binarios al email, y desde ahí la codificación se extendió a casi cualquier transporte de solo texto en internet.

En 2006, IETF consolidó las definiciones dispersas de Base64 en RFC 4648, que define Base64, Base32 y Base16 en un solo documento. RFC 4648 también definió la variante URL-safe en la sección 5, que cambió los dos caracteres no aptos para URL (+ y /) por - y _. JSON Web Tokens (RFC 7519, 2015) estandarizó en Base64 URL-safe con el padding eliminado. Hoy, cada adjunto de email, cada certificado codificado en PEM, cada URL data:, cada JWT y cada límite de subida multipart depende de Base64.

Cómo funciona Base64: las matemáticas

Base64 toma tres bytes de entrada (24 bits) y los reescribe como cuatro caracteres de salida (6 bits cada uno), usando un alfabeto de 64 símbolos. El mapeo es fijo:

Así Hello se convierte en:

• Bytes ASCII: 0x48 0x65 0x6C 0x6C 0x6F (5 bytes)
• Binario: 01001000 01100101 01101100 01101100 01101111
• Reagrupado en bloques de 6 bits: 010010 000110 010101 101100 011011 000110 1111
• El último bloque es corto, rellenado con ceros: 010010 000110 010101 101100 011011 000110 111100
• Búsqueda: S G V s b G 8 (solo 7 caracteres para 6 grupos de 6 bits = 36 bits, padding para los 4 que faltan)
• Padding: añadir = para redondear a múltiplo de 4 caracteres de salida: SGVsbG8=

La salida siempre es múltiplo de 4 caracteres. Si la longitud de entrada módulo 3 es 1, obtienes dos caracteres = de padding; si es 2, obtienes uno; si es 0, ningún padding. El padding a veces se elimina (notablemente en JWT y en fragmentos de URL) y se espera que los decodificadores lo toleren.

El overhead del 33 % viene de esta expansión 3-a-4: cada 3 bytes de entrada se vuelven 4 caracteres de salida, un aumento de un tercio. No hay forma de reducirlo sin cambiar el alfabeto (Base85 / Ascii85 expande solo un 25 % usando 85 caracteres imprimibles, a costa de un codificador más complejo).

Casos de uso comunes

Adjuntos de email. SMTP, el protocolo que mueve el 95 % del email entre servidores, se diseñó en 1982 (RFC 821) para ASCII de 7 bits. Cada adjunto binario que envías (una imagen, un PDF, un ZIP) lo codifica en Base64 tu cliente de correo antes de transmitirlo y lo decodifica el del destinatario. Las cabeceras MIME en el email le dicen al destinatario qué partes son Base64 y cuáles son texto plano.

URLs data en HTML y CSS. Una URL data:image/png;base64,iVBORw0KGgo... embebe un archivo binario directamente en el documento. Útil para iconos pequeños bajo 1-2 KB, donde la petición HTTP ahorrada pesa más que el overhead del 33 % y la pérdida de caché.

Cargas útiles de API. Cuando una API JSON o XML necesita aceptar un valor binario (un archivo subido, una firma, una foto de perfil), el patrón estándar es codificar los bytes en Base64 y enviarlos como campo de cadena. El receptor los decodifica en el lado servidor. Así funciona la entrada de imagen de OpenAI, así Stripe recibe subidas de archivos y así la mayoría de funciones cloud aceptan entrada binaria.

HTTP Basic Authentication. La cabecera Authorization: Basic <token> lleva un par username:password codificado en Base64 (RFC 7617). Es codificación, no cifrado: cualquiera que vea la cabecera ve la contraseña. Basic Auth requiere HTTPS por esa razón.

Certificados y claves. Los archivos PEM (-----BEGIN CERTIFICATE----- ... -----END CERTIFICATE-----) envuelven un blob de bytes ASN.1 codificados en DER, codificados en Base64. Cada certificado TLS, cada archivo de clave SSH, cada certificado de firma de código es Base64 dentro de un sobre PEM.

Tokens JWT. Un JWT son tres segmentos Base64 URL-safe separados por puntos: <header>.<payload>.<signature>. La codificación Base64 permite que un JWT viaje seguro en cabeceras, URLs y cookies.

Cómo codificar y decodificar

1. Elige codificar o decodificar: selecciona la dirección de conversión.
2. Pega texto o sube un archivo: introduce texto directamente o arrastra y suelta un archivo (hasta 5 MB para codificación en navegador).
3. Elige la variante: Base64 estándar para email y certificados, URL-safe para JWT y fragmentos de URL. La herramienta usa estándar por defecto.
4. Copia el resultado: la salida se actualiza al instante. Cópiala al portapapeles, o usa el botón de descarga para salidas largas.

Variantes de Base64

Existen varias codificaciones tipo Base64 para situaciones específicas:

La mayoría de las veces quieres Base64 estándar o URL-safe. Las demás aparecen en protocolos específicos.

Cuándo usar Base64

Úsalo cuando:

• Necesitas embeber una imagen pequeña (bajo 5 KB) directamente en HTML o CSS, ahorrando una petición HTTP.
• Una API requiere datos binarios como cadena de texto en una carga JSON o XML.
• Estás pasando datos binarios por un sistema que solo soporta texto (email, entradas de log, parámetros de query).
• Estás codificando un JWT, certificado, clave o cualquier blob binario estructurado.
• Necesitas una representación de cadena determinista y autocontenida que cualquier lenguaje pueda decodificar.

No lo uses cuando:

• El archivo es grande. Base64 añade 33 % de overhead, impide al navegador cachear el binario como recurso separado, y fuerza al blob entero a pasar por el parser de la página.
• Necesitas seguridad. Base64 no es cifrado; es trivialmente reversible.
• Puedes servir el archivo normalmente. Un <img src="photo.jpg"> normal es más eficiente que una URL data Base64 para cualquier cosa por encima de unos pocos KB.
• Necesitas una representación compacta. Hex es más simple si el tamaño no importa; Base85 es más denso si importa.

Errores comunes

• Confundir codificación con cifrado. Base64 es reversible por cualquiera en milisegundos. Pasar un «secreto» por Base64 no lo protege de nada salvo de un vistazo por encima del hombro.
• La penalización de tamaño del 33 %. Una imagen de 1 MB se vuelve una cadena de 1,33 MB, y las URLs data en línea se descargan con el HTML padre en cada visita, sin caché separada.
• Saltos de línea en MIME Base64. La variante MIME inserta \r\n cada 76 caracteres. Si pegas MIME Base64 en un valor JSON o una URL fallará; quita primero los saltos de línea.
• Padding eliminado en JWT. JWT usa Base64 URL-safe con el padding = eliminado. Una biblioteca que exige estrictamente padding rechazará JWTs válidos; una que no lo produce creará tokens que otras bibliotecas rechazan. RFC 7515 manda «sin padding» para el estándar JWS.
• Confusión URL-safe vs estándar. Decodificar una cadena URL-safe con un decodificador estándar falla en los caracteres - y _; decodificar una cadena estándar con un decodificador URL-safe falla en + y /.
• Manejo de entrada Unicode. Base64 opera sobre bytes, no caracteres. Si codificas en Base64 una cadena de emojis UTF-8, primero debes decidir una codificación de bytes (casi siempre UTF-8). Distintos runtimes tienen distintos valores por defecto; especifícalo explícitamente.
• Decodificadores de streaming parciales. Un decodificador Base64 en flujo correctamente implementado espera grupos de 4 caracteres de entrada antes de emitir 3 bytes de salida. Implementaciones ingenuas que decodifican un carácter a la vez producen basura.
• Espacios en blanco y BOM al final. Algunos editores añaden un salto de línea o un BOM UTF-8 al guardar. Ese byte extra cambia la salida Base64. Compara tu resultado codificado contra una fuente aguas arriba si ves mismatches inesperados.
• + interpretado como espacio en URLs. El + de Base64 estándar se vuelve ` ` (espacio) cuando un parser de URL lo decodifica en porcentaje. Por eso existe Base64 URL-safe exactamente.

Alternativas y codificaciones vecinas

Base64 es el valor por defecto, no la única opción. La elección correcta depende del canal y del presupuesto de tamaño.

Para la mayoría del trabajo diario, la respuesta es Base64 (estándar o URL-safe). Para subidas binarias sobre HTTP, la respuesta correcta es normalmente multipart/form-data, que no codifica nada.

Privacidad y el codificador

El codificador y decodificador Base64 corre enteramente en tu navegador. El texto o archivo que introduces lo procesa JavaScript en tu dispositivo, el resultado se renderiza en la página y no se envía nada a un servidor. No se registra nada, no se guarda nada después de salir de la página, y ningún tag de analytics ve el contenido. Para cosas que podrías codificar en Base64 (certificados PEM, claves privadas, cargas útiles JWT de sistemas de producción, borradores de peticiones API con datos reales de cliente), ese flujo estrictamente local es el valor por defecto correcto. La herramienta entera puede correr offline una vez cargada la página, lo que puedes verificar desconectando la red y recodificando la misma entrada.