Decoded entirely in your browser. Your tokens are never sent to our servers.
| Claim | Value | Description |
|---|
A JSON Web Token (JWT) is a compact, URL-safe token format defined in RFC 7519. JWTs are widely used for authentication and authorization in web applications, APIs, and microservices. A JWT allows claims (pieces of information) to be securely transmitted between two parties as a digitally signed JSON object.
JWTs are self-contained: they carry all the information needed to authenticate a user or authorize a request, eliminating the need for server-side session storage. This makes them ideal for stateless architectures, single sign-on (SSO), and distributed systems.
Every JWT consists of three parts separated by dots (.): the header, payload, and signature. Each part is Base64URL-encoded. You can use our Base64 Encoder & Decoder to inspect the raw Base64 values.
The header typically contains two fields: alg (the signing algorithm, such as HS256 or RS256) and typ (the token type, usually "JWT"). The header tells the verifier which algorithm was used to create the signature.
The payload contains the claims — statements about the user and additional metadata. Claims can be registered (standardized names like sub and exp), public (defined in the IANA JSON Web Token Claims registry), or private (custom claims agreed upon between parties).
The payload is Base64URL-encoded, not encrypted. Anyone with access to the token can decode and read the payload. Never store sensitive information like passwords or API keys in a JWT.
The signature is created by taking the encoded header, the encoded payload, a secret or private key, and the algorithm specified in the header. The signature ensures that the token has not been altered. For HMAC algorithms, the same secret is used for signing and verification. For RSA and ECDSA algorithms, a private key signs the token and a public key verifies it.
The following registered claims are defined in RFC 7519. They are optional but recommended for interoperability between JWT implementations.
| Claim | Full Name | Description |
|---|---|---|
| iss | Issuer | Identifies the principal that issued the JWT. Typically a URL or application identifier. |
| sub | Subject | Identifies the subject of the JWT, usually the user ID. |
| aud | Audience | Identifies the recipients the JWT is intended for. Can be a string or array of strings. |
| exp | Expiration Time | The time after which the JWT must not be accepted. Expressed as a Unix timestamp (seconds since epoch). |
| nbf | Not Before | The time before which the JWT must not be accepted. Prevents tokens from being used prematurely. |
| iat | Issued At | The time at which the JWT was issued. Useful for determining the age of the token. |
| jti | JWT ID | A unique identifier for the JWT. Can be used to prevent token replay attacks. |
JWTs support multiple signing algorithms, each with different security properties and use cases.
HMAC algorithms use a single shared secret for both signing and verification. They are fast and simple, making them a good choice when the same party both creates and verifies tokens. However, the secret must be shared between all parties, which can be a security concern in distributed systems.
RSA algorithms use an asymmetric key pair: a private key for signing and a public key for verification. This means the verifier cannot forge tokens. RS256 is the most widely used algorithm for JWTs in production and is the default in many OAuth 2.0 and OpenID Connect implementations.
ECDSA (Elliptic Curve Digital Signature Algorithm) offers the same asymmetric benefits as RSA but with shorter key sizes and faster operations. ES256 uses the P-256 curve and produces 64-byte signatures, compared to 256-byte signatures for RS256. ECDSA is increasingly preferred for new implementations due to its efficiency.
RSA-PSS is a more modern RSA padding scheme that provides a tighter security proof than the PKCS#1 v1.5 padding used by RS256. It is recommended over RS256 for new systems where RSA is required.
exp claim. Tokens that never expire are a security risk if compromised.iss and aud claims to ensure the token was issued by a trusted authority and intended for your application.kid (Key ID) header parameter to support key rotation without downtime.Decoding a JWT means converting the Base64URL-encoded header and payload back into readable JSON. Anyone can decode a JWT without a secret key. Verifying a JWT means checking that the signature is valid using the secret key (for HMAC) or public key (for RSA/ECDSA), confirming the token has not been tampered with.
It depends on the tool. This JWT decoder processes everything entirely in your browser using client-side JavaScript. Your tokens are never sent to any server. However, you should avoid pasting production tokens into tools that send data to a backend. Always check whether a tool is client-side only before pasting sensitive tokens.
Yes. The header and payload of a JWT are only Base64URL-encoded, not encrypted. Anyone with access to the token can decode and read the contents. This is by design — JWTs are meant to be verifiable, not secret. Never store sensitive information like passwords or secrets in a JWT payload.
Registered claims are predefined claim names defined in RFC 7519. They include: iss (issuer), sub (subject), aud (audience), exp (expiration time), nbf (not before), iat (issued at), and jti (JWT ID). These claims are not mandatory but are recommended for interoperability.
HS256 (HMAC with SHA-256) uses a single shared secret key for both signing and verification — it is a symmetric algorithm. RS256 (RSA with SHA-256) uses a private key for signing and a separate public key for verification — it is an asymmetric algorithm. RS256 is preferred when the verifier should not be able to create tokens, such as in distributed systems or third-party integrations.
In JWT authentication, the server creates a signed token containing user claims (like user ID and roles) after successful login. The client stores this token and sends it with subsequent requests, typically in the Authorization header as Bearer <token>. The server verifies the signature and extracts the claims without needing to query a database, making it stateless and scalable.