Formatter Validator Minifier Escape / Unescape JSON ↔ String JSON ↔ YAML JSON → CSV NDJSON / JSON Lines JSON → Types JSON ↔ XML JSON Diff JSON Patch Canonicalize (RFC 8785) Schema Validator Schema Generator JSONPath Tester JWT Decoder JSON Errors Schemas More Tools
JWT decode · Header · Payload · Signature · Expiration check

JWT Decoder Online

Decode JSON Web Tokens to inspect the header and payload. Detects expired tokens, displays issuance and expiration times in human-readable form. 100% browser-based — your tokens never leave your device.

Encoded JWT
🎯 Header

    

    

      
📦 Payload

      

    

    

      
🔏 Signature

      

    

  



  What is a JSON Web Token (JWT)?
  
What is a JSON Web Token (JWT)?

  

    
A JSON Web Token (JWT) is a compact, URL-safe way to transmit claims between two parties. JWTs are everywhere in modern web authentication: OAuth flows, single sign-on (SSO), API authentication, and microservice communication all commonly use them.



A JWT consists of three parts joined by dots: header.payload.signature. The header and payload are base64url-encoded JSON. The signature is a cryptographic signature over the header and payload, using either an HMAC secret (symmetric) or an RSA/ECDSA key (asymmetric).



JWTs are not encrypted by default — they're encoded. Anyone with the token can decode and read the contents. The signature only prevents tampering: changing the payload invalidates the signature, but the original payload is readable. This is a common source of security misunderstanding.

  






  How to decode a JWT online
  
How to decode a JWT online

  

    
    
  
  1. Paste your JWT into the input field. It should look like three base64-encoded strings joined by dots.
    2. 
  
  2. The decoder runs automatically. The header and payload appear immediately, parsed and pretty-printed.
    3. 
  
  3. Check the status. The tool detects standard claims and displays their values in human-readable form — including a warning if the token has expired.
    4. 




The signature is shown but not verified. Verification requires the secret key (for HMAC) or public key (for RSA/ECDSA), which you should never paste into a website. To verify signatures, use a server-side library or self-hosted tool.

  






  Understanding JWT structure
  
Understanding JWT structure

  

    

  

    
1 Header

    
Tiny JSON describing the token type (typ: "JWT") and the signing algorithm (alg). Common algorithms: HS256 (HMAC with SHA-256), RS256 (RSA with SHA-256), ES256 (ECDSA).

  

  

    
2 Payload

    
The claims — facts the token asserts. Standard claims (defined in RFC 7519): sub (subject/user ID), iss (issuer), aud (audience), exp (expiration), iat (issued at), nbf (not before), jti (token ID). Custom claims can be added freely.

  

  

    
3 Signature

    
Cryptographic proof the token wasn't modified after being issued. For HMAC: HMACSHA256(base64url(header) + "." + base64url(payload), secret). For RSA/ECDSA: a signature using the private key. Verifying the signature requires the matching secret or public key.

  



  






  JWT security: what you need to know
  
JWT security: what you need to know

  

    
    
  
  • JWTs are not encrypted. The payload is base64-encoded, which is reversible. Never put secrets, passwords, or sensitive PII in a JWT payload. If you need encryption, use JWE (JSON Web Encryption) instead.
    • 
  
  • Check exp on every use. JWT libraries usually do this automatically, but if you're hand-rolling validation, expiration is the most commonly missed check.
    • 
  
  • Validate alg on the server. A well-known vulnerability: an attacker sets alg: "none" and supplies an unsigned token. The server, if not careful, accepts it. Always validate the algorithm matches what your application expects.
    • 
  
  • Use strong secrets. For HMAC-signed tokens, the secret should be at least 256 bits of randomness. Weak secrets can be cracked offline once an attacker has any valid token.
    • 
  
  • Rotate keys periodically. Build in key rotation from day one. JWT headers can include a kid (key ID) that identifies which signing key was used.
    • 
  
  • Short-lived tokens with refresh. Best practice is to issue short-lived access tokens (5-15 minutes) plus long-lived refresh tokens stored more securely. This limits blast radius if a token leaks.
    • 


  





  Common questions
  
FAQ — Jwt Decoder

  

    
Is a JWT encrypted?

    
No. JWT payloads are base64-encoded, which is just an encoding — fully reversible by anyone. The signature prevents tampering, but the content is readable. If you need actual encryption, use JWE (JSON Web Encryption). Never store passwords, credit card numbers, or other secrets in a JWT payload.

  

  

    
Why isn't the signature verified by this tool?

    
Signature verification requires the secret key (for HMAC algorithms like HS256) or the public key (for RSA/ECDSA). Asking users to paste their server's secret key into a web page would be a serious security mistake — anyone watching the network or with access to the browser could capture it. To verify signatures, use a server-side library or run a verifier on your own machine.

  

  

    
How do I tell if a JWT is expired?

    
Look for the exp claim in the payload — it's a Unix timestamp (seconds since 1970-01-01 UTC). Compare it to the current time. Our decoder does this automatically and shows EXPIRED in red if applicable. Note: a future exp doesn't mean a token is valid — it just means it hasn't expired yet. You still need to verify the signature on the server.

  

  

    
What does the alg field mean?

    
It specifies the signing algorithm. Common values: HS256 (HMAC with SHA-256, symmetric, used when the same party signs and verifies), RS256 (RSA with SHA-256, asymmetric, used when the verifier doesn't have the signing key — common for SSO), ES256 (ECDSA with SHA-256, asymmetric and faster than RSA). Less common: HS384, HS512, RS384, RS512, PS256, EdDSA.

  

  

    
What's the maximum length of a JWT?

    
Technically unlimited, but most servers cap HTTP headers at 8 KB. JWTs over 4 KB are usually a code smell — JWTs should carry identity and minimal claims, not entire user records. If you're approaching the size limit, you're probably putting too much in the token.

  

  

    
Where should I store JWTs in a browser?

    
Depends on your threat model. localStorage is convenient but vulnerable to XSS. httpOnly cookies are safer against XSS but vulnerable to CSRF without proper CSRF tokens. Modern best practice: short-lived access tokens in memory (lost on tab close, refreshed via a long-lived httpOnly refresh token cookie). Never store JWTs in URL query parameters — they get logged everywhere.

  

  

    
Why are my JWTs so long?

    
JWTs include three base64-encoded sections. Each section is roughly 33% larger than its raw form due to base64. Common reasons for excessive length: (1) too many claims in the payload (slim it down), (2) RSA-signed tokens (RS256 signatures are 256+ bytes — switch to ES256 for shorter signatures), (3) including long lists or nested objects in claims.

  

  

    
Can a JWT be revoked before its exp?

    
Not natively. JWTs are stateless — once issued, they're valid until they expire. To support revocation, you either: (1) keep an in-memory blocklist of revoked token IDs (jti); (2) use short-lived tokens (5-15 minutes) so revocation propagates fast; (3) check a database on every request (which defeats the stateless benefit). Most production systems combine #2 and #1.

  

  

    
What's the difference between JWT and OAuth?

    
They're complementary, not competing. OAuth is a framework for authorization flows (how a client gets a token from an authorization server). JWT is a token format (how to encode the token). Most modern OAuth implementations issue JWTs as the access token format, but you can use OAuth with non-JWT tokens (opaque strings backed by a database) and you can use JWTs without OAuth (for example, in a custom session system).

  

  

    
Is this tool similar to jwt.io?

    
Functionally similar — both decode JWTs and display the parts. Two important differences: (1) jwt.io supports signature verification if you paste your secret key (which is convenient but security-questionable for production secrets); we deliberately don't. (2) Our tool processes everything in your browser; jwt.io's verification feature requires submitting your secret to their servers. For decoding alone, both are equivalent in privacy.

  







  Related
  
Where to go next