Base64 y Base64URL representan bytes con texto, pero no son intercambiables sin reglas claras. La diferencia parece mínima: Base64 estándar usa + y /, mientras Base64URL usa - y _. Además, Base64URL a menudo omite el padding =. Esos detalles importan porque URLs, formularios, rutas, tokens y firmas tratan ciertos caracteres como sintaxis, no como datos.

El alfabeto estándar no encaja bien en todos los lugares

En Base64 clásico, + puede confundirse con espacio en algunos contextos de formularios, / puede parecer separador de ruta y = tiene significado en query strings. Es posible escapar esos caracteres, pero cada escape añade una capa de complejidad. Base64URL evita parte del problema usando caracteres más cómodos para URLs y nombres de archivo.

Esto no significa que Base64URL sea universalmente “mejor”. En correo, PEM o formatos antiguos, el alfabeto estándar puede ser el esperado. La variante correcta es la que el protocolo define y todos los participantes implementan igual.

JWT popularizó Base64URL sin padding

Un JSON Web Token está formado por tres partes separadas por puntos. Cada parte se codifica con Base64URL, normalmente sin padding. Esa elección permite que el token viaje en cabeceras HTTP y URLs con menos escaping. Sin embargo, también crea errores cuando alguien usa una función Base64 estándar para construir o verificar el token.

En un token firmado, cambiar la representación textual cambia los bytes que se firman. Añadir padding, usar otro alfabeto o normalizar la cadena puede invalidar la firma. El consumidor no debe “arreglar” el valor de forma creativa antes de verificarlo si el protocolo exige bytes exactos.

El padding es una convención, no decoración

El padding ayuda a indicar cómo se completó el último bloque. Algunas bibliotecas lo requieren y otras lo infieren. En Base64URL es común omitirlo para producir cadenas más limpias. Si una API no documenta esta elección, clientes distintos pueden generar valores que parecen razonables pero fallan en producción.

La solución es especificar tanto la variante como el padding. Un contrato robusto indica qué acepta en entrada y qué emite en salida. Puede aceptar valores con y sin padding por compatibilidad, pero debería producir una forma canónica para evitar duplicados y problemas de comparación.

URLs tienen más de una zona de riesgo

No es lo mismo colocar un valor en un segmento de ruta que en una query string o en un fragment. Cada lugar tiene reglas de escape y caracteres reservados. Base64URL reduce fricción, pero no elimina la necesidad de construir URLs con APIs correctas. Concatenar cadenas manualmente sigue siendo una fuente de errores.

Si un valor Base64 estándar se coloca en una URL sin escape, puede cambiar durante el viaje por proxies, frameworks o formularios. Si se escapa dos veces, el receptor puede obtener otro texto. Usar Base64URL y un constructor de URLs elimina muchas ambigüedades.

Los nombres de archivo también se benefician

El carácter / tiene significado especial en rutas de sistemas de archivos. Aunque Base64 estándar no fue diseñado para nombres de archivo, muchos equipos intentan usarlo para claves de caché o artefactos. Base64URL evita el separador más obvio, pero aún conviene evaluar longitud, sensibilidad a mayúsculas y políticas del sistema.

Para identificadores persistentes, a veces hexadecimal, UUID o un formato específico resulta más claro. Base64URL es compacto, pero menos cómodo para lectura humana y soporte operativo.

La comparación debe usar una forma canónica

Dos cadenas pueden decodificar a los mismos bytes aunque una tenga padding y otra no. Si se usan como claves de base de datos, cache keys o identificadores visibles, esa flexibilidad puede crear duplicados. La aplicación debe normalizar al guardar o rechazar formas no canónicas según el contrato.

En seguridad, la normalización debe seguir exactamente el protocolo. Para firmas, MACs y tokens, lo que importa puede ser la cadena original, no solo los bytes decodificados. La documentación debe separar “forma textual firmada” de “payload recuperado”.

Las bibliotecas no siempre nombran igual las funciones

Algunos lenguajes ofrecen funciones separadas para Base64URL; otros requieren reemplazar caracteres y ajustar padding; otros aceptan varias variantes silenciosamente. Esa tolerancia facilita integraciones, pero también oculta errores. Las pruebas deben cubrir ejemplos con +, /, -, _ y longitudes no múltiplos de cuatro.

Una buena suite incluye vectors conocidos y round trips entre los lenguajes usados por el sistema. Así se detectan diferencias antes de que un token generado por un servicio falle en otro.

Elegir variante es parte del diseño del protocolo

Base64 estándar funciona bien en documentos y transportes que ya lo esperan. Base64URL funciona mejor en URLs, tokens, rutas y contextos donde los caracteres reservados complican la vida. Lo peligroso no es elegir una u otra, sino dejar la elección implícita.

Un protocolo maduro define alfabeto, padding, encoding de bytes antes de codificar, reglas de comparación y comportamiento ante errores. Con esas piezas claras, Base64URL deja de ser una fuente de sorpresas y se convierte en una herramienta práctica para transportar bytes en lugares orientados a texto.