Skip to content

JWT Decoder

Paste a token, see every claim. Decoded in your browser — no server, no leak.

Security Notice — NEVER paste production JWTs with active secrets into any online tool, including this one. Use dev tokens only. Decoding happens in your browser — no network request is made.

How the JWT Decoder Works

A JWT consists of three Base64URL-encoded segments separated by dots: header, payload, and signature. This tool splits the token on the dots, Base64URL-decodes each segment using TextDecoder for full UTF-8 correctness, and renders the parsed JSON. The algorithm (alg) and type (typ) from the header are displayed as badges. Standard registered claims (iss, sub, aud, exp, iat, nbf) are decoded with human-readable timestamps.

The optional HS256 signature verification uses the Web Crypto API (HMAC-SHA256) entirely in the browser. Enable it, enter your HMAC secret, and the tool verifies whether the signature matches. No data ever leaves your browser.

References

The JWT structure is defined in RFC 7519 — JSON Web Token (JWT) (rfc-editor.org/rfc/rfc7519). This RFC specifies the three-part structure, registered claim names (iss, sub, aud, exp, nbf, iat, jti), and the Base64URL encoding.

Signing algorithms (HS256, RS256, ES256, etc.) are defined in RFC 7518 — JSON Web Algorithms (JWA) (rfc-editor.org/rfc/rfc7518). This tool only verifies HS256 (HMAC-SHA256) in v1.

What's here, and what's not

Full JWT decoding: header (alg, typ), payload with all custom claims, signature display. Standard claims (exp, iat, nbf) rendered as human-readable ISO timestamps with relative time (e.g. 'expired 3 days ago'). Optional HS256 signature verification via Web Crypto. Security notice reminding you not to paste production tokens.

What isn't here: JWE (JSON Web Encryption) decryption — encrypted tokens require a private key and are fundamentally different from signed JWTs. RS256, ES256, PS256 signature verification — asymmetric algorithms require the public key in PEM or JWK format, which is v2. Token generation or signing is also not supported — this is a decoder and inspector, not an auth tool.

JWT Structure: Three Parts Explained

A JWT consists of three Base64URL-encoded parts separated by dots: header.payload.signature. Each part is independently encoded and can be decoded without any key.

Header: specifies the algorithm ("alg") and token type. Example: {"alg": "HS256", "typ": "JWT"}. Common algorithms: HS256 (HMAC-SHA256, symmetric), RS256 (RSA-SHA256, asymmetric), ES256 (ECDSA-SHA256).

Payload (claims): the data carried in the token. Standard claims: sub (subject/user ID), iss (issuer), exp (expiration timestamp), iat (issued at), nbf (not before). Custom claims can be added freely.

Signature: created by signing base64(header) + "." + base64(payload) with the server's secret key. Verifying the signature ensures the token wasn't tampered with.

The header and payload are NOT encrypted — they're only Base64URL-encoded. Anyone with the token can read them. Signatures ensure integrity, not confidentiality.

Related tools: Base64 Encoder / Decoder, JSON Formatter, Hash Generator, and URL Encoder.

JWT Security: Common Mistakes

Don't store JWTs in localStorage: vulnerable to XSS attacks. Prefer httpOnly cookies for browser storage — JavaScript cannot access httpOnly cookies.

Always verify the signature server-side: this tool decodes JWTs for inspection — it does NOT verify signatures (that requires the server's secret key). Never trust a JWT payload without signature verification.

Check expiry (exp): a JWT without an expiry claim lives forever. Always set exp and validate it on every request.

Algorithm confusion attacks: if your server accepts both HS256 and RS256, an attacker can create an HS256 token signed with the server's public key. Always specify exactly one algorithm in your JWT library configuration.

alg: "none" vulnerability: early JWT libraries accepted "alg": "none" and skipped signature verification. Always configure your library to require a specific algorithm.

Never put secrets (passwords, credit card numbers) in JWT payloads — they're readable by anyone who has the token.

Frequently Asked Questions

What is a JWT?
A JSON Web Token (JWT, pronounced 'jot') is a compact, URL-safe token format defined in RFC 7519. It consists of three Base64URL-encoded parts: a header (algorithm and type), a payload (claims about the subject), and a signature. JWTs are commonly used in authentication (bearer tokens), authorization, and information exchange between services.
Is it safe to paste my JWT here?
This tool decodes entirely in your browser — no data is sent to any server. However, you should still never paste production JWTs containing live session credentials or sensitive user data into any online tool. Use dev/test tokens here. If a production token is accidentally pasted, revoke it immediately.
What are the exp, iat, and nbf claims?
These are registered claim names defined in RFC 7519: exp (expiration time), the token must not be accepted after this Unix timestamp. iat (issued at) — when the token was created. nbf (not before), the token must not be accepted before this timestamp. All three are NumericDate values (Unix seconds).
What is the difference between HS256 and RS256?
HS256 (HMAC-SHA256) is a symmetric algorithm, the same secret key is used to both sign and verify the token. RS256 (RSA-SHA256) is asymmetric — a private key signs the token and a public key verifies it. RS256 is preferred in distributed systems because the verifying party never needs the private key. This tool supports HS256 verification only.
Where is the JWT specification documented?
The JWT specification is RFC 7519, published by the IETF in May 2015, available at rfc-editor.org/rfc/rfc7519. Signing algorithms are defined in RFC 7518 (JWA). The full family of standards is called JOSE (JSON Object Signing and Encryption) and includes RFC 7515 (JWS), RFC 7516 (JWE), RFC 7517 (JWK), and RFC 7518 (JWA).
Is it safe to decode a JWT in the browser?
Decoding a JWT (reading the payload) is always safe — Base64URL decoding is a reversible operation with no security implications. What is NOT safe is trusting the decoded payload without server-side signature verification. This tool decodes JWTs for debugging and inspection purposes. For production applications, signature verification must happen on the server using the appropriate secret or public key.
How long should a JWT be valid?
Access tokens should be short-lived: 5–60 minutes is typical. Refresh tokens (if used) can be longer: 1–30 days, with rotation on each use. Longer expiry = larger security window if a token is stolen. Common practice: short-lived access token + long-lived refresh token stored in an httpOnly cookie. If a token doesn't contain sensitive claims, longer expiry trades security for convenience.

By Bam's Thinkery — Updated