A standard JWT (JWS) is not encrypted - it is only signed. The payload is base64url-encoded, which means anyone who obtains the token can read its contents. JWE (JSON Web Encryption) is a separate standard for encrypted tokens. Unless you are explicitly using JWE, assume your JWT payload is readable by anyone who holds it.

JWT Decoder

Decode and inspect JSON Web Tokens — private, runs entirely in your browser

Paste JWT Token Your tokens never leave your browser.

What Is a JWT?

A JSON Web Token (JWT) is a compact, URL-safe string used to represent claims between two parties. A JWT consists of three parts separated by dots: header.payload.signature. Each part is base64url-encoded, meaning the + character is replaced with -, / with _, and padding = is typically omitted.

The header describes the token type and the signing algorithm (e.g., HS256, RS256). The payload contains claims — statements about the user and additional metadata. The signature is created by signing the encoded header and payload with a secret or private key, allowing the recipient to verify the token has not been tampered with.

JWTs are widely used for authentication (after login, the server issues a JWT the client sends with each request), API authorization, and Single Sign-On (SSO) flows between services.

JWT Claims Reference

The JWT specification defines a set of registered claim names. These are not mandatory, but their use is recommended when the semantics match your use case.

Claim	Name	Description
`iss`	Issuer	Who issued the token (e.g., your auth server URL)
`sub`	Subject	Who the token is about — typically the user ID
`aud`	Audience	Intended recipient(s) of the token
`exp`	Expiration	Unix timestamp after which the token must not be accepted
`nbf`	Not Before	Unix timestamp before which the token must not be accepted
`iat`	Issued At	Unix timestamp when the token was created
`jti`	JWT ID	Unique identifier to prevent replay attacks

JWT Security Best Practices

Never store JWTs in localStorage: JavaScript can read localStorage, making tokens vulnerable to cross-site scripting (XSS) attacks. Prefer httpOnly cookies that JavaScript cannot access.
Always verify signatures server-side: Decoding a JWT does not validate it. Your server must verify the signature against the secret or public key before trusting any claim.
Use short expiration times: Set exp to minutes or hours, not days or weeks. Combine with refresh tokens for longer sessions.
Do not put sensitive data in the payload: The payload is only encoded, not encrypted. Anyone who intercepts the token can read every claim. Store only non-sensitive identifiers like user IDs and permission scopes.
Use strong algorithms: Prefer asymmetric algorithms like RS256 or ES256 for tokens consumed by third parties. Avoid the none algorithm entirely — some libraries have historically accepted unsigned tokens.
Validate all claims: Check exp, nbf, iss, and aud on the server. Do not skip claim validation just because the signature is valid.

Why Decode JWTs Locally?

JWT tokens routinely contain user data, session information, and permission scopes. When you paste a token into an online decoder that sends it to a server, you are exposing that data — and potentially live session credentials — to a third party you do not control.

This tool decodes tokens entirely within your browser using standard JavaScript. No token data is transmitted over the network. The base64url decoding, JSON parsing, and timestamp formatting all happen locally on your machine. Close the tab and the data is gone.

This is especially important in professional and enterprise environments where tokens may encode role information, internal user IDs, or infrastructure details that should not leave your network.

Frequently Asked Questions

Can you decode a JWT without the secret?

Yes. The header and payload are only base64url-encoded, so anyone can decode and read them without any key. The secret (or private key) is only needed to verify the signature — which proves the token was genuinely issued by a trusted party and has not been altered. This tool decodes the readable parts; it does not perform signature verification.

Is a JWT encrypted?

A standard JWT (technically a JWS — JSON Web Signature) is signed but not encrypted. The payload is base64url-encoded, not ciphered — anyone who holds the token can decode and read the payload. JWE (JSON Web Encryption) is a separate format for truly encrypted tokens. Unless your application explicitly uses JWE, assume your JWT payload is readable by anyone who obtains it.

Should I put sensitive data in a JWT?

No. Because the payload is readable by anyone, you should never include passwords, payment information, government IDs, or other sensitive personal data in a JWT payload. Restrict the payload to non-sensitive identifiers such as a user ID or a set of permission scopes.