JWT Decoder & Encoder - JSON Web Token Parser

Decoding Options

Pretty print JSON

Show readable timestamps

Encoding Algorithm

Algorithm:

Secret Key:

Error message

JWT Token 0 characters

Decoded JWT 0 characters

Copied!

JWT Structure Analysis

Payload

{"sub": "1234567890", "name": "John Doe", "iat": 1516239022}

Claims & Data

Signature

SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Verification

Token Status:

Valid Format

Algorithm:

HS256

Expiration:

Not specified

What is JWT (JSON Web Token)?

JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. JWTs are widely used for authentication and information exchange in modern web applications, APIs, and microservices architectures.

JWT Structure

A JWT consists of three parts separated by dots (.), which are:

1. Header

The header typically consists of two parts: the type of token (JWT) and the signing algorithm being used, such as HMAC SHA256 or RSA. The header is Base64Url encoded to form the first part of the JWT.

{
  "alg": "HS256",
  "typ": "JWT"
}

2. Payload

The payload contains the claims, which are statements about an entity (typically, the user) and additional data. There are three types of claims:

Registered claims: Predefined claims like iss (issuer), exp (expiration), sub (subject), aud (audience)
Public claims: Claims defined at will by those using JWTs
Private claims: Custom claims created to share information between parties

{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022,
  "exp": 1516242622
}

3. Signature

The signature is used to verify that the sender of the JWT is who it says it is and to ensure that the message wasn't changed along the way. The signature is created by encoding the header and payload using Base64url and then signing the result using the algorithm specified in the header.

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret
)

Common JWT Claims

Claim	Name	Description	Type
`iss`	Issuer	Identifies the principal that issued the JWT	String
`sub`	Subject	Identifies the principal that is the subject of the JWT	String
`aud`	Audience	Identifies the recipients that the JWT is intended for	String or Array
`exp`	Expiration Time	Unix timestamp after which the JWT expires	Number
`nbf`	Not Before	Unix timestamp before which the JWT is not valid	Number
`iat`	Issued At	Unix timestamp when the JWT was issued	Number
`jti`	JWT ID	Unique identifier for the JWT	String

JWT Algorithms

JWTs can be signed using different algorithms:

HMAC (Symmetric)

HS256: HMAC using SHA-256 hash algorithm
HS384: HMAC using SHA-384 hash algorithm
HS512: HMAC using SHA-512 hash algorithm

RSA (Asymmetric)

RS256: RSASSA-PKCS1-v1_5 using SHA-256
RS384: RSASSA-PKCS1-v1_5 using SHA-384
RS512: RSASSA-PKCS1-v1_5 using SHA-512

ECDSA (Asymmetric)

ES256: ECDSA using P-256 and SHA-256
ES384: ECDSA using P-384 and SHA-384
ES512: ECDSA using P-521 and SHA-512

When to Use JWTs

JWTs are useful in several scenarios:

Authentication

Once a user is logged in, each subsequent request includes the JWT, allowing the user to access routes, services, and resources permitted with that token. Single Sign On is a feature that widely uses JWT due to its small overhead and ability to be easily used across different domains.

Information Exchange

JWTs are a good way of securely transmitting information between parties. Because JWTs can be signed, you can be sure the senders are who they say they are. Additionally, the signature is calculated using the header and payload, so you can verify that the content hasn't been tampered with.

API Authorization

JWTs are commonly used for API authorization. After a user authenticates, the JWT can contain the necessary permissions and user information, reducing the need for additional database queries.

JWT Best Practices

Keep it small: JWTs are sent with every request, so keep the payload minimal
Use HTTPS: Always transmit JWTs over secure connections
Set expiration: Always include an 'exp' claim to limit token lifetime
Store securely: Never store JWTs in localStorage on the client side for sensitive applications
Validate thoroughly: Always verify the signature, expiration, and claims
Use appropriate algorithms: Choose the right algorithm for your security requirements

Security Considerations

JWTs are not encrypted: The payload is only Base64 encoded, not encrypted. Don't include sensitive information unless using JWE
Algorithm confusion attacks: Always validate the algorithm in the header
Key management: Protect your signing keys and rotate them regularly
Token revocation: JWTs cannot be easily revoked. Consider using short expiration times
None algorithm: Never accept 'none' algorithm in production unless specifically intended

JWT vs Sessions

Aspect	JWT	Sessions
Storage	Client-side (stateless)	Server-side (stateful)
Scalability	High (no server storage)	Lower (session storage needed)
Performance	Fast (no database lookup)	Slower (database/cache lookup)
Security	Good (signed, not encrypted)	Excellent (server-controlled)
Revocation	Difficult	Easy (delete session)
Cross-domain	Excellent	Limited
Payload Size	Larger (all data in token)	Smaller (just session ID)

Conclusion

JWTs provide a compact, URL-safe way to represent claims to be transferred between two parties. They're particularly useful for authentication and information exchange in distributed systems. However, they should be used thoughtfully, considering security implications and use case requirements. Always validate JWTs properly and follow security best practices to ensure robust authentication systems.

Key Takeaways

JWTs consist of three Base64Url encoded parts: header, payload, and signature
They're self-contained and don't require server-side session storage
Perfect for stateless authentication and information exchange
Always validate the signature, expiration, and other claims
Consider security implications and use HTTPS for transmission
Choose appropriate algorithms and manage keys securely