Decodificador y verificador JWT
Pega un JSON Web Token y léelo como debería hacerlo tu servidor: encabezado y carga decodificados a JSON legible, las afirmaciones de tiempo dibujadas como una línea temporal —emitido, válido desde, expira, expirado— y, para HS256, HS384 y HS512, una verificación de firma real contra un secreto que tú aportas. Todo ocurre en tu navegador. Un token es una credencial, y en este sitio las credenciales no se pegan en chats de IA con registro ni en servidores de desconocidos.
Qué es un token y qué prueba decodificarlo
Un JWT son tres segmentos Base64URL unidos por puntos: un encabezado que nombra el algoritmo de firma, una carga de afirmaciones y una firma sobre los dos primeros. El segmento central —el que todo el mundo quiere leer— es una codificación, no un cifrado: el decodificador Base64 lo abre sin ninguna clave, y por eso un token nunca debe llevar nada que no imprimirías en un póster. Lo que la firma añade es procedencia: edita una afirmación y el HMAC ya no coincide, siempre que el verificador compruebe de verdad; los fallos que llenan los informes de incidentes son servidores que decodificaron y confiaron sin verificar, bibliotecas que dejaron que el token eligiera su propio algoritmo y tokens «none» aceptados como evangelio. Esta página refleja el flujo honesto: decodificar y leerlo todo, leer la línea temporal de afirmaciones contra el reloj (un exp en el pasado es un token muerto por válida que sea la firma), atender los avisos de algoritmo y solo entonces verificar —localmente, con el secreto permaneciendo en la misma pestaña del navegador que el token. Si el secreto con el que depuras venía de un archivo de configuración, el validador .env comprueba ese archivo sin transmitirlo tampoco; el artículo principal, nunca dejes que un chatbot toque tus secretos, explica por qué toda la familia de trabajos se mudó al navegador.
Preguntas frecuentes
¿Es seguro pegar aquí un token de producción?
Es el lugar más seguro de internet para hacerlo, y la razón de que esta herramienta exista. La decodificación ocurre en tu navegador, en el código de esta página: el token nunca se transmite, se almacena ni se registra. Compáralo con las alternativas que la gente usa de verdad: chats de IA, que conservan la conversación en servidores de un tercero, y «decodificadores JWT en línea» cuyo servidor ve lo que sea que pegues. Un token es una credencial viva hasta que expira; en cualquier sitio donde se pegue, puede reproducirse desde ahí. Aquí no va a ninguna parte: la misma regla de solo-local que el validador .env.
Si cualquiera puede decodificar un JWT, ¿por qué no es eso un agujero de seguridad?
Porque decodificar nunca fue la protección. Un JWT es una declaración firmada, no cifrada: la carga es Base64URL, una codificación, legible por cualquiera que tenga el token, y la seguridad vive en la firma, que prueba que la declaración fue emitida por quien posee la clave y no ha sido alterada. El desastre clásico es un desarrollador que trata la carga como secreta, o un servidor que no verifica la firma para que una carga editada a mano pase sin más. El artículo Base64 no es cifrado cubre la confusión de codificación que hay debajo de ambos.
¿Por qué podéis verificar HS256 aquí pero no mi token RS256?
HS256 es simétrico: un secreto compartido firma y verifica, así que un secreto que escribas puede comprobarse localmente con HMAC. RS256 es asimétrico: se firma con una clave privada y se verifica con la clave pública correspondiente, que esta página tendría que pedirte, y una página que invita a pegar claves enseña un hábito que termina en una clave privada filtrada. Verifica los tokens RS256 con el JWKS publicado por el emisor en tu propio código o herramientas, y nunca pegues una clave privada en ningún sitio web ni chat, incluido este.
¿Qué significa «alg: none» y por qué el aviso en rojo?
Significa que el token declara que no está firmado, y un servidor que honra esa declaración acepta cualquier carga de cualquiera, sin clave. Fue una clase de vulnerabilidad real y repetida: bibliotecas que confiaban en el propio campo alg del token podían recibir un token «none» con una carga de administrador. El aviso es sonoro porque la respuesta correcta es sonora: un token none es un dato no autenticado, y cualquier sistema que lo acepte tiene una omisión de autenticación por diseño.
La firma cuadra. ¿He terminado?
Has probado que el token fue acuñado por un poseedor del secreto y que su contenido no está alterado. No has probado que sea para ti (comprueba la afirmación aud), que esté vigente (la línea temporal de arriba muestra exp y nbf), ni que el secreto en sí sea fuerte: HS256 con un secreto adivinable como «secret» cae ante la fuerza bruta sin conexión, tras lo cual cualquiera puede acuñar tokens que tu comprobación bendecirá. La verificación es una línea de la auditoría, no toda la auditoría.