Base64 explicado: por qué, cuándo y las variantes comunes

Base64 está en todas partes — adjuntos de correo, tokens JWT, URIs de datos, bloques PEM de certificados, secretos de cliente OAuth, payloads de notificaciones push — y casi nadie se detiene a preguntar qué hace realmente. Tiene un trabajo específico, tres variantes casi idénticas y las diferencias entre ellas causan la mayoría de los errores.

El problema que resuelve Base64

Muchos canales de transporte están diseñados para texto, no para bytes arbitrarios. Los cuerpos de correo electrónico históricamente debían ser ASCII imprimible. Las URLs no pueden contener caracteres de control sin procesar ni espacios. Las cadenas JSON deben ser Unicode válido. Si quieres enviar un PNG dentro de cualquiera de estos, los bytes brutos romperán el canal.

Base64 toma cualquier secuencia de bytes y la reexpresa usando solo 64 caracteres seguros más relleno opcional. El resultado cabe en cualquier lugar donde cabe el texto, y un decodificador recupera los bytes originales exactamente. No hay pérdida, no hay compresión y no hay seguridad — solo un cambio de formato.

El alfabeto

Base64 estándar (RFC 4648 §4) usa 65 caracteres en total:

• A–Z — valores 0–25
• a–z — valores 26–51
• 0–9 — valores 52–61
• + — valor 62
• / — valor 63
• = — relleno, sin valor

Por qué la salida es un 33% más grande

4 caracteres de salida portan solo lo que portaban 3 bytes de entrada, por lo que la inflación es exactamente 4/3 = 1,333…, o 33,3% adicional. Un archivo binario de 1 MB se convierte en una cadena Base64 de 1,33 MB. Este es el precio del transporte seguro para texto; si no puedes permitírtelo, no puedes usar Base64.

Prueba nuestro codificador / decodificador Base64 con una entrada de muestra — verás la relación de tamaño reportada junto con el resultado.

Las tres variantes que encontrarás

Base64 estándar (RFC 4648 §4)

El original. El alfabeto incluye + y /, relleno con = requerido. Usado por archivos PEM (certificados TLS, claves SSH), XML Signature, adjuntos SOAP y el encabezado HTTP Authorization: Basic.

Base64url (RFC 4648 §5)

Seguro para URLs y nombres de archivo. Reemplaza + por - y / por _. El relleno es técnicamente opcional en la especificación pero casi siempre se omite en la práctica. Esto es lo que usan JWT, JWS, JWE, OAuth PKCE, WebPush VAPID y WebAuthn.

Base64 estándar y Base64url no son directamente intercambiables. Consulta nuestra comparativa Base64 vs Base64url para las reglas exactas.

MIME Base64 (RFC 2045)

La variante original de adjuntos de correo. Mismo alfabeto que Base64 estándar, pero con un salto de línea duro (\r\n) insertado cada 76 caracteres porque los relés SMTP antiguos se atascaban con líneas largas. Si generas Base64 para un campo JSON o un JWT, nunca insertes saltos de línea.

Errores comunes

Codificar cadenas sin especificar UTF-8

Base64 no conoce los caracteres — codifica bytes. Si codificas en Base64 la cadena “café”, el resultado depende completamente de qué codificación de bytes elegiste (UTF-8 da 5 bytes produciendo Y2Fmw6k=; Latin-1 da 4 bytes produciendo Y2Fm6Q==). La convención moderna es bytes UTF-8 para cualquier entrada de texto.

Mezclar estándar y URL-seguro

Una cadena que contiene - o _ es base64url; los decodificadores de Base64 estándar la rechazan. Una cadena que contiene + o / es estándar; los decodificadores URL-seguros la rechazan. Si controlas ambos extremos, elige uno y documéntalo.

Discrepancia de relleno

Los JWT y formatos similares eliminan el relleno. Los decodificadores ingenuos requieren relleno y lanzan InvalidBase64. La corrección es volver a añadir caracteres = hasta que la longitud de entrada sea múltiplo de 4.

Tratar Base64 como un límite de seguridad

Los Secrets de Kubernetes son Base64, no cifrados. Poner en Base64 una contraseña en código cliente no la protege. Base64 no oculta nada a nadie con un decodificador — y todos los ordenadores tienen uno.

Prueba el codificador

Pega cualquier texto o sube un archivo en nuestro codificador / decodificador Base64. Admite tanto los alfabetos estándar como los URL-seguros, muestra el comportamiento del relleno explícitamente e informa los tamaños de bytes de entrada/salida para que puedas ver la inflación para tu entrada específica. La entrada del glosario Base64 es la versión de un párrafo.

Conclusión

Base64 es una comodidad de transporte, no una característica de seguridad. Te cuesta un tercio de tus bytes y te paga de vuelta en compatibilidad con canales solo de texto. Las variantes importan — estándar para PEM y HTTP Basic, URL-seguro para JWT y OAuth, MIME para correo — y no se decodifican mutuamente sin transcodificación. Sé siempre explícito sobre qué variante produces y consumes, y siempre codifica las cadenas Unicode a bytes UTF-8 primero.