Herramientas de desarrollo · JWT decodificador
Base64 vs Base64url: por qué falla un JWT en un decodificador Base64 estándar
· Cómo funciona
jwt base64 codificación
Pegue un segmento JWT en un decodificador base64 normal y puede quejarse de caracteres o relleno. Esta publicación explica los mandatos JWS de la variante base64url y cómo convertir entre los dos.
Carácter no válido, relleno incorrecto: los errores que aparecen cuando base64 se encuentra con base64url
Un mensaje de "carácter no válido" o "relleno incorrecto" a menudo significa que se le dio un segmento JWT a un decodificador que espera Base64 normal. El token se puede copiar correctamente. Su representación sigue las convenciones de base64url, mientras que la utilidad receptora acepta un alfabeto relacionado pero no idéntico o insiste en un relleno explícito.
ToolAcre evita esa discrepancia entre el encabezado y la carga útil. Su decodificador de bytes elimina espacios en blanco, traduce símbolos seguros para URL, restaura el relleno omitido cuando la longitud lo permite y luego convierte bytes como estricto UTF-8. El fallo en cualquier etapa se convierte en un error INVALID_JWT en lugar de una excepción sin formato del navegador.
Dos alfabetos: más y barra versus guión y guión bajo, y por qué las URL forzaron el cambio
Base64 estándar usa más y barra para sus dos últimas posiciones alfabéticas. Base64url asigna guiones y guiones bajos a esas mismas posiciones. Los valores subyacentes de seis bits no cambian, por lo que traducir `-` a `+` y `_` a `/` conserva cada byte decodificado; sólo cambia la ortografía segura para el transporte.
Esas sustituciones son importantes en canales donde más o barra ya tienen sintaxis. Una ortografía segura para URL reduce la interpretación accidental mediante el procesamiento de formularios o rutas. No añade secreto, integridad o autenticidad. Cualquiera que reciba un segmento puede revertir las sustituciones y recuperar los mismos bytes sin clave criptográfica.
Relleno: por qué JWS elimina los signos iguales y cómo restaurarlos para un decodificador estricto
ToolAcre acepta relleno omitido. Después de la normalización del alfabeto, examina la longitud del segmento módulo cuatro. Un resto de dos necesita dos signos iguales y un resto de tres necesita uno. Un resto de uno es imposible para un valor Base64 completo y se rechaza como una cadena truncada en lugar de adivinar su forma.
La recuperación del acolchado es una estructura mecánica, no una reparación simbólica. Agregar signos igual no puede restaurar los caracteres perdidos durante la copia, y la decodificación exitosa de bytes no muestra que los bytes provengan de un emisor. La implementación simplemente reconstruye la longitud canónica requerida por el decodificador del navegador antes de llamar a `atob`.
Decodificar todo el token de una vez: el error de no dividir primero en los puntos
Un token firmado compacto debe dividirse en sus puntos antes de decodificar cualquier segmento. Pasar `header.payload.signature` a una función Base64 introduce puntos que pertenecen a la serialización JWT, no al alfabeto Base64. ToolAcre requiere exactamente tres segmentos para esta entrada en forma de JWS e informa el recuento observado cuando esa estructura está ausente.
El caso de cinco partes recibe un mensaje JWE separado porque la serialización compacta cifrada no es el mismo objeto. En cambio, dos o cuatro partes sugieren un truncamiento o una entrada incorrecta. Esta verificación estructural se produce antes de la interpretación de JSON, manteniendo un error de copia distinto del texto codificado con formato incorrecto o JSON con formato incorrecto.
Ejemplo resuelto: convertir un segmento de base64url a base64, rellenarlo y decodificarlo a JSON
Para una conversión trabajada, tome `eyJhbGciOiJIUzI1NiJ9`. No contiene caracteres alfabéticos que difieran entre las variantes, pero el relleno que le falta aún ilustra el proceso. Su longitud permite la restauración del acolchado; la decodificación produce UTF-8 bytes para `{"alg":"HS256"}`, y el análisis JSON produce un objeto con una propiedad `alg`.
Un segmento que contiene un guión o guión bajo sigue la misma secuencia con los dos reemplazos de símbolos primero. ToolAcre realiza estas operaciones dentro de `base64ToBytes`, luego `decodeSegment` analiza el texto resultante. El algoritmo mostrado es lo que declara el encabezado no verificado; no se selecciona como política de verificación.
Unicode en reclamaciones: por qué los bytes decodificados deben leerse como UTF-8 para mostrar los nombres correctamente
Los reclamos pueden contener acentos, caracteres CJK o emoji. Base64 opera con bytes, por lo que tratar cada byte decodificado como un carácter independiente corrompe el texto multibyte. La ruta correcta son los símbolos codificados en bytes y luego un decodificador UTF-8. ToolAcre construye `TextDecoder` con modo fatal, por lo que UTF-8 no válido falla ruidosamente.
Las pruebas cubren una carga útil que contiene `Zoë 世界 🙂` y esperan la cadena exacta después de la decodificación. Ese resultado demuestra que la canalización de byte a texto conservó este valor de prueba. Todavía no dice nada sobre si la persona nombrada en la carga útil existe, si el emisor aprobó el reclamo o si el token fue alterado.
Lo que esto no cubre: el segmento de firma, que se decodifica en bytes en lugar de texto y necesita una clave para significar algo.
El segmento de firma está fuera de la ruta JSON. ToolAcre mantiene su forma codificada original y sólo intenta medir la longitud del byte decodificado. La firma no válida Base64 genera una advertencia pero no impide la inspección del encabezado y la carga útil; un tercer segmento vacío produce una advertencia diferente de que no hay bytes de firma presentes.
Ninguno de los resultados es un resultado de verificación. Una validación de firma significativa necesita material clave confiable, un algoritmo permitido elegido independientemente de la entrada controlada por el atacante y verificaciones de aplicaciones. Un recuento de bytes es útil para diagnosticar la forma, pero cero o treinta y dos bytes medidos no pueden autorizar una solicitud ni establecer un emisor.
Conclusión: use un decodificador que hable base64url: el decodificador ToolAcre JWT maneja el alfabeto y el relleno para el encabezado y la carga útil
Utilice un decodificador que comprenda base64url cuando el trabajo inmediato sea inspeccionar JSON. ToolAcre maneja el alfabeto, el relleno omitido, el UTF-8 estricto y el JSON de solo objeto para los dos primeros segmentos. También rechaza longitudes imposibles y envuelve errores de análisis en mensajes que identifican si el encabezado o la carga útil fallaron.
Deténgase en ese límite. Una decodificación limpia significa que la cadena tenía bytes recuperables y objetos JSON adecuados. No significa que sus afirmaciones sean confiables, autenticadas, autorizadas o no modificadas. Sólo un verificador configurado por separado puede responder esas preguntas, y esta herramienta de navegador no expone deliberadamente ninguna operación de verificación.