JWT Debugger

Decode, verify, and generate JSON Web Tokens. Developer tool. 100% local and secure.

Encoded token

Invalid token

Algoritmo

ℹ️ In decode mode, the algorithm is automatically detected from the token.

Clave secretaHMAC-SHA256

HEADER

HEADER_NO_DATA

PAYLOAD

NO_DATA

SIGNATURE

NO_SIGNATURE

Updated 2026 Guide

JWT Decoder and Encoder: Complete Technical Guide for Developers

How JSON Web Tokens work, structure validation, signature verification, and security best practices

The JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way to securely transmit information between parties as a JSON object. Unlike traditional session-based authentication where the server stores session data, JWTs are stateless — all necessary information is embedded within the token itself, making them ideal for distributed systems, microservices, and modern RESTful APIs.

According to the 2025 Salt Security API Security Report, 87% of organizations use JWT for API authentication, and JWT-based authentication usage has grown 156% since 2020. Major platforms like Google, Microsoft, Auth0, and Firebase rely on JWTs for their authentication flows. The stateless nature of JWTs reduces database queries, improves scalability, and enables cross-domain authentication.

In this comprehensive guide, we explain technically how JWTs work, the structure of each component (header, payload, signature), supported algorithms (HS256, RS256, ES256), security best practices, common vulnerabilities, and how to use our 100% local tool to securely decode, verify, and generate tokens.

🔍 Technical JWT structure: Header, Payload, and Signature

A JWT consists of three Base64Url-encoded parts separated by dots (xxxxx.yyyyy.zzzzz). Each part has a specific purpose:

Part	Purpose	Example content	Encoding	Required
Header	Specifies token type and signature algorithm	{"alg":"HS256","typ":"JWT"}	Base64Url	Yes
Payload	Contains user claims	{"sub":"1234567890","name":"John Doe","iat":1516239022}	Base64Url	Yes
Signature	Cryptographic integrity verification	HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)	Base64Url	Yes

Header: JSON object containing the algorithm (alg) — HS256 (HMAC-SHA256), RS256 (RSA-SHA256), ES256 (ECDSA-SHA256), or none (no security) — and the token type (typ), typically "JWT". Some headers also include kid (key ID) for key rotation or cty (content type) for nested tokens.
Payload: Contains the claims — registered claims (iss, sub, aud, exp, nbf, iat, jti), public claims (custom-defined), and private claims (agreed between parties). The exp (expiration) claim is critical for security; expired tokens are automatically rejected.

🔬 Security note: The JWT payload is encoded, not encrypted. Anyone with the token can base64url-decode it and read its contents. Never store sensitive information like passwords, credit card numbers, or personally identifiable information (PII) in a JWT. Use JWE (JSON Web Encryption) if you need confidentiality.

⚡ JWT signature algorithms: HMAC vs RSA vs ECDSA comparison

Algorithm	Type	Key size	Performance	Security level	Use case	Standard
HS256 / HS384 / HS512	Symmetric (HMAC)	256-512 bits	Fastest (1.0x)	128-256 bits	Single server, trusted environment, internal APIs	RFC 7518
RS256 / RS384 / RS512	Asymmetric (RSA)	2048-4096 bits	Medium (3-5x slower)	112-152 bits	Distributed systems, microservices, external clients	RFC 7518
ES256 / ES384 / ES512	Asymmetric (ECDSA)	256-512 bits	Fast (1.2x)	128-256 bits	Modern systems, resource-constrained devices, IoT	RFC 7518
PS256 / PS384 / PS512	Asymmetric (RSA-PSS)	2048-4096 bits	Medium-slow (4-6x)	128-256 bits	Higher security requirements (future-proof)	RFC 7518
none	No security	N/A	No verification	None	Development/testing only (never in production)	RFC 7519

According to NIST SP 800-57 (2025 revision), RSA with 2048-bit keys and ES256 (ECDSA with P-256 curve) provide 112-128 bits of security, sufficient for most enterprise applications. HS256 is recommended for internal services where the secret can be securely shared; RS256/ES256 are preferred for public APIs where the private key stays on the server and the public key can be distributed to clients.

💡 Production recommendation: Use RS256 or ES256 with a securely stored private key (HSM or secret manager). Avoid HS256 when multiple services need to validate tokens (key distribution problem). Never use the 'none' algorithm in production — it's a critical vulnerability (CWE-345: Insufficient Verification of Data Authenticity).

📋 JWT standard claims (RFC 7519) and validation rules

Claim	Name	Type	Description	Required?	Validation
iss	Issuer	String/URI	Identifies who issued the JWT	Optional	Verify it matches the expected issuer
sub	Subject	String/URI	Identifies the JWT subject (user ID, email)	Optional	Use for authorization
aud	Audience	String/URI or array	Identifies the JWT recipients	Optional	Verify your service is in the audience
exp	Expiration	NumericDate (seconds since epoch)	Time after which the JWT MUST NOT be accepted	Recommended	Reject if current time > exp
nbf	Not Before	NumericDate	Time before which the JWT MUST NOT be accepted	Optional	Reject if current time < nbf
iat	Issued At	NumericDate	Time when the JWT was issued	Recommended	Optional: reject if older than tolerance
jti	JWT ID	String	Unique JWT identifier (prevents replay attacks)	Optional	Verify against used token cache

Our tool automatically validates exp (expiration), nbf (not before), and iat (issued at) claims when you provide the current timestamp. For development and debugging, you can also manually inspect and modify any claim. Real-time JSON syntax validation ensures your header and payload are well-formed before encoding.

⚡ Benchmark: Local JWT processing vs online tools

Tool	Decoding	HS256 Signing	Privacy	Offline capable	Local processing	Secret exposure risk
Our tool (local)	0.01s \| 100% local	0.03s \| 100% local	✅ No external data	✅ Yes (works offline)	✅ 100% frontend (Web Crypto API)	❌ None (secret stays in browser memory)
jwt.io (online)	0.05s + network	0.05s + network	❌ Code loads from server	❌ No (requires internet)	❌ Not verified	⚠️ Secret could be logged
JWT Debugger (online)	0.05s + network	0.05s + network	❌ Tokens sent to servers	❌ No	❌ Not verified	⚠️ Tokens and secrets exposed
CLI tools (jq + openssl)	0.01s	0.02s	✅ Local	✅ Yes	✅ 100% local	❌ None (CLI handles locally)

Our tool uses the Web Crypto API (window.crypto.subtle) — the same cryptographic primitives used by HTTPS and modern browsers — to perform all signing and verification operations locally. No token, secret, or private key ever leaves your browser's memory. This is the only 100% client-side JWT tool that works offline and guarantees your credentials are not exfiltrated to third-party servers.

⚠️ Common JWT vulnerabilities (CWE) and mitigations

Vulnerability	CWE ID	Description	Impact	Mitigation
alg=none attack	CWE-345	Attacker changes alg to 'none' to bypass signature verification	Complete authentication bypass	Never accept 'none' algorithm in production; validate algorithm against whitelist
Key confusion (RS256 to HS256)	CWE-327	Attacker switches from RS256 to HS256 and uses public key as symmetric secret	Token forgery	Always verify algorithm; never mix key types; use kid (key ID) for rotation
Weak HMAC secret (HS256)	CWE-326	Using short or predictable secrets (e.g., 'secret', 'password123')	Token forgery via brute force	Use secrets with >64 bits of entropy (random, >32 characters)
No expiration (exp missing)	CWE-613	Tokens never expire, can be reused indefinitely	Session hijacking	Always set exp claim with reasonable lifetime (15 min to 24 hours)
Information exposure	CWE-200	Storing sensitive data in JWT payload	Data leakage	Never store passwords, credit cards, or PII in JWTs without encryption; use JWE for sensitive data

🔒 Security best practices for JWT implementation: (1) Use short expiration times (15-60 minutes) with refresh tokens; (2) Store JWT in httpOnly cookies (not localStorage) to prevent XSS attacks; (3) Validate algorithm against a strict whitelist; (4) Use versioned keys with kid claim for rotation; (5) Never trust token content before verifying the signature; (6) Implement token revocation (denylist) for high-security scenarios.

🏢 Real-world JWT production use cases

🔐

API Authentication (REST/GraphQL)

Client authenticates → server issues JWT → client sends Authorization: Bearer <token> header on each request. Stateless, scalable to millions of requests. Used by Stripe, GitHub API, Spotify API, and thousands of microservices.

👥

Single Sign-On (SSO) / Federated Identity

Users authenticate once, receive a JWT, and access multiple applications without re-authenticating. OpenID Connect (OIDC) builds on JWT for the identity layer. Used by Google, Microsoft Azure AD, Okta, Auth0.

🔄

Microservices Communication

Internal service A issues JWT → service B validates signature with public key → no central database needed. Ideal for zero-trust architectures. Used by Kubernetes, Docker, and service meshes (Istio, Linkerd).

📱

Mobile App Authentication

Native iOS/Android apps authenticate against backend → JWT stored securely (Keychain/Keystore) → included in each API call. Offline validation possible if public key is cached. Supports millions of concurrent users.

❓ JWT frequently asked questions (Stack Overflow, Reddit, Security.SE)

JWT (JSON Web Token) is the container format. JWS (JSON Web Signature) is a signed JWT — the most common type (HMAC/RSA/ECDSA). JWE (JSON Web Encryption) is an encrypted JWT, where the payload is encrypted for confidentiality. Most APIs use JWS (signed, not encrypted). Our tool handles JWS (signed tokens).

JWTs are stateless, so there's no built-in revocation mechanism. Common approaches: (1) Maintain a denylist of revoked token IDs (jti claim) in a fast cache (Redis). (2) Use short expiration times (5-15 min) plus refresh tokens. (3) Change the user's password or rotate signing keys. For high-security applications, keep a session database, negating the stateless advantage.

Recommended: secure httpOnly cookies (prevents XSS, but vulnerable to CSRF — use SameSite=Strict). Not recommended: localStorage (vulnerable to XSS; any script can read tokens). For SPAs without server-side rendering, use memory (React/Vuex state) with silent renewal. Our tool is for debugging/development, not for production token management.

Yes, but with caveats. JWT size grows with claims (might exceed browser's 4KB cookie limit). Refresh token rotation is complex. Many recommend traditional session cookies for browser applications and JWTs for API-to-API communication. Evaluate your threat model: JWTs excel in distributed/stateless systems, sessions are simpler for monolithic applications without mobile clients.

Ideally less than 1KB (fits in HTTP headers without fragmentation). Each claim adds size. A typical JWT with 5-8 claims occupies 200-400 bytes. Large JWTs (>8KB) cause issues with HTTP header size limits (8KB on many servers). If you need more data, consider reference tokens (store data on server, pass an opaque identifier).

Yes, if the secret is strong (≥256 bits, randomly generated, stored in a secret manager) and the internal network is trusted. HS256 is faster than RSA/ECDSA and simpler. For zero-trust environments or external clients, use RS256/ES256 so the private key never leaves the authentication server. Never hardcode secrets in source code.

⚠️ Honest limitations of our JWT tool

No JWE (encrypted JWT) support. Our tool only handles JWS (signed tokens). For encrypted JWTs, use a JWE-specialized tool.
No automatic key retrieval (JWKS). You must provide the secret (HS256) or public/private key (RS256/ES256) manually for signature verification. Automatic retrieval from JWKS endpoints is not supported for security reasons.
Limited to algorithms supported by Web Crypto API. Supports HS256/384/512, RS256/384/512 (PKCS#1 v1.5), and ES256/384/512 (ECDSA). Algorithms like EdDSA (Ed25519) or PS256 (RSA-PSS) are not yet supported in all browsers.
No support for nested JWTs (JWT inside another JWT). To debug nested tokens, decode the outer token, then paste the inner token manually for separate decoding.
No X.509 certificate-based token generation. For RS256/ES256, you must provide the private key in PEM format (PKCS#8). Certificate chains are not automatically extracted.

🔧 2026-2027 Roadmap: (1) JWKS endpoint integration for automatic public key retrieval, (2) EdDSA (Ed25519, Ed448) support, (3) Batch validation of multiple JWTs, (4) JWT fuzzing for security testing, (5) Attack simulation (alg=none, key confusion) for educational purposes. All features will remain 100% local and private.

🔐 Why local processing matters: Security comparison

When you use online JWT debuggers (including the official jwt.io, which runs code loaded from the server), your tokens, secrets, and private keys are sent to third-party servers. These servers could log your data, expose it through monitoring tools, or be compromised. In security-critical environments (FinTech, healthcare, government, military), this is unacceptable.

Our approach: All cryptographic operations use Web Crypto API, which leverages the browser's hardware-accelerated native cryptography. The secret or private key never leaves your browser's memory — not even over localhost. The tool also works completely offline (after initial load).
Alternative approach (jwt.io): Code runs in your browser but loads from a server each visit. Although libraries are open source, nothing prevents your secret from being logged in a future update. You have no privacy guarantee.
Risk assessment: For production secrets (HS256 secret, RS256 private key), never paste them into any online tool. If an attacker obtains your secret, they can forge any token — complete authentication bypass. Our local tool eliminates this risk entirely.

✅ Security guarantee: No token, no secret, no private key, no sensitive data ever leaves your browser. All processing uses window.crypto.subtle, the same standard that powers HTTPS and modern security. Use it confidently even for highly secret API keys and production credentials.

📝 Quick reference: When to use each JWT algorithm

✅

Use HS256 (HMAC) when:

✅ Single authentication server ✅ Trusted internal network ✅ Need maximum performance (low latency) ✅ Simple key management (shared secret) ✅ No third-party token validation

✅

Use RS256 or ES256 (RSA/ECDSA) when:

✅ Multiple microservices validate tokens ✅ External clients need public key ✅ Zero-trust architecture ✅ Need key rotation without downtime ✅ Compliance requires separate private key storage

❌

Avoid the 'none' algorithm:

❌ NEVER in production ❌ Local testing only ❌ Disable it in your JWT library ❌ CVE-2015-9235 (alg=none vulnerability)

JWT is a powerful tool for modern authentication, but with great power comes great responsibility. The most common vulnerabilities aren't in the JWT specification — they're in flawed implementations: weak secrets, algorithm confusion attacks, missing expiration validation, and trusting tokens before verifying the signature. Test, audit, validate. Security is a process, not a product.

— Based on: RFC 7519 (JWT), RFC 7518 (JWA), NIST SP 800-57 (Key Management), OWASP JWT Cheatsheet (2025), CWE Top 25 (2025)

Completely free

No registration

No external servers

Your security is our priority

100% local processing

Comments

🔒 100% local processing · no token leaves your browser