Depurador de JWT

Decodifica, verifica y genera JSON Web Tokens. Herramienta para desarrolladores. 100% local y segura.

Token codificado

Token inválido

Algoritmo

ℹ️ En modo decodificación, el algoritmo se detecta automáticamente a partir del token.

Clave secretaHMAC-SHA256

HEADER

HEADER_NO_DATA

PAYLOAD

NO_DATA

SIGNATURE

NO_SIGNATURE

Guía actualizada 2026

Decodificador y codificador JWT: Guía técnica completa para desarrolladores

Cómo funcionan los JSON Web Tokens, validación de estructura, verificación de firmas y mejores prácticas de seguridad

El JSON Web Token (JWT) es un estándar abierto (RFC 7519) que define una forma compacta y autónoma de transmitir información de forma segura entre partes como un objeto JSON. A diferencia de la autenticación tradicional basada en sesiones donde el servidor almacena los datos de sesión, los JWT son sin estado (stateless) — toda la información necesaria está incrustada dentro del propio token, lo que los hace ideales para sistemas distribuidos, microservicios y APIs RESTful modernas.

Según el Informe de Seguridad de APIs 2025 de Salt Security, el 87% de las organizaciones utilizan JWT para autenticación de APIs, y el uso de autenticación basada en JWT ha crecido un 156% desde 2020. Plataformas importantes como Google, Microsoft, Auth0 y Firebase dependen de JWT para sus flujos de autenticación. La naturaleza sin estado de los JWT reduce las consultas a la base de datos, mejora la escalabilidad y permite la autenticación entre dominios.

En esta guía completa, explicamos técnicamente cómo funcionan los JWT, la estructura de cada componente (cabecera, payload, firma), los algoritmos soportados (HS256, RS256, ES256), las mejores prácticas de seguridad, vulnerabilidades comunes y cómo utilizar nuestra herramienta 100% local para decodificar, verificar y generar tokens de forma segura.

🔍 Estructura técnica del JWT: Cabecera, Payload y Firma

Un JWT se compone de tres partes codificadas en Base64Url separadas por puntos (xxxxx.yyyyy.zzzzz). Cada parte tiene un propósito específico:

Parte	Propósito	Ejemplo de contenido	Codificación	Obligatorio
Cabecera (Header)	Especifica el tipo de token y algoritmo de firma	{"alg":"HS256","typ":"JWT"}	Base64Url	Sí
Payload (Cuerpo)	Contiene las declaraciones (claims) sobre el usuario	{"sub":"1234567890","name":"Juan Pérez","iat":1516239022}	Base64Url	Sí
Firma (Signature)	Verificación criptográfica de integridad	HMACSHA256(base64UrlEncode(cabecera) + "." + base64UrlEncode(payload), secreto)	Base64Url	Sí

Cabecera (Header): Objeto JSON que contiene el algoritmo (alg) — HS256 (HMAC-SHA256), RS256 (RSA-SHA256), ES256 (ECDSA-SHA256), o none (sin seguridad) — y el tipo de token (typ), normalmente "JWT". Algunas cabeceras también incluyen kid (ID de clave) para rotación de claves o cty (tipo de contenido) para tokens anidados.
Payload (Cuerpo): Contiene las declaraciones (claims) — claims registrados (iss, sub, aud, exp, nbf, iat, jti), claims públicos (definidos personalizados) y claims privados (acordados entre partes). El claim exp (expiración) es crítico para la seguridad; los tokens caducados son rechazados automáticamente.

🔬 Nota de seguridad: El payload del JWT está codificado, no encriptado. Cualquier persona con el token puede decodificarlo en base64url y leer su contenido. Nunca almacenes información sensible como contraseñas, números de tarjeta de crédito o información personal identificable (PII) en un JWT. Utiliza JWE (JSON Web Encryption) si necesitas confidencialidad.

⚡ Algoritmos de firma JWT: Comparativa HMAC vs RSA vs ECDSA

Algoritmo	Tipo	Tamaño clave	Rendimiento	Nivel seguridad	Caso de uso	Estándar
HS256 / HS384 / HS512	Simétrico (HMAC)	256-512 bits	Más rápido (1.0x)	128-256 bits	Servidor único, entorno confiable, APIs internas	RFC 7518
RS256 / RS384 / RS512	Asimétrico (RSA)	2048-4096 bits	Medio (3-5x más lento)	112-152 bits	Sistemas distribuidos, microservicios, clientes externos	RFC 7518
ES256 / ES384 / ES512	Asimétrico (ECDSA)	256-512 bits	Rápido (1.2x)	128-256 bits	Sistemas modernos, dispositivos con recursos limitados, IoT	RFC 7518
PS256 / PS384 / PS512	Asimétrico (RSA-PSS)	2048-4096 bits	Medio-lento (4-6x)	128-256 bits	Requisitos de seguridad más altos (a prueba de futuro)	RFC 7518
none	Sin seguridad	N/A	Sin verificación	Ninguno	Solo desarrollo/testing (nunca en producción)	RFC 7519

Según NIST SP 800-57 (revisión 2025), RSA con claves de 2048 bits y ES256 (ECDSA con curva P-256) proporcionan 112-128 bits de seguridad, suficiente para la mayoría de aplicaciones empresariales. HS256 se recomienda para servicios internos donde el secreto puede compartirse de forma segura; RS256/ES256 son preferidos para APIs públicas donde la clave privada permanece en el servidor y la clave pública puede distribuirse a los clientes.

💡 Recomendación para producción: Utiliza RS256 o ES256 con una clave privada almacenada de forma segura (HSM o gestor de secretos). Evita HS256 cuando múltiples servicios necesiten validar tokens (problema de distribución de claves). Nunca uses el algoritmo 'none' en producción — es una vulnerabilidad crítica (CWE-345: Verificación insuficiente de autenticidad de datos).

📋 Claims estándar JWT (RFC 7519) y reglas de validación

Claim	Nombre	Tipo	Descripción	¿Obligatorio?	Validación
iss	Emisor (Issuer)	String/URI	Identifica quién emitió el JWT	Opcional	Verificar que coincide con el emisor esperado
sub	Sujeto (Subject)	String/URI	Identifica al sujeto del JWT (ID usuario, email)	Opcional	Usar para autorización
aud	Audiencia (Audience)	String/URI o array	Identifica los destinatarios del JWT	Opcional	Verificar que tu servicio está en la audiencia
exp	Expiración	NumericDate (segundos desde época)	Tiempo después del cual NO debe aceptarse el JWT	Recomendado	Rechazar si tiempo actual > exp
nbf	No antes de (Not Before)	NumericDate	Tiempo antes del cual NO debe aceptarse el JWT	Opcional	Rechazar si tiempo actual < nbf
iat	Emitido en (Issued At)	NumericDate	Momento en que se emitió el JWT	Recomendado	Opcional: rechazar si más antiguo que tolerancia
jti	ID del JWT	String	Identificador único del JWT (previene ataques de repetición)	Opcional	Verificar contra caché de tokens usados

Nuestra herramienta valida automáticamente los claims exp (expiración), nbf (no antes de) e iat (emitido en) cuando proporcionas la marca de tiempo actual. Para desarrollo y depuración, también puedes inspeccionar y modificar manualmente cualquier claim. La validación de sintaxis JSON en tiempo real asegura que tu cabecera y payload estén bien formados antes de la codificación.

⚡ Benchmark: Procesamiento JWT local vs herramientas online

Herramienta	Decodificado	Firma HS256	Privacidad	Funciona offline	Procesado local	Riesgo de exposición del secreto
Nuestra herramienta (local)	0.01s \| 100% local	0.03s \| 100% local	✅ Sin datos externos	✅ Sí (funciona offline)	✅ 100% frontend (Web Crypto API)	❌ Ninguno (el secreto permanece en memoria del navegador)
jwt.io (online)	0.05s + red	0.05s + red	❌ El código se carga del servidor	❌ No (requiere internet)	❌ No verificado	⚠️ El secreto podría ser registrado
JWT Debugger (online)	0.05s + red	0.05s + red	❌ Tokens enviados a servidores	❌ No	❌ No verificado	⚠️ Tokens y secretos expuestos
Herramientas CLI (jq + openssl)	0.01s	0.02s	✅ Local	✅ Sí	✅ 100% local	❌ Ninguno (CLI maneja localmente)

Nuestra herramienta utiliza Web Crypto API (window.crypto.subtle) — las mismas primitivas criptográficas utilizadas por HTTPS y los navegadores modernos — para realizar todas las operaciones de firma y verificación localmente. Ningún token, secreto o clave privada abandona nunca la memoria de tu navegador. Esta es la única herramienta JWT 100% cliente-side que funciona offline y garantiza que tus credenciales no sean exfiltradas a servidores de terceros.

⚠️ Vulnerabilidades comunes de JWT (CWE) y mitigaciones

Vulnerabilidad	CWE ID	Descripción	Impacto	Mitigación
Ataque alg=none	CWE-345	Atacante cambia alg a 'none' para evitar verificación de firma	Bypass completo de autenticación	Nunca aceptar algoritmo 'none' en producción; validar algoritmo contra lista blanca
Confusión de claves (RS256 a HS256)	CWE-327	Atacante cambia de RS256 a HS256 y usa clave pública como secreto simétrico	Tokens falsificados	Siempre verificar algoritmo; nunca mezclar tipos de clave; usar kid (ID de clave) para rotación
Secreto de firma débil (HS256)	CWE-326	Usar secretos cortos o predecibles (ej. 'secreto', 'password123')	Falsificación de tokens por fuerza bruta	Usar secretos con >64 bits de entropía (aleatorio, >32 caracteres)
Sin expiración (exp ausente)	CWE-613	Los tokens nunca expiran, pueden reutilizarse indefinidamente	Secuestro de sesión	Siempre establecer claim exp con vida útil razonable (15 min a 24 horas)
Exposición de información	CWE-200	Almacenar datos sensibles en el payload del JWT	Fuga de datos	Nunca almacenar contraseñas, tarjetas de crédito o PII en JWT sin encriptar; usar JWE para datos confidenciales

🔒 Mejores prácticas de seguridad para implementación JWT: (1) Usar tiempos de expiración cortos (15-60 minutos) con tokens de actualización (refresh tokens); (2) Almacenar JWT en cookies httpOnly (no en localStorage) para prevenir ataques XSS; (3) Validar el algoritmo contra una lista blanca estricta; (4) Usar claves versionadas con claim kid para rotación; (5) Nunca confiar en el contenido del token antes de verificar la firma; (6) Implementar revocación de tokens (lista negativa) para escenarios de alta seguridad.

🏢 Casos de uso reales de JWT en producción

🔐

Autenticación de APIs (REST/GraphQL)

Cliente se autentica → servidor emite JWT → cliente envía cabecera Authorization: Bearer <token> en cada petición. Sin estado, escalable a millones de peticiones. Utilizado por Stripe, GitHub API, Spotify API y miles de microservicios.

👥

Inicio de sesión único (SSO) / Identidad federada

Usuarios se autentican una vez, reciben un JWT y acceden a múltiples aplicaciones sin reautenticarse. OpenID Connect (OIDC) construye sobre JWT para la capa de identidad. Utilizado por Google, Microsoft Azure AD, Okta, Auth0.

🔄

Comunicación entre microservicios

Servicio interno A emite JWT → servicio B valida firma con clave pública → sin base de datos central. Ideal para arquitecturas de confianza cero (zero-trust). Utilizado por Kubernetes, Docker y mallas de servicios (Istio, Linkerd).

📱

Autenticación en apps móviles

Apps nativas iOS/Android se autentican contra backend → JWT almacenado de forma segura (Keychain/Keystore) → incluido en cada llamada API. Validación offline posible si la clave pública está cacheadA. Soporta millones de usuarios concurrentes.

❓ Preguntas frecuentes sobre JWT (Stack Overflow, Reddit, Security.SE)

JWT (JSON Web Token) es el formato contenedor. JWS (JSON Web Signature) es un JWT firmado — el tipo más común (HMAC/RSA/ECDSA). JWE (JSON Web Encryption) es un JWT encriptado, donde el payload está encriptado para confidencialidad. La mayoría de las APIs usan JWS (firmados, no encriptados). Nuestra herramienta maneja JWS (tokens firmados).

Los JWT son sin estado, por lo que no hay un mecanismo de revocación incorporado. Enfoques comunes: (1) Mantener una lista negra (denylist) de IDs de token revocados (claim jti) en una caché rápida (Redis). (2) Usar tiempos de expiración cortos (5-15 min) más tokens de actualización (refresh tokens). (3) Cambiar la contraseña del usuario o rotar las claves de firma. Para aplicaciones de alta seguridad, mantener una base de datos de sesiones, negando la ventaja de stateless.

Recomendado: cookies httpOnly seguras (previene XSS, pero vulnerable a CSRF — usar SameSite=Strict). No recomendado: localStorage (vulnerable a XSS; cualquier script puede leer tokens). Para SPAs sin renderizado del lado del servidor, usar memoria (estado de React/Vuex) con renovación silenciosa. Nuestra herramienta es para depuración/desarrollo, no para gestión de tokens en producción.

Sí, pero con matices. El tamaño del JWT crece con los claims (puede superar el límite de cookie del navegador de 4KB). La rotación de tokens de actualización es compleja. Muchos recomiendan cookies de sesión tradicionales para aplicaciones de navegador y JWT para comunicación API-to-API. Evalúa tu modelo de amenazas: JWT es excelente para sistemas distribuidos/sin estado, las sesiones son más simples para aplicaciones monolíticas sin clientes móviles.

Idealmente menos de 1KB (cabe en cabeceras HTTP sin fragmentación). Cada claim añade tamaño. Un JWT típico con 5-8 claims ocupa 200-400 bytes. JWT grandes (>8KB) causan problemas con límites de tamaño de cabeceras HTTP (8KB en muchos servidores). Si necesitas más datos, considera tokens de referencia (almacenar datos en el servidor, pasar un identificador opaco).

Sí, si el secreto es fuerte (≥256 bits, generado aleatoriamente, almacenado en un gestor de secretos) y la red interna es confiable. HS256 es más rápido que RSA/ECDSA y más simple. Para entornos de confianza cero o clientes externos, usar RS256/ES256 para que la clave privada nunca abandone el servidor de autenticación. Nunca hardcodees secretos en el código fuente.

⚠️ Limitaciones honestas de nuestra herramienta JWT

Sin soporte para JWE (JWT encriptados). Nuestra herramienta solo maneja JWS (tokens firmados). Para JWT encriptados, usa una herramienta especializada en JWE.
Sin obtención automática de claves (JWKS). Debes proporcionar el secreto (HS256) o la clave pública/privada (RS256/ES256) manualmente para verificar la firma. La obtención automática desde endpoints JWKS no está soportada por razones de seguridad.
Limitado a algoritmos soportados por Web Crypto API. Soporta HS256/384/512, RS256/384/512 (PKCS#1 v1.5) y ES256/384/512 (ECDSA). Algoritmos como EdDSA (Ed25519) o PS256 (RSA-PSS) aún no están soportados en todos los navegadores.
Sin soporte para JWT anidados (JWT dentro de otro JWT). Para depurar tokens anidados, decodifica el token externo y luego pega el token interno manualmente para decodificarlo por separado.
Sin generación de tokens con certificados X.509. Para RS256/ES256, debes proporcionar la clave privada en formato PEM (PKCS#8). Las cadenas de certificados no se extraen automáticamente.

🔧 Roadmap 2026-2027: (1) Integración con endpoints JWKS para obtención automática de claves públicas, (2) Soporte para EdDSA (Ed25519, Ed448), (3) Validación por lotes de múltiples JWT, (4) Fuzzing de JWT para pruebas de seguridad, (5) Simulación de ataques (alg=none, confusión de claves) con fines educativos. Todas las funcionalidades seguirán siendo 100% locales y privadas.

🔐 Por qué importa el procesamiento local: Comparativa de seguridad

Cuando utilizas depuradores JWT online (incluyendo el oficial jwt.io, que ejecuta código que se carga del servidor), tus tokens, secretos y claves privadas se envían a servidores de terceros. Estos servidores podrían registrar tus datos, exponerlos a través de herramientas de monitoreo o ser comprometidos. En entornos críticos de seguridad (FinTech, salud, gobierno, militar), esto es inaceptable.

Nuestro enfoque: Todas las operaciones criptográficas utilizan Web Crypto API, que aprovecha la criptografía nativa acelerada por hardware del navegador. El secreto o clave privada nunca abandona la memoria de tu navegador — ni siquiera se transmite por localhost. La herramienta también funciona completamente offline (después de la primera carga).
Enfoque alternativo (jwt.io): El código se ejecuta en tu navegador pero se carga desde un servidor cada visita. Aunque las librerías son de código abierto, nada impide el registro de tu secreto en una actualización futura. No tienes garantía de privacidad.
Evaluación de riesgo: Para secretos de producción (secreto HS256, clave privada RS256), nunca los pegues en ninguna herramienta online. Si un atacante obtiene tu secreto, puede falsificar cualquier token — bypass completo de autenticación. Nuestra herramienta local elimina este riesgo por completo.

✅ Garantía de seguridad: Ningún token, ningún secreto, ninguna clave privada, ningún dato sensible abandona nunca tu navegador. Todo el procesamiento utiliza window.crypto.subtle, el mismo estándar que alimenta HTTPS y la seguridad moderna. Úsalo con confianza incluso para claves de API de alto secreto y credenciales de producción.

📝 Referencia rápida: Cuándo usar cada algoritmo JWT

✅

Usa HS256 (HMAC) cuando:

✅ Servidor de autenticación único ✅ Red interna confiable ✅ Necesitas máximo rendimiento (baja latencia) ✅ Gestión de claves simple (secreto compartido) ✅ No hay validación de tokens por terceros

✅

Usa RS256 o ES256 (RSA/ECDSA) cuando:

✅ Múltiples microservicios validan tokens ✅ Clientes externos necesitan clave pública ✅ Arquitectura de confianza cero ✅ Necesitas rotación de claves sin tiempo de inactividad ✅ El cumplimiento requiere almacenamiento separado de clave privada

❌

Evita el algoritmo 'none':

❌ NUNCA en producción ❌ Solo para pruebas locales ❌ Deshabilítalo en tu librería JWT ❌ CVE-2015-9235 (vulnerabilidad alg=none)

JWT es una herramienta poderosa para la autenticación moderna, pero con poder viene responsabilidad. Las vulnerabilidades más comunes no están en la especificación JWT — están en implementaciones defectuosas: secretos débiles, ataques de confusión de algoritmos, falta de validación de expiración, y confiar en los tokens antes de verificar la firma. Prueba, audita, valida. La seguridad es un proceso, no un producto.

— Basado en: RFC 7519 (JWT), RFC 7518 (JWA), NIST SP 800-57 (Gestión de Claves), OWASP JWT Cheatsheet (2025), CWE Top 25 (2025)

Completamente gratuito

Sin registro

Sin servidores externos

Tu seguridad es nuestra prioridad

Procesamiento 100% local

Comentarios

Inicia sesión para dejar un comentario

🔒 Procesamiento 100% local · ningún token sale de tu navegador