JWT Decoder Online
Decode JWT tokens in your browser — no data sent to any server.
Why use it
Debug JWT tokens instantly
100% private
Decoding happens in your browser. Your token never leaves your device.
Instant
Real-time decoding as you type. No buttons, no waiting.
Formatted JSON
Header and payload shown as readable JSON with proper syntax highlighting.
All JWT types supported
Works with HS256, RS256, ES256, and any algorithm in the JOSE standard.
How it works
Three steps, no hassle
Paste your JWT token
Copy and paste any JWT into the input field. The format is three dot-separated parts: header.payload.signature.
Instant decoding
The header and payload are decoded from Base64URL and displayed as formatted JSON. See the algorithm type, issuer, expiration, and all claims.
Analyze the data
Review each payload field: iss (issuer), sub (subject), exp (expiration), iat (issued at), aud (audience), and any custom claims.
FAQ
Got questions?
JWT (JSON Web Token) is an open standard (RFC 7519) that defines a compact, self-contained way to transmit information between parties as a JSON object. The token is digitally signed, allowing its authenticity to be verified. It is widely used for authentication and authorization in REST APIs and modern web applications.
When a user logs in, the server creates a JWT signed with a secret key (HS256) or private key (RS256) and sends it to the client. The client stores the token (typically in memory or localStorage) and includes it in every request as 'Authorization: Bearer <token>'. The server verifies the token's signature without querying a database, making JWT a stateless authentication mechanism that scales well across distributed systems.
A JWT is signed, not encrypted. This means anyone can decode the payload and read its contents — so never include passwords, credit cards, or sensitive data in the payload. The signature guarantees integrity (nobody can modify the token without invalidating it) but not confidentiality. If you need to encrypt the content, use JWE (JSON Web Encryption).
Claims are statements about the token's subject. Registered claims (RFC 7519) include: iss (issuer), sub (subject), exp (expiration, Unix timestamp), iat (issued at), aud (audience), nbf (not before), and jti (JWT ID). Beyond these, you can include any custom claims your application needs.
Not without invalidating it. If you modify any part of the header or payload and don't have the secret key to re-sign it, the resulting signature will be wrong and the server will reject the token. However, known vulnerabilities exist: the 'alg:none' attack (where the header declares no algorithm to bypass verification) and RS256/HS256 algorithm confusion. Always use a well-maintained JWT library that explicitly handles these cases.
Session cookies store an ID on the server (stateful), while JWT contains all information in the token itself (stateless). JWT scales better in distributed architectures and microservices because it doesn't require shared sessions. However, JWT has drawbacks: you cannot revoke a token before it expires without additional infrastructure (blacklist), and if the token is stolen it remains valid until expiry. For most traditional web applications, httpOnly session cookies remain the more secure default choice.
JWT: history, technical structure, and security in depth
JSON Web Token was standardized by the IETF in May 2015 as RFC 7519, part of the JOSE (JSON Object Signing and Encryption) framework. JOSE also includes JWS (JSON Web Signature, RFC 7515), JWE (JSON Web Encryption, RFC 7516), JWK (JSON Web Key, RFC 7517), and JWA (JSON Web Algorithms, RFC 7518). Work on the standard began in 2011, led by Mike Jones (Microsoft), John Bradley, and Nat Sakimura. Before JWT, developers relied on SAML (Security Assertion Markup Language), an XML-based standard considerably more verbose and complex.
A JWT consists of three Base64URL-encoded parts separated by dots. Base64URL differs from standard Base64 by replacing '+' with '-' and '/' with '_', omitting '=' padding, making it safe for use in URLs and HTTP headers without additional encoding. The header specifies the token type ('typ': 'JWT') and signing algorithm ('alg'). The most common algorithms are HS256 (HMAC-SHA256, symmetric key), RS256 (RSA-SHA256, asymmetric key), ES256 (ECDSA-SHA256, P-256 curve), and the dangerous 'none' (no signature, which must never be accepted in production).
The most critical JWT vulnerabilities are well documented in OWASP API Security Top 10. The 'alg:none' vulnerability (CVE-2015-9235 in several libraries) allows an attacker to modify the header to declare no signature is needed, so the server accepts any arbitrary payload if the library doesn't explicitly validate the algorithm. RS256/HS256 algorithm confusion occurs when a server configured for RS256 also accepts HS256: the attacker can use the RSA public key (which is, by definition, public) as an HMAC secret key to sign fraudulent tokens. Modern libraries like jose, python-jose, and jsonwebtoken solve these by requiring the algorithm to be specified explicitly when verifying.