La diferencia entre base64url y base64 se reduce a tres pequeños cambios: base64 estándar usa + y / en su alfabeto más el relleno =, mientras que base64url cambia + por -, cambia / por _ y normalmente elimina el relleno = por completo. Esa es toda la diferencia a nivel de especificación. Todo lo demás, la matemática de codificación, la agrupación de 6 bits, la sobrecarga de tamaño del 33%, es idéntico entre ambos.
¿Por qué importa? Porque +, / y = tienen significados reservados dentro de URLs, cadenas de consulta y nombres de archivo. Si pones una cadena base64 estándar en una URL, + puede interpretarse como un espacio, / inicia un nuevo segmento de ruta y = parece una asignación de parámetro. Base64url existe para que los datos codificados sobrevivan a esos contextos sin cambios. Esta guía cubre exactamente cuándo se requiere cada variante, el detalle del relleno que la mayoría de los artículos omiten y por qué los JSON Web Tokens usan base64url para su cabecera y carga útil.
Base64url vs Base64: La diferencia clave#
Ambas variantes están definidas en RFC 4648. El base64 estándar se encuentra en la Sección 4; el alfabeto seguro para URL y nombres de archivo está en la Sección 5. Codifican los bytes de la misma manera: toman tres bytes (24 bits), los dividen en cuatro grupos de 6 bits y mapean cada grupo a un carácter de un alfabeto de 64 caracteres. Lo único que cambia es qué caracteres ocupan las dos últimas posiciones de ese alfabeto y si se agrega relleno al final.
Aquí está la comparación que realmente importa:
| Aspecto | Base64 estándar | Base64url |
|---|---|---|
| Carácter del índice 62 | + (más) | - (guión/raya) |
| Carácter del índice 63 | / (barra) | _ (guión bajo) |
| Relleno | = hasta múltiplo de 4 | Generalmente omitido |
| Seguro en URL / cadenas de consulta | No | Sí |
| Seguro en nombres de archivo | No (la / rompe rutas) | Sí |
| Sección RFC 4648 | Sección 4 | Sección 5 |
| Longitud de salida | Idéntica | Idéntica |
Observa que los primeros 62 caracteres (A-Z, a-z, 0-9) son iguales en ambos alfabetos. Solo las posiciones 62 y 63 difieren. Por eso convertir entre ambos es una simple sustitución de caracteres y nunca requiere recodificar los bytes originales.
Consejo rápido: si ves una cadena con apariencia base64 que contiene
-o_, casi seguro que estás viendo base64url. El base64 simple nunca usa esos dos caracteres.
Por qué + y / rompen dentro de las URL#
Una URL tiene una gramática y varios caracteres tienen un significado estructural. La barra / separa segmentos de ruta. El signo más + se interpreta históricamente como un espacio codificado en datos application/x-www-form-urlencoded (el formato usado por cadenas de consulta y formularios). El signo igual = separa el nombre de un parámetro de consulta de su valor.
Por lo tanto, si colocas un token base64 estándar como a+b/c= directamente en una URL, un servidor podría decodificar el + como un espacio, tratar /c como una nueva ruta y leer = como el inicio de un valor. Tus datos se corrompen antes de que tu código los toque. Base64url evita todo el problema al no emitir nunca ninguno de esos tres caracteres.
Cuándo Debes Usar Cada Variante#
La regla de decisión es breve. Usa base64url en cualquier lugar donde la salida viaje a través de una URL, un parámetro de consulta, un encabezado HTTP, un nombre de archivo o una cookie. Usa base64 estándar para todo lo demás: archivos adjuntos de correo electrónico (MIME), URIs de datos, archivos de configuración, valores de cadena JSON que no están vinculados a URL y blobs binarios almacenados en una base de datos.
Usa base64url cuando el valor codificado aparecerá en:
- Una ruta de URL o cadena de consulta (por ejemplo
?token=...) - Un JWT (encabezado, payload y firma son todos base64url)
- Un parámetro de OAuth u OpenID Connect como
stateocode_challenge - Un nombre de archivo o clave de objeto S3 (la
/en base64 estándar crearía carpetas no deseadas) - Claves WebPush, credenciales FIDO/WebAuthn y muchos otros contextos de criptografía web
Usa base64 estándar cuando el valor reside en:
- Un archivo adjunto de correo electrónico codificado como MIME
- Una URI
data:incrustada en HTML o CSS (estas toleran+y/sin problemas) - Un valor de configuración JSON o YAML que nunca se coloca en una URL
- Una columna de base de datos o línea de registro
Si no estás seguro de cuál tienes, pégala en el codificador y decodificador base64 gratuito y decodifícala de ambas formas. Si solo una variante produce una salida limpia y legible, eso te indica qué alfabeto la generó.
El truco del relleno que la mayoría de guías omiten#
Esta es la parte que confunde a la gente y la razón por la que un fragmento copiado a veces da error. El base64 estándar rellena la salida con = para que la longitud total sea siempre múltiplo de 4. Base64url normalmente elimina ese relleno porque = no es seguro en URLs.
Las matemáticas: base64 codifica 3 bytes en 4 caracteres. Cuando la entrada no es múltiplo de 3 bytes, el codificador llena el espacio con =. Un byte sobrante produce dos caracteres de relleno (==), dos bytes sobrantes producen uno (=).
Aquí está la trampa. Muchos decodificadores estrictos exigen una longitud múltiplo de 4. Cuando base64url elimina el relleno, la cadena ya no es múltiplo de 4, por lo que un decodificador ingenuo falla. La solución es volver a rellenar antes de decodificar.
Cómo rellenar base64url antes de decodificar#
Para decodificar de forma segura una cadena base64url con un decodificador base64 genérico, haz dos cosas: convierte el alfabeto de nuevo (- a +, _ a /), luego añade = hasta que la longitud sea múltiplo de 4.
En JavaScript:
function base64urlDecode(input) {
// 1. Restaurar el alfabeto estándar
let b64 = input.replace(/-/g, '+').replace(/_/g, '/');
// 2. Rellenar hasta múltiplo de 4
const pad = b64.length % 4;
if (pad === 2) b64 += '==';
else if (pad === 3) b64 += '=';
else if (pad === 1) throw new Error('Longitud base64url inválida');
return atob(b64);
}
Un resto de longitud 1 es imposible en base64 válido, así que trátalo como entrada mal formada en lugar de adivinar. Si omites el paso de relleno, atob y la mayoría de decodificadores del lado del servidor rechazarán la cadena o devolverán basura. Nuestro codificador base64 maneja el relleno automáticamente, así que puedes insertar un token base64url sin relleno y lo decodifica sin que hagas las cuentas.
Por qué los JWT usan Base64url (no Base64)#
Un JSON Web Token son tres segmentos en base64url unidos por puntos: header.payload.signature. La razón por la que se usa base64url y no base64 estándar es exactamente el problema anterior. Los tokens se pasan en URLs, en cabeceras Authorization: Bearer y en parámetros de consulta durante flujos OAuth. Un token base64 estándar con un / o + se rompería al llegar a una URL.
Por eso, la especificación JWT (RFC 7519, basada en RFC 7515) exige base64url sin relleno. Así, un JWT nunca contiene =, + ni /, solo letras, dígitos, guiones, guiones bajos y los dos puntos separadores.
Advertencia: base64url es codificación, no cifrado. Cualquiera puede decodificar el payload de un JWT y leer sus claims. Nunca pongas secretos en el cuerpo de un JWT. La firma demuestra que el token no ha sido alterado, pero no oculta su contenido.
Si quieres inspeccionar un token, puedes separar los tres segmentos y decodificar en base64url la cabecera y el payload con la herramienta decodificadora JWT. Ella realiza la conversión del alfabeto y el relleno por ti, para que veas los claims JSON en crudo al instante. Para entender qué demuestra el segmento de la firma frente a lo que muestra la decodificación, merece la pena leer el desglose en decodificar vs verificar un JWT antes de confiar en cualquier token en producción.
Conversión entre las dos variantes#
Dado que solo dos caracteres y el relleno difieren, la conversión es pura manipulación de cadenas. Nunca se vuelve a ejecutar el algoritmo base64.
Base64 estándar a base64url:
- Reemplazar cada
+con- - Reemplazar cada
/con_ - Eliminar los caracteres
=finales
Base64url de vuelta a base64 estándar:
- Reemplazar cada
-con+ - Reemplazar cada
_con/ - Agregar relleno
=hasta que la longitud sea múltiplo de 4
Esa simetría es la conclusión práctica: los dos formatos son los mismos datos con ropa diferente. Si falla una decodificación, la causa casi siempre es un desajuste (se introdujo base64url en un decodificador estándar sin convertir) o falta de relleno, no datos corruptos.
Un ejemplo práctico#
Tome los bytes de la cadena Hello?>. Base64 estándar los codifica como SGVsbG8/Pg==. Observe el / en el índice 8 y el relleno ==. Como base64url, los mismos bytes se convierten en SGVsbG8_Pg: el / ahora es _ y el relleno ha desaparecido. Decodifique cualquiera de los dos y obtendrá Hello?> de vuelta. Mismo contenido, dos representaciones seguras para diferentes contextos.
Errores comunes y cómo evitarlos#
Algunos errores aparecen una y otra vez cuando los desarrolladores mezclan las dos variantes:
- Decodificar base64url con un decodificador estándar y obtener un error. Primero convierta
-/_de vuelta y vuelva a rellenar. Este es el error más común. - Asumir que
=siempre está presente. El código que divide o valida según la longitud del relleno falla en cuanto encuentra base64url sin relleno. Haga que el relleno sea opcional en su análisis. - Codificar en URL una cadena base64 estándar en lugar de usar base64url. Esto funciona pero infla la salida:
+se convierte en%2B,/se convierte en%2F. Base64url es más corto y limpio para contextos de URL. - Tratar base64 o base64url como una capa de seguridad. Ambos son reversibles por cualquiera. Úselos para transportar binarios como texto, nunca para proteger datos.
- Olvidar que ambos formatos tienen la misma sobrecarga de tamaño del 33%. Codificar 3 bytes como 4 caracteres significa que su salida es aproximadamente un tercio más grande que la entrada original, en cualquier variante.
Si está manejando binarios codificados como imágenes junto con texto, la guía sobre cómo codificar y decodificar imágenes base64 y URLs de datos cubre el lado de las URI de datos donde el base64 estándar es la opción correcta.
Preguntas Frecuentes#
¿Es base64url lo mismo que base64?
No, pero son similares. Base64url usa el mismo algoritmo de codificación y produce la misma longitud de salida. Las únicas diferencias son que + se convierte en -, / se convierte en _ y el relleno = generalmente se elimina para que la cadena sea segura en URL y nombres de archivo.
¿Por qué base64url elimina el relleno?
El carácter de relleno = tiene un significado reservado en las URL (separa el nombre de un parámetro de consulta de su valor), por lo que dejarlo podría corromper los datos o confundir a un servidor. Base64url lo elimina por seguridad. La desventaja es que los decodificadores estrictos pueden requerir que vuelvas a agregar el relleno antes de decodificar.
¿Puedo decodificar base64url con un decodificador base64 normal?
Sí, pero solo después de dos pasos. Primero, convierte el alfabeto reemplazando - con + y _ con /. Luego, vuelve a rellenar la cadena con = hasta que su longitud sea múltiplo de 4. Si omites cualquiera de estos pasos, la mayoría de los decodificadores estándar mostrarán un error o devolverán datos basura.
¿Por qué los JWT usan base64url en lugar de base64 estándar?
Porque los tokens viajan a través de URL, encabezados HTTP y parámetros OAuth donde +, / y = causarían problemas. La especificación JWT exige base64url sin relleno, por lo que nunca verás esos tres caracteres en un JSON Web Token válido, solo letras, dígitos, guiones, guiones bajos y separadores de punto.
¿Base64url es cifrado o solo codificación? Es solo codificación. Cualquiera puede revertirlo sin clave, exactamente como base64 estándar. Existe para representar datos binarios como texto seguro para URL, no para mantener algo en secreto. Nunca almacenes contraseñas, claves de API u otros datos sensibles como base64url y asumas que están protegidos.
¿Base64url produce una cadena más pequeña que base64?
Ligeramente, solo porque generalmente omite el relleno = (ahorrando de cero a dos caracteres). El cuerpo codificado tiene la misma longitud en ambos. Ambas variantes agregan aproximadamente el mismo 33% de sobrecarga en comparación con el binario sin procesar, ya que cada 3 bytes se convierten en 4 caracteres.
Base64url vs base64 no es un misterio profundo una vez que lo ves como un alfabeto con dos caracteres intercambiados y relleno opcional. Usa base64url siempre que tus datos toquen una URL, encabezado, nombre de archivo o JWT, y base64 estándar para MIME, URI de datos y almacenamiento. Cuando una decodificación falle, sospecha primero de una variante incorrecta o relleno faltante, luego coloca la cadena en el codificador y decodificador base64 para confirmar qué alfabeto tienes.
