JWT Decoder

JWT Decoder Online — Free, No Server, Browser-Side

Paste any JSON Web Token and instantly decode the header, payload, and signature with this free JWT decoder online — no server, no account, everything runs in your browser using the native Web Crypto API. Timestamp fields like exp, iat, and nbf are automatically converted to human-readable dates so you can tell at a glance whether a token has expired.

Beyond basic decoding, the tool verifies HMAC signatures (HS256, HS384, HS512) in-browser and generates ready-to-use JWT signing code for JavaScript, PHP, Python, and Java — making it a complete JWT debugger and development utility.

How to Use the JWT Decoder

1. Paste your JWT into the input field — click Paste from Clipboard or type the encoded token. The tool immediately color-codes the three dot-separated parts (header in pink, payload in purple, signature in cyan) so you can see the structure at a glance.
2. Inspect the decoded data — the header panel shows the algorithm and token type; the payload panel displays all claims with iat, exp, and nbf timestamps automatically rendered as ISO dates, making it easy to spot expiry problems without manual conversion.
3. Check expiration — the decoded exp claim is shown alongside its human-readable equivalent. If the expiry date is in the past, you know the token is expired before touching a single line of code.
4. Verify the signature — for HMAC tokens (HS256, HS384, HS512), enter your secret key in the verification panel. Toggle "Base64 Encoded" if your secret is stored in Base64 format. A green "Signature Verified" badge confirms the token is authentic; a red badge means the secret is wrong or the token was tampered with.
5. Generate code — switch to the code generator, choose your language (JavaScript, PHP, Python, Java) and algorithm, then copy the ready-to-run signing snippet directly into your project.

JWT Decoder Examples

Standard Example (jwt.io reference token)

The following token is the canonical example used on jwt.io — safe to test with any JWT decoder:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Decoded header:

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

Decoded payload:

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

The iat claim (issued-at) renders as 2018-01-18T01:30:22.000Z. There is no exp claim, meaning this token has no built-in expiry — a common oversight in examples that should not be copied to production.

Edge Case 1 — Expired Token

Paste a token whose exp value is a Unix timestamp in the past (e.g., "exp": 1700000000). The tool decodes it normally and displays the expiry date alongside the raw timestamp. You will immediately see that the date is in the past — the token is expired. This is the fastest way to confirm that a "401 Unauthorized" is caused by expiry rather than a bad secret or wrong audience.

Edge Case 2 — Malformed Token (Only Two Parts)

If you paste a string with only one dot (two segments instead of three), the tool rejects it with the error: "Invalid JWT token. Expected format: header.payload.signature." This catches copy-paste mistakes like accidentally truncating the signature or copying only part of a token from a log file.

Edge Case 3 — alg: none Token (Unsigned)

A token with "alg": "none" in the header has no signature — it relies entirely on the server accepting unsigned tokens. The tool decodes it and shows the none algorithm in the header panel. The signature verification section switches to the "unsupported" state, signaling that there is nothing to verify. This is a critical red flag: if your application accepts alg: none tokens, any attacker can craft arbitrary payloads without knowing your secret.

What Is a JSON Web Token?

A JSON Web Token (JWT) is a compact, URL-safe format for securely transmitting claims between parties. Defined in RFC 7519, every JWT has three Base64URL-encoded sections separated by dots:

• Header — declares the token type (JWT) and signing algorithm (HS256, RS256, etc.)
• Payload — contains the claims: user ID, roles, permissions, expiry time, and any custom data
• Signature — a cryptographic hash of the header and payload, signed with a secret or private key, which guarantees the token has not been modified

JWTs are the standard credential format in REST APIs, OAuth 2.0 authorization flows, and OpenID Connect identity tokens.

Supported Algorithms

Common Use Cases

• Authentication debugging: When an API returns a 401 or your frontend gets an "invalid token" error, paste the JWT here to check the exp claim (has it expired?), the aud claim (does it match the expected audience?), and the algorithm before writing any code.
• Security audits: JWTs are Base64-encoded, not encrypted — the payload is readable by anyone. Paste tokens from your system here to confirm no sensitive data (passwords, PII, internal keys) is accidentally leaking through claims.
• Development and integration testing: Verify that your backend issues tokens with the correct claims, correct TTL (exp minus iat), and the right algorithm before writing integration tests against the auth flow.
• Signature verification: Enter your HMAC secret to confirm that a token was signed with the key you expect — useful when debugging token mismatches between services that share a secret.
• Learning JWT structure: The color-coded split view and human-readable claim display make this tool ideal for understanding how JWTs work without reading the RFC.
• Code generation: The built-in code generator produces copy-ready JWT signing snippets so you don't have to look up the right library methods and claim format for each language.

Common Mistakes with JWTs

Confusing Decoding with Verification

This is the most widespread misconception. Decoding a JWT reads the payload without checking the signature — anyone can do it without knowing the secret. Verification confirms that the token was signed by the expected party and has not been tampered with. A token can decode successfully but still be completely forged if the server skips signature verification.

Storing JWTs in localStorage

Tokens stored in localStorage are accessible to any JavaScript running on the page. A single XSS vulnerability anywhere on your site is enough for an attacker to steal every active token. The safer pattern is httpOnly cookies, which JavaScript cannot read at all.

Not Checking the exp Claim

Accepting a JWT without verifying the exp (expiration) claim means a stolen or leaked token is valid indefinitely. Access tokens should have short lifetimes — 15 minutes is the 2026 best practice — combined with a refresh token flow. Paste your tokens here to confirm the exp is set to a reasonable value.

Using alg: none in Production

Some JWT libraries from earlier years accepted tokens with "alg": "none" in the header, meaning no signature was required. An attacker could modify the payload and strip the signature entirely. Modern libraries reject alg: none by default, but it is worth auditing any legacy code that handles JWT validation manually.

Putting Sensitive Data in the Payload

The payload is only Base64URL-encoded, not encrypted. Anyone with the token string — including browser DevTools, proxy logs, and CDN access logs — can decode it instantly. Never store passwords, credit card numbers, social security numbers, or other PII in a JWT payload. Use opaque session tokens if you need server-side privacy, or JSON Web Encryption (JWE) if you must embed sensitive data.

Short-Lived Tokens Without Refresh Logic

Setting a very short exp (e.g., 5 minutes) is good security practice, but without a refresh token mechanism users get logged out unexpectedly. Implement silent token refresh so the user experience stays smooth while the security window stays narrow.

Frequently Asked Questions

Why is the JWT payload visible without any key?

The payload is only Base64URL-encoded, not encrypted. Anyone who has the token string can decode and read the payload without any key. The signature only proves the token was issued by someone with the correct secret — it does not hide the contents. Never store sensitive data in a JWT payload unless you use JSON Web Encryption (JWE).

Can I decode a JWT without the secret key?

Yes — decoding and verifying are completely separate operations. Decoding just Base64URL-decodes the header and payload, which requires no key at all. Verifying checks whether the signature matches the header + payload using the secret or public key. You can always read what a token claims, but you cannot confirm it is genuine without the key.

What happens if I paste an expired JWT?

The tool still decodes it fully and displays the entire payload. The exp claim is shown alongside its human-readable date, making it obvious that the expiry is in the past. The token is expired, but its contents are still readable — useful for debugging exactly what claims were issued before the token expired.

What is the difference between HS256 and RS256?

HS256 is a symmetric algorithm: the same secret key is used both to sign the token and to verify it. RS256 is asymmetric: a private key signs the token, and a different (public) key verifies it. RS256 is preferred in distributed systems where multiple services need to verify tokens without ever receiving the signing secret. HS256 is simpler and faster, making it suitable for single-service or trusted-service scenarios.

How do I check if a JWT token has expired?

Paste the token here — the exp (expiration) claim is automatically rendered as a human-readable date and compared against the current time. If the token is expired, you will see the expiry timestamp displayed clearly alongside the raw Unix timestamp (e.g., 1740000000 (2025-02-20T...)).

Can this tool verify RS256 or RS512 tokens?

Full signature verification in the browser is currently supported for HMAC-based algorithms (HS256, HS384, HS512). For RSA algorithms (RS256, RS384, RS512), the tool decodes and displays the token, but verifying the signature requires a public key — that operation is better performed in your backend using a JWT library.

Is my JWT token or secret sent to any server?

No. All decoding and verification happens entirely in your browser using JavaScript and the Web Crypto API. Your tokens, secrets, and payload data never leave your device. The tool also functions fully offline once the page is loaded.

Resources

• jwt.io — The canonical JWT reference and interactive debugger, maintained by Auth0.
• IETF RFC 7519 — JSON Web Token (JWT) — The official specification that defines the JWT format, claim names, and processing rules.
• Auth0 — Introduction to JSON Web Tokens — A widely cited practical guide covering JWT structure, signing, and common use patterns.