Qué cambia Base64url
Base64url, definido en RFC 4648 sección 5, mantiene los grupos de seis bits de Base64 y sustituye + por - y / por _. Así evita significados especiales en URL y nombres de archivo.
El relleno es independiente del alfabeto. Algunos protocolos lo conservan y otros, como muchos segmentos JWT, lo omiten. La herramienta produce y acepta ambas formas válidas.
El texto Unicode se convierte en UTF-8. Datos binarios como firmas o claves pueden no ser texto y deberían manejarse como bytes.
Cómo usar Base64url
- Selecciona Codificar para texto o Decodificar para una cadena URL-safe.
- Ajusta el relleno según el protocolo receptor.
- Pega una cadena continua formada por letras, dígitos, - y _.
- Si aparece + o /, probablemente es Base64 estándar.
- Después de decodificar, valida por separado firmas y estructura del protocolo.
Ejemplos y diferencias de Base64url
Los casos muestran relleno opcional y bytes que producen los dos caracteres diferentes del alfabeto estándar.
| Entrada | Salida | Dirección de conversión | Notas |
|---|---|---|---|
Hello |
SGVsbG8= |
Codificar | Incluir relleno: Con relleno — Hello con relleno. Este texto no utiliza los dos símbolos diferentes. |
Hello |
SGVsbG8 |
Codificar | Incluir relleno: Sin relleno — Hello sin relleno. Muchos protocolos omiten = cuando conocen la longitud. |
SGVsbG8 |
Hello |
Decodificar | Decodificar ambos estilos. El decodificador restaura el relleno interno necesario. |
࠾ |
4KC- |
Codificar | Incluir relleno: Con relleno — Carácter del alfabeto seguro para URL. Este carácter UTF-8 válido produce un - final en Base64url, donde Base64 normal usa +. |
你好 |
5L2g5aW9 |
Codificar | Incluir relleno: Sin relleno — Unicode en UTF-8. El texto se convierte primero en bytes UTF-8. |
{"ok":true} |
eyJvayI6dHJ1ZX0 |
Codificar | Incluir relleno: Sin relleno — JSON compacto. Codificar no firma, valida ni cifra JSON. |
Alfabeto y longitudes válidas
El relleno solo puede aparecer al final y el espacio se rechaza.
Sin relleno, la longitud módulo cuatro puede ser 0, 2 o 3; nunca 1.
-
- sustituye a +.
- _ sustituye a /.
- El relleno es opcional pero debe ser correcto.
-
- y / se rechazan.
- Los bits finales no usados deben ser cero.
Cómo convierte los bytes
Tres bytes se dividen en cuatro valores de seis bits. Solo cambian los símbolos de los índices 62 y 63.
La salida sin relleno elimina únicamente los = finales. El decodificador calcula el relleno implícito y reconstruye bytes.
Una decodificación UTF-8 estricta evita ocultar bytes dañados con caracteres de reemplazo.
Usos habituales de Base64url
Se usa cuando datos binarios o estructurados deben caber en un campo textual seguro para URL.
| Caso | Descripción |
|---|---|
| Segmentos JWT | Cabecera, carga y firma suelen usar Base64url sin relleno. |
| OAuth y OIDC | Varios parámetros usan Base64url bajo reglas específicas. |
| Identificadores de URL | Evita +, / y codificación porcentual adicional. |
| Criptografía web | Serializa hashes, claves y firmas, sin sustituir su validación. |
| Pruebas de API | Detecta errores de relleno y alfabeto entre plataformas. |
Errores y límites de protocolo
Mezclar Base64 normal y Base64url es el fallo más común. Incluso con el alfabeto correcto hay que conocer la política de relleno.
Decodificar un JWT no verifica su firma, emisor, audiencia ni caducidad.
- Resto de longitud 1 es imposible.
- Relleno intermedio es inválido.
-
- y / no se corrigen silenciosamente.
- Los bytes pueden no ser UTF-8.
- Base64url no es cifrado.
Base64url, Base64 y codificación URL
Base64 y Base64url difieren en dos símbolos. La codificación porcentual escapa caracteres de componentes URL y resuelve otro problema.
Hexadecimal es más fácil de leer pero duplica la longitud; Base58 usa otro modelo y otro alfabeto.
| Caso | Descripción |
|---|---|
| Base64 estándar | Usa + y / y suele mantener relleno. |
| Codificación porcentual | Escapa caracteres reservados; no es una variante Base64. |
| JWT | Añade estructura y requiere verificación criptográfica. |