How JWT Tokens Work
JSON Web Tokens (JWTs) are an open standard for securely transmitting information between parties as a compact, self-contained JSON object. Unlike traditional session-based authentication where the server stores session state, JWTs carry all necessary information within the token itself, making them ideal for stateless architectures, microservices, and single-page applications.
The authentication flow typically works as follows: a user submits credentials to the server, which validates them and returns a signed JWT. The client stores this token (usually in memory or an HTTP-only cookie) and includes it in the Authorization header of subsequent API requests. The server verifies the token's signature and extracts the claims without needing to query a database or session store.
JWTs are signed using either a symmetric algorithm (HMAC with SHA-256, where both parties share a secret) or an asymmetric algorithm (RSA or ECDSA, where the server signs with a private key and clients verify with the corresponding public key). The choice depends on your architecture — symmetric is simpler for monolithic apps, while asymmetric is preferred when multiple services need to verify tokens independently.
Parts of a JWT
Every JWT consists of three base64url-encoded segments separated by dots:
- Header: A JSON object that declares the token type (
"typ": "JWT") and the signing algorithm ("alg": "HS256","RS256", etc.). The header tells the receiving party how to verify the signature. - Payload: A JSON object containing claims — statements about the user and additional metadata. Standard registered claims include
iss(issuer),sub(subject),aud(audience),exp(expiration),iat(issued at), andnbf(not before). You can also include custom claims like user roles, permissions, or tenant IDs. - Signature: Created by encoding the header and payload, concatenating them with a dot, and signing the result with the specified algorithm and a secret or private key. The signature ensures data integrity — if anyone modifies the header or payload, the signature becomes invalid.
Our decoder splits the token at the dots, base64url-decodes each segment, and presents the header and payload as formatted JSON. Timestamps like exp and iat are automatically converted to human-readable dates for quick inspection.
JWT Signing Algorithms Explained
The alg field in the JWT header specifies which cryptographic algorithm was used to sign the token. Choosing the right algorithm depends on your architecture and security requirements.
HMAC using SHA-256. Both parties share the same secret key. Simple and fast, but the secret must be distributed securely. Best for server-to-server communication where both sides are trusted.
WikipediaRSA Signature with SHA-256. Uses a private key to sign and a public key to verify. The public key can be freely shared. Used by most OAuth 2.0 and OpenID Connect providers (Google, Auth0, Okta).
WikipediaECDSA using P-256 curve and SHA-256. Smaller keys and signatures than RSA with equivalent security. Gaining popularity for modern applications. Used by Apple Sign-In and WebAuthn.
WikipediaRSA-PSS with SHA-256. A probabilistic variant of RSA that provides stronger security guarantees than PKCS#1 v1.5 (RS256). Recommended when RSA is required and forward-looking security matters.
WikipediaEdwards-curve Digital Signature Algorithm (Ed25519 or Ed448). Fastest of all asymmetric algorithms with excellent security. Increasingly used in modern protocols and recommended for new implementations.
Wikipedia Unsecured JWT — no signature at all. Should never be accepted in production. A common attack vector where an attacker modifies the payload and sets alg: "none" to bypass verification.
JWT Security Best Practices
While JWTs are powerful, improper use can introduce security vulnerabilities. Follow these best practices to keep your implementation secure:
- Always verify signatures server-side. Never trust a JWT without validating its signature. Client-side decoding is useful for inspection, but authorization decisions must happen on the server.
- Set short expiration times. Use the
expclaim to limit token lifetime. Short-lived access tokens (5-15 minutes) combined with longer-lived refresh tokens reduce the damage window if a token is compromised. - Avoid storing sensitive data in the payload. JWT payloads are encoded, not encrypted. Anyone with the token can decode and read the claims. Never include passwords, credit card numbers, or other secrets in a JWT.
- Use strong signing keys. For HMAC algorithms, use a cryptographically random secret of at least 256 bits. For RSA, use a minimum key size of 2048 bits. Rotate keys periodically.
- Validate all claims. Beyond the signature, verify the
iss,aud, andexpclaims to ensure the token was issued by a trusted source, is intended for your application, and has not expired.
Frequently Asked Questions
What is a JWT token?+
A JSON Web Token (JWT) is a compact, URL-safe token format defined by RFC 7519. It is used to securely transmit claims between two parties — typically a client and a server. JWTs are widely used for authentication, authorization, and information exchange in web applications and APIs.
Is it safe to decode a JWT in the browser?+
Decoding a JWT simply means base64-decoding its header and payload — it does not require a secret key. This is safe because the payload of a JWT is not encrypted; it is only signed. Our decoder runs entirely in your browser and never transmits your token to any server. However, you should never share your JWTs publicly, as they may contain sensitive claims.
What is the difference between decoding and verifying a JWT?+
Decoding a JWT extracts the header and payload by base64-decoding the token segments. This reveals the claims but does not confirm authenticity. Verifying a JWT checks the cryptographic signature against a secret key (HMAC) or public key (RSA/ECDSA) to confirm that the token was issued by a trusted party and has not been tampered with. Our tool decodes tokens for inspection; signature verification requires server-side code with access to the signing key.
Why does my JWT have three parts separated by dots?+
A JWT consists of three base64url-encoded segments separated by periods: the header (specifying the algorithm and token type), the payload (containing claims like user ID, roles, and expiration), and the signature (a cryptographic hash that ensures the token has not been modified). Each part serves a distinct purpose in the token lifecycle.
How do I check if a JWT has expired?+
The payload of a JWT typically contains an "exp" (expiration) claim, which is a Unix timestamp indicating when the token becomes invalid. Our decoder automatically detects and highlights the expiration time, converting it to a human-readable date so you can instantly see whether the token is still valid or has expired.
Built With
This tool uses no external JWT libraries — just pure JavaScript base64url decoding.
Best JWT Libraries by Language
The recommended JWT library for each major language and framework. All support HS256, RS256, and ES256 at minimum.