JWT Debugger

JWT Debugger (Decodificar & Verificar)

Depura tokens JWT online con nuestro JWT debugger. Decodifica claims de cabecera y payload, verifica firmas HS256, RS256 y ES256, e inspecciona la expiración localmente.

Preajustes:
Token JWT Codificado
Cabecera (JOSE)(74B)
.
Payload (Claims)(248B)
.
Firma (Criptográfica)(342B)
PKCS#1 / X.509 SPKI
Tolerancia de Desviación de Reloj (Clock Skew):
60s
Length: 666 charsSegments: 3/3
Cabecera (JOSE) • Payload (Claims) • Firma (Criptográfica)
Expiration (exp): 244d ago
Cabecera Decodificada (JOSE Header)alg: RS256
{
  "alg": "RS256",
  "typ": "JWT",
  "kid": "auth0-key-2026-prod"
}
Payload Decodificado (Claims Registrados y Privados)6 registered & custom claims
{
  "iss": "https://auth.example.com/",
  "sub": "auth0|64f1a2b3c4d5e6f7",
  "aud": "https://api.example.com/v2/",
  "iat": 1772500000,
  "exp": 1772586400,
  "scope": "read:profile write:reports openid email"
}
iss (Issuer): https://auth.example.com/
sub (Subject): auth0|64f1a2b3c4d5e6f7
aud (Audience): "https://api.example.com/v2/"
iat (Issued At): 245d ago
Status:UNVERIFIED|Time: 0ms
Tamaño del Token666 B
AlgoritmoRS256
Estado de ExpiraciónToken Expirado
Salud de Seguridad85/100
Estado de la FirmaProporcione Clave Secreta o PEM para Verificar la Firma
Total de Claims6 Claims

Procesamiento en el Cliente

Cálculo criptográfico de alto rendimiento ejecutado íntegramente en la memoria del navegador.

Privacidad sin Envío al Servidor

Todos los payloads permanecen estrictamente locales con cero transmisión a servidores externos.

Exportación Lista para Producción

Formatos de salida limpios y optimizados, listos para su integración y despliegue inmediato.

ToolsAA•Utilidades web 100% privadas en el cliente
Referencia técnica y guía de arquitectura

Depurador JWT (Decodificar & Verificar) — Guía de referencia

Depura tokens JWT online con nuestra herramienta técnica. Decodifica claims del header y payload, verifica firmas HS256, RS256 y ES256, e inspecciona la expiración en local.

Depurador JWT (Decodificar & Verificar) — Guía de referencia — Arquitectura en memoria del lado del cliente y flujo de datos
Depurador JWT (Decodificar & Verificar) — Guía de referencia — Arquitectura en memoria del lado del cliente y flujo de datos

Parámetros clave y controles

Encabezado JOSE (Javascript Object Signing and Encryption)Objeto JSON (Especificación JWS RFC 7515)

Especifica el algoritmo criptográfico ('alg': HS256, RS256, ES256) y el tipo de token ('typ': 'JWT'). Debe aplicar listas blancas estrictas de algoritmos en el verificador para bloquear ataques de confusión de algoritmos. Analizado en tiempo de escaneo lineal O(n) sin backtracking de expresiones regulares.

Por defecto: {"alg":"HS256","typ":"JWT"}
Payload de Claims JWT (Conjunto de Declaraciones RFC 7519)Objeto JSON (Especificación RFC 7519)

Contiene aserciones de identidad, metadatos de la entidad y alcances de acceso. Los claims estándar registrados incluyen 'sub' (sujeto), 'iss' (emisor), 'aud' (audiencia), 'iat' (emitido en) y 'exp' (expiración en segundos epoch POSIX). El entorno local aislado de Web Crypto API decodifica los claims en tiempo O(n) con cero transmisión a redes externas.

Por defecto: {"sub":"user_123","iat":1772500000,"exp":1772503600}
Firma Compacta JWSCompendio Criptográfico Binario Base64URL

Compendio criptográfico generado al firmar 'Base64URL(Header) + "." + Base64URL(Payload)' con la clave privada o el secreto compartido. Verifica la autenticidad del mensaje y la integridad de la carga útil mediante comparación en tiempo constante frente a ataques de canal lateral por temporización.

Por defecto: Firma HMAC o RSA codificada en Base64URL
Secreto Compartido HMAC / Clave Pública PEMMaterial de Clave Criptográfica (SPKI PEM / Secreto en Bruto)

Clave criptográfica empleada para verificar la firma. HS256 requiere un secreto mínimo de 256 bits (32 bytes) para evitar ataques de fuerza bruta offline por diccionario; RS256 exige una clave pública RSA SPKI PEM de 2048 o 4096 bits; ES256 requiere una clave pública P-256 (secp256r1) importada mediante crypto.subtle.importKey() de Web Crypto API.

Por defecto: tu-secreto-de-256-bits
Tolerancia de Desfase de Reloj (Leeway)Margen de Desfase Temporal (Segundos)

Variación de tiempo operativo admisible (intervalo estándar: 30 a 120 segundos, referencia: 60 segundos) que compensa la desviación de reloj del Network Time Protocol (NTP) entre el emisor de autenticación y los verificadores de recursos durante la validación de claims 'exp' y 'nbf'.

Por defecto: 60 segundos

Consejos profesionales y mejores prácticas

Nunca confíes únicamente en la decodificación JWT del lado del cliente (Verifica la firma en el servidor de recursos)

Decodificar un JWT mediante Base64URL en el JavaScript del frontend revela los claims para personalizar la interfaz (por ejemplo, mostrar el nombre de usuario), pero no demuestra autenticidad alguna. Un atacante puede manipular claims del payload como 'role: admin' en segundos. Las pasarelas de API en producción y los servidores backend deben verificar matemáticamente la firma JWS mediante un secreto confiable o una clave pública antes de autorizar peticiones.

Defensa contra el ataque de elusión criptográfica 'alg: none' (RFC 8725 §3.1)

El estándar RFC 7519 permite el tipo de token 'alg: none' para contextos no protegidos. Las librerías de verificación vulnerables aceptan tokens con 'alg: none' y un bloque de firma vacío, lo que permite a los atacantes falsificar claims arbitrarios. Configura siempre tu middleware de verificación JWT con una lista blanca explícita de algoritmos (por ejemplo, algorithms: ['RS256']) y rechaza cualquier token cuyo 'alg' sea 'none' o no coincida con el cifrado esperado.

Exige el mínimo de entropía de 256 bits para secretos HS256 (RFC 7518 §3.2)

Las firmas simétricas HMAC son tan seguras como lo sea el secreto compartido. Si un secreto HS256 es una palabra común o tiene menos de 32 bytes (256 bits), herramientas de descifrado offline por fuerza bruta como hashcat pueden recuperar el secreto en segundos a partir de tokens interceptados. Utiliza claves de 256 bits criptográficamente aleatorias generadas con 'crypto.getRandomValues(new Uint8Array(32))' o un CSPRNG.

Mitiga ataques de confusión de claves entre cifrados simétricos y asimétricos (RFC 8725 §3.2)

En un ataque de confusión de algoritmos, un atacante modifica el encabezado de un token RS256 a 'HS256' y lo firma utilizando la clave pública RSA del servidor como secreto compartido HMAC. Si la librería de verificación del backend evalúa algoritmos dinámicamente sin comprobar estrictamente el tipo de clave, validará el token falsificado. Protégete fijando los algoritmos esperados por endpoint y segregando de forma estricta los almacenes de claves HMAC y RSA.

El payload del JWT está codificado, NO cifrado (Nunca almacenes contraseñas ni datos personales protegidos)

Un JWT estándar es un JWS (JSON Web Signature) firmado, no un JWE (JSON Web Encryption) cifrado. La carga útil está simplemente codificada en Base64URL y puede ser leída por cualquier persona con acceso a la red o a la consola del navegador. Nunca guardes credenciales de bases de datos, contraseñas en texto claro, números de la seguridad social, DNI ni datos financieros sensibles en los claims del JWT.

Problemas comunes y soluciones

⚠️Error de firma no válida (SignatureVerificationException) a pesar de introducir el secreto correcto

Este error surge cuando la clave secreta está codificada en Base64 en el servidor de autenticación (común en Supabase y Auth0), pero se ingresa como texto plano UTF-8 en el verificador. Asegúrate de activar la opción 'Base64 Secret' si tu secreto posee codificación base64. Comprueba también que no se hayan pegado caracteres de nueva línea ('\n') o comillas accidentales junto con el secreto.

⚠️Error de token expirado (TokenExpiredError: jwt expired) inmediatamente después de su generación

Los claims 'exp' e 'iat' de JWT se expresan en segundos transcurridos desde el epoch Unix (10 dígitos), no en milisegundos (13 dígitos). Si tu backend define 'exp: Date.now()', la marca de tiempo representará un futuro muy lejano o, si se divide incorrectamente, el año 1970. Emplea 'Math.floor(Date.now() / 1000) + lifetimeInSeconds' y configura una tolerancia de desfase de reloj (leeway) de 60 segundos en el verificador.

⚠️Fallo de verificación RS256 con error 'Invalid Key Format' o error de PEM SPKI

RS256 requiere una clave pública PEM SubjectPublicKeyInfo (SPKI) que inicie con '-----BEGIN PUBLIC KEY-----' y finalice con '-----END PUBLIC KEY-----'. Si utilizas un certificado PKCS#1 que comience por '-----BEGIN RSA PUBLIC KEY-----' o un endpoint JWKS, convierte la clave al formato SPKI estándar o extrae la cadena de certificados x5c en un envoltorio PEM válido.

⚠️Error de token malformado: el JWT no contiene exactamente dos puntos delimitadores

Un JWT compacto válido según RFC 7519 contiene exactamente dos caracteres de punto que delimitan tres segmentos Base64URL (Header.Payload.Signature). Si copias un token desde una petición HTTP, elimina el prefijo 'Bearer ', los caracteres de escape en URLs ('%2E') o retornos de carro ('\r\n') antes del procesamiento.

Preguntas frecuentes (FAQ)

¿Cómo se verifica la firma de un JWT y qué componentes matemáticos son necesarios?▼

Para verificar la firma de un JWT, se toma el encabezado y el payload exactos codificados en Base64URL concatenados por un punto ('header.payload'), se calcula el compendio criptográfico utilizando el algoritmo especificado en el encabezado ('alg') junto con la clave del servidor, y se compara el compendio calculado con la firma decodificada de Base64URL. Para HS256, este proceso requiere HMAC-SHA256 con un secreto compartido; para RS256, requiere la verificación RSA-SHA256 mediante la clave pública del emisor.

¿Cuál es la diferencia entre HS256 y RS256 en la autenticación JWT?▼

HS256 es un algoritmo simétrico en el que se utiliza la misma clave secreta tanto para firmar como para verificar tokens, ideal cuando el emisor y la pasarela de API comparten un perímetro interno seguro. RS256 es un algoritmo asimétrico donde el servidor de autenticación firma los tokens con una clave privada y los servidores de recursos verifican la validez con un certificado público, permitiendo que microservicios y terceros corroboren la autenticidad sin exponer la clave privada de firma.

¿Puede modificarse o manipularse un token JWT sin invalidar su firma?▼

No. Cualquier alteración en el encabezado o en el payload —como elevar el rol de un usuario de 'user' a 'admin' o extender la marca de tiempo de expiración— modifica la entrada criptográfica. Sin poseer la clave privada original o el secreto compartido, un atacante no puede generar una firma coincidente, por lo que cualquier verificador estándar rechazará el token de inmediato con un error de firma no válida.

¿Por qué nunca deben almacenarse datos confidenciales como contraseñas o tarjetas de crédito en el payload de un JWT?▼

Porque los tokens JWT estándar únicamente están firmados digitalmente (JWS) y no cifrados (JWE). La carga útil se encuentra simplemente codificada en Base64URL, lo que proporciona nula confidencialidad. Cualquiera que intercepte el token en tránsito, inspeccione el tráfico de red o consulte el almacenamiento local puede decodificar al instante el payload en Base64URL y leer todos los claims en texto plano.

¿Qué son los claims registrados de JWT y qué significan iat, exp y nbf?▼

Los claims registrados son claves de metadatos predefinidas por el estándar RFC 7519: 'iat' (Issued At) indica la marca de tiempo epoch de creación; 'exp' (Expiration Time) define el instante a partir del cual el token debe rechazarse; 'nbf' (Not Before) especifica el momento más temprano en el que el token es válido; 'iss' identifica al emisor del token; 'sub' identifica al sujeto principal; y 'aud' especifica la audiencia destinataria.

Herramientas y utilidades relacionadas

Todas las herramientas →
Generador CSP & Content Security PolicySeguridad

Genera cabeceras Content Security Policy (CSP) seguras al instante. Configura script-src, style-src, nonces y hashes para mitigar ataques XSS y resolver errores de CSP.

Abrir herramienta→
Generador de Hashes Bcrypt y Verificador de ContraseñasSeguridad

Genera hashes de contraseña Eksblowfish seguros con rondas de salt configurables (4-16) y verifica contraseñas localmente en tu navegador.

Abrir herramienta→
Generador y Verificador de Firmas HMACSeguridad

Calcule y verifique códigos de autenticación de mensajes RFC 2104 (HMAC-SHA256, HMAC-SHA512, HMAC-SHA1, HMAC-MD5) con verificación en tiempo constante inmune a ataques de temporización.

Abrir herramienta→
Cifrador y Descifrador AES-GCM / CBC en el ClienteSeguridad

Cifrado autenticado AES-256 con aceleración por hardware ejecutado 100% en el navegador mediante Web Crypto API. Cero retención en servidores.

Abrir herramienta→
Generador de Claves RSA Públicas y PrivadasSeguridad

Genera pares de claves RSA criptográficamente seguras (2048 y 4096 bits) en formato PEM PKCS#8 mediante la API Web Crypto de tu navegador.

Abrir herramienta→
Codificador y Decodificador Base58 / Base58CheckSeguridad

Convierte cadenas de texto y valores hexadecimales al formato Base58 utilizado en Bitcoin e IPFS, con verificación de suma de control SHA-256.

Abrir herramienta→