Los JWTs son el formato de token de autenticación más común en aplicaciones web. Cada vez que inicias sesión, una API emite un JSON Web Token que lleva tu identidad, permisos y a menudo detalles personales. Cuando algo sale mal — una sesión expirada, una petición rechazada, un compañero preguntando “¿qué hay en este token?” — el primer instinto es decodificarlo.
La mayoría de los decodificadores JWT en línea funcionan. La pregunta es si deberías confiarles tu token.
Qué hay realmente en un JWT
Un JWT son tres cadenas codificadas en base64url separadas por puntos:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NSIsIm5hbWUiOiJBbGljZSIsImlhdCI6MTUxNjIzOTAyMn0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
Decodifica las dos primeras partes y obtienes JSON:
// Header
{
"alg": "HS256",
"typ": "JWT"
}
// Payload
{
"sub": "12345",
"name": "Alice",
"iat": 1516239022
}
La firma es un hash criptográfico que demuestra que el token fue emitido por alguien que tiene el secreto. Cualquiera puede decodificar el payload — ese no es el límite de seguridad. El límite es si puedes verificar la firma.
Decodificar vs verificar
Esta distinción importa:
- Decodificar = decodificar el JSON en base64 para poder leerlo. No se requiere secreto. Cualquiera puede hacerlo.
- Verificar = comprobar la firma contra un secreto conocido para confirmar que el token no fue alterado. Requiere el secreto.
La mayoría de los decodificadores en línea solo decodifican. Muestran el encabezado y payload pero nunca te piden tu secreto — porque no están verificando, solo mostrando.
Para depuración (qué claims tiene este token, cuándo expira), decodificar es suficiente. Para autenticación, necesitas verificación — y tiene que ocurrir en infraestructura que tú controles.
Claims estándar de JWT que verificar
Cuando decodificas un JWT, busca estos claims registrados:
| Claim | Significado | Qué verificar |
|---|---|---|
exp |
Tiempo de expiración (marca de tiempo Unix) | ¿Está en el futuro? |
nbf |
No antes de (marca de tiempo Unix) | ¿Está en el pasado? |
iat |
Emitido en (marca de tiempo Unix) | ¿Cuánto tiempo tiene el token? |
iss |
Emisor | ¿Coincide con tu servidor de autenticación? |
aud |
Audiencia | ¿Coincide con tu API? |
sub |
Sujeto (ID de usuario) | ¿Es el usuario esperado? |
La razón más común por la que un token “válido” falla: está expirado. Verifica exp primero.
Cómo decodificar un JWT en tu navegador
No necesitas una herramienta de terceros para esto. Un JWT son solo tres cadenas base64url. Pero si prefieres no memorizar el comando de decodificación, un decodificador basado en navegador hace lo mismo sin subir tu token:
- Pega el JWT en el decodificador
- Ve el encabezado, payload y firma decodificados
- Verifica el claim
exppara ver si el token está expirado - Comprueba que el algoritmo en el encabezado coincide con lo que esperas
El decodificador JWT en DevSpeedTools se ejecuta completamente en tu navegador. Sin peticiones de red, sin subida, sin registro. Abre DevTools → Network, pega un token y confirma que nada sale de tu máquina.
Cuándo necesitas verificación (no solo decodificación)
Si estás depurando un problema de autenticación y necesitas saber si el token es válido — no solo qué contiene — necesitas verificar la firma. Esto tiene que ocurrir con el mismo secreto o clave pública que usa tu servidor de autenticación.
Opciones que no implican pegar tu secreto en un sitio web:
- Node.js:
jsonwebtoken.verify(token, process.env.JWT_SECRET) - Python:
jwt.decode(token, key, algorithms=['HS256']) - Go:
token, err := jwt.Parse(tokenString, keyFunc) - CLI:
jwt-cli(Rust) opyjwtcon una línea de comandos
Nunca pegues un secreto de producción en una herramienta en línea. El token no es un secreto. El contenido a menudo lo es.
Resumen rápido
- Usa un decodificador basado en navegador para inspección rápida. Sin subida, sin filtraciones.
- Usa CLI o tu propio código para verificación. Nunca pegues un secreto en un sitio web.
- Verifica
expprimero — los tokens expirados son la causa de la mayoría de los problemas de “mi token dejó de funcionar”.