JWT Decoder

Decode and inspect JSON Web Tokens instantly. View the header, payload, registered claims with expiry analysis, and algorithm detection -- all client-side. Your token never leaves your browser.

How It Works

⚡

Instant Decoding

Paste any JWT and instantly see the decoded header and payload with syntax-highlighted JSON. Decoding happens entirely in your browser -- no server calls, no data stored.

🔍

Claims Analysis

Automatically identifies all seven registered JWT claims (iss, sub, aud, exp, nbf, iat, jti) with human-readable labels and values. Custom claims are listed separately for clarity.

⏰

Expiry Check

Instantly see whether your token is expired or still valid. Unix timestamps for exp, iat, and nbf are converted to human-readable dates with relative time (e.g., "expired 2 hours ago").

🔐

Algorithm Detection

Detects and displays the signing algorithm from the header, supporting HS256, RS256, ES256, PS256, EdDSA, and more. Warns about the insecure "none" algorithm.

Understanding JSON Web Tokens

JSON Web Tokens (JWTs) are a compact, URL-safe way to represent claims between two parties. Defined in RFC 7519, JWTs are widely used for authentication, authorization, and information exchange in modern web applications and APIs. A JWT consists of three Base64URL-encoded parts separated by dots: the header, payload, and signature.

JWT Structure

header.payload.signature

The header typically contains the signing algorithm (e.g., HS256, RS256) and token type (JWT). The payload contains the claims -- statements about the user and additional metadata. The signature is used to verify the token has not been tampered with.

How to Use This Tool

Paste your JWT into the text area above and the tool will instantly decode it. You will see the header and payload as formatted JSON with syntax highlighting, a detailed claims analysis with human-readable dates for time-based claims, expiry status, and information about the signing algorithm. Click the example buttons to see how different types of tokens are decoded.

Common Use Cases

Frequently Asked Questions

What is a JSON Web Token (JWT)? ▼
A JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact, self-contained way to securely transmit information between parties as a JSON object. JWTs are digitally signed using a secret (HMAC) or a public/private key pair (RSA or ECDSA), which means the information can be verified and trusted. JWTs are commonly used for authentication -- after a user logs in, each subsequent request includes the JWT, allowing the user to access routes, services, and resources permitted by that token.
What are the three parts of a JWT? ▼
A JWT consists of three parts separated by dots: the Header, Payload, and Signature. The Header typically contains the token type ("JWT") and the signing algorithm (e.g., "HS256" or "RS256"). The Payload contains the claims, which are statements about the user and additional data. The Signature is created by encoding the header and payload with Base64URL, concatenating them with a dot, and then signing the result using the algorithm specified in the header along with a secret or private key. The three parts are each Base64URL-encoded and joined with dots to form the complete token string.
What are registered claims in a JWT? ▼
Registered claims are a set of predefined claims defined in the JWT specification (RFC 7519) that provide useful, interoperable information. They include: iss (Issuer) -- who issued the token; sub (Subject) -- the entity the token is about; aud (Audience) -- the intended recipient; exp (Expiration Time) -- when the token expires as a Unix timestamp; nbf (Not Before) -- the earliest time the token can be used; iat (Issued At) -- when the token was created; and jti (JWT ID) -- a unique identifier for the token. None of these claims are mandatory, but they are recommended to ensure interoperability between different JWT implementations.
Is it safe to decode JWTs in the browser? ▼
Yes, decoding a JWT in the browser is safe because JWTs are not encrypted by default -- they are only Base64URL-encoded. Anyone who has the token can decode and read the header and payload. This is by design: the security of a JWT comes from the signature, which prevents tampering, not from hiding the contents. This is also why you should never put sensitive information (passwords, credit card numbers) in a JWT payload. Our tool decodes tokens entirely client-side in your browser. No data is sent to any server, and nothing is stored or logged.
Can this tool verify JWT signatures? ▼
This tool decodes and inspects JWTs but does not verify signatures. Signature verification requires the secret key (for HMAC algorithms) or the public key (for RSA/ECDSA algorithms), which should be kept secure and not shared with client-side tools. The tool detects the signing algorithm from the header and displays it, but the actual cryptographic verification should be performed server-side in your application using a trusted JWT library like jsonwebtoken (Node.js), PyJWT (Python), or java-jwt (Java).
What does "exp" mean in a JWT? ▼
The exp (Expiration Time) claim identifies the expiration time after which the JWT must not be accepted for processing. It is represented as a Unix timestamp (the number of seconds since January 1, 1970 UTC). For example, a value of 1700000000 corresponds to November 14, 2023. Our decoder converts this timestamp to a human-readable date and tells you whether the token is currently expired or still valid, along with how long ago it expired or how much time remains before expiration.
What JWT algorithms are supported? ▼
Our decoder recognizes all standard JWT signing algorithms: HMAC-based algorithms (HS256, HS384, HS512) which use a shared secret; RSA-based algorithms (RS256, RS384, RS512) which use public/private key pairs; ECDSA algorithms (ES256, ES384, ES512) which use elliptic curve cryptography; RSA-PSS algorithms (PS256, PS384, PS512); EdDSA for Edwards-curve signatures; and the "none" algorithm which indicates an unsigned token. The tool displays the algorithm name along with a description and warns about security implications when the "none" algorithm is detected.
Why should I not store sensitive data in a JWT? ▼
JWTs are signed but not encrypted (unless you use JWE, which is a separate standard). This means anyone who obtains the token can decode and read the payload contents simply by Base64URL-decoding it -- no secret key is needed to read the data, only to verify the signature. Therefore, you should never include passwords, credit card numbers, social security numbers, or other sensitive personally identifiable information in a JWT payload. Instead, use the JWT to carry identifiers (like user IDs) and non-sensitive claims (like roles or permissions), and look up sensitive data server-side when needed.

Explore More Developer Tools

Check out our other free developer tools. Build Kubernetes manifests, parse AWS ARNs, and more -- all from your browser with no sign-up required.

Kubernetes YAML Generator →