Guía
Base64 vs Base64URL: diferencias de alfabeto y padding
Aprende cuándo usar + y / o - y _, cómo tratar el padding y por qué los segmentos JWT usan Base64URL.
por Tools in a Tab · Publicado el · Revisado el
Respuesta breve
Base64 y Base64URL representan los mismos bytes en grupos de seis bits, pero usan dos alfabetos ligeramente distintos para adaptarse al canal.
| Valor | Base64 estándar | Base64URL |
|---|---|---|
| Índice 62 | + |
- |
| Índice 63 | / |
_ |
| Padding | = canónico |
Puede omitirse si el protocolo lo define |
Los caracteres + y / tienen significados especiales en algunos contextos
de URL. La variante URL-safe los sustituye; no es una forma de cifrado ni un
algoritmo de compresión.
No cambies solo dos caracteres a ciegas
Para convertir correctamente también debes tratar el padding y validar la
longitud. El receptor necesita saber cuántos bytes representaba el último
grupo. Algunos protocolos omiten = porque pueden reconstruirlo; otros exigen
la forma Base64 estándar con padding.
La RFC 4648 define el alfabeto Base64URL. Debe seguirse el perfil concreto del protocolo, no una suposición general sobre todas las URLs.
JWT usa Base64URL
Los segmentos compactos de un JWT son valores Base64URL separados por puntos. El decodificador JWT entiende esa variante y advierte que leer el contenido no verifica la firma.
El conversor Base64 permite elegir explícitamente Base64 estándar o Base64URL y decidir si la salida URL-safe conserva el padding. La selección evita aceptar silenciosamente una entrada bajo reglas distintas.
Elección rápida
- MIME o un campo que exige Base64 RFC 4648: alfabeto estándar.
- JWT, JWS u otro protocolo que especifica Base64URL: variante URL-safe.
- Parámetro de una aplicación propia: define alfabeto, padding y tratamiento de bytes en el contrato.
No intentes decodificar bytes arbitrarios como texto: Base64 puede representar cualquier secuencia, pero el resultado solo es texto si esos bytes forman una codificación válida, como UTF-8.