JWT.io Alternative — JWT Decoder and Inspector

Q: What does "algorithm none" attack mean for JWTs?

Some early JWT libraries had a vulnerability where setting "alg": "none" in the header bypassed signature verification — accepting any payload as valid. Modern libraries reject tokens with alg: none by default, but it's worth checking your library's configuration. Always explicitly specify which algorithms your server accepts (e.g., HS256 only) and reject tokens with unexpected algorithms. If you're building an API, never use a JWT library without disabling the "none" algorithm.

Decode and inspect JWT tokens online — header, payload, expiration, and claims. Fully browser-based, no data sent to any server.

Why Use This JWT Decoder

People looking for a JWT decoder want to quickly inspect token headers and claims — algorithm, expiration, user ID, roles. This tool decodes any JWT instantly and shows the full header and payload in readable JSON. Unlike some online tools, processing is entirely client-side: your token never leaves the browser.

100% client-side: Token decoding runs in your browser — safe to use with production tokens containing sensitive claims
Header inspection: Shows algorithm (alg), token type (typ), and key ID (kid) from the header
Payload display: All claims displayed as formatted JSON — exp, iat, nbf, sub, aud, custom claims
Expiration check: Converts exp and iat timestamps to human-readable dates automatically
No account needed: Paste a token and see the decoded output immediately

Decode JWT →

Choose the Right Variant

This page: JWT decoder for token inspection and debugging
JWT Decoder: Decode, inspect, and debug JWT tokens online
JWT vs Session Tokens: When to use JWTs vs server-side sessions
Base64 Converter: Decode raw Base64 segments manually

Step-by-Step Tutorial

Copy your JWT token — it looks like xxxxx.yyyyy.zzzzz (three base64url segments separated by dots)
Paste the full token into the JWT decoder input field
The header and payload are decoded and displayed as formatted JSON
Check exp to see when the token expires — shown as a human-readable date
Inspect custom claims to verify role, permissions, or user identity fields

Common JWT Claims Reference

iss (issuer): Who issued the token — e.g. https://auth.example.com
sub (subject): Who the token is about — typically a user ID
aud (audience): Who the token is intended for — your API's identifier
exp (expiration): Unix timestamp when the token expires — tokens with past exp are invalid
iat (issued at): Unix timestamp when the token was issued
nbf (not before): Token not valid before this timestamp — used for delayed activation
jti (JWT ID): Unique identifier for this token — used for preventing replay attacks

Privacy and Data Handling

All JWT decoding runs in your browser using JavaScript. Your token — including any encoded user data, roles, or claims — is never transmitted to any server. Safe to use with production tokens.

Frequently Asked Questions

Is it safe to paste a production JWT token into an online decoder?

It depends on the tool. Some online JWT decoders send the token to a server for processing — avoid those for production tokens containing sensitive data. This decoder runs entirely in your browser using JavaScript: the token is decoded client-side using atob() and JSON.parse(). No network request is made. If you're unsure about any tool's privacy behavior, use browser developer tools to verify no external requests are made while the token is pasted.

Why does JWT decoding work without the secret key?

JWT decoding (reading the contents) is separate from JWT verification (confirming it's legitimate). The header and payload are only base64url-encoded — anyone can decode them without the secret. The signature in the third segment is what requires the secret to verify. This is by design: JWTs are meant to be readable but tamper-evident. Never put sensitive information in a JWT payload assuming it's secret — treat it as public data that's cryptographically bound to its origin.

What does "algorithm none" attack mean for JWTs?

Some early JWT libraries had a vulnerability where setting "alg": "none" in the header bypassed signature verification — accepting any payload as valid. Modern libraries reject tokens with alg: none by default, but it's worth checking your library's configuration. Always explicitly specify which algorithms your server accepts (e.g., HS256 only) and reject tokens with unexpected algorithms. If you're building an API, never use a JWT library without disabling the "none" algorithm.