Decode a JWT's header and payload instantly, entirely in your browser. This tool never verifies the signature.
A JSON Web Token (JWT, pronounced "jot") is a compact way to represent a set of claims — like a user ID, roles, or an expiration time — as a signed, URL-safe string. It's made of three parts separated by dots: header.payload.signature. The header and payload are each a JSON object, Base64URL-encoded; the signature is a cryptographic hash proving the header and payload haven't been changed since the token was issued, computed using a secret (or private) key only the issuing server knows.
This is the single most important thing to understand about a standard JWT: the header and payload are only encoded, not encrypted. Anyone who has the token — including this tool, or any similar one — can decode and read them without needing any key at all. Security comes entirely from the signature, which lets a server confirm the payload hasn't been tampered with since it was issued (and, for asymmetric algorithms like RS256, who issued it). Never put a password, secret key, or other sensitive-if-read data inside a JWT payload expecting it to stay hidden — it won't.
| Claim | Meaning |
|---|---|
iss | Issuer — who created and signed the token |
sub | Subject — who the token is about (often a user ID) |
aud | Audience — who the token is intended for |
exp | Expiration time, as a Unix timestamp |
iat | Issued-at time, as a Unix timestamp |
No, and it never will. Verifying a signature requires the secret or public key the token was signed with, which this tool never asks for. This tool only decodes the header and payload so you can read their contents — it says nothing about whether the token is authentic, unexpired-by-someone-else's-server-logic, or has been tampered with. Signature verification always has to happen on the server (or system) that knows the signing key.
A JSON Web Token (JWT) is a compact, URL-safe way to represent a set of claims (like a user ID or permissions) as a signed token. It has three dot-separated parts — header, payload, and signature — each Base64URL-encoded. The header and payload are just encoded, not encrypted, meaning anyone can decode and read them; only the signature actually requires a secret key.
Not by design — a standard JWT is meant to be readable by anyone; its security comes entirely from the signature, which proves the payload hasn't been altered since it was signed (and, for asymmetric algorithms, who signed it). It's a mistake to put secret information in a JWT payload assuming it's hidden — it isn't, which is exactly what this tool demonstrates.
These are standard registered claim names. "iat" (issued at) and "exp" (expiration time) are Unix timestamps marking when the token was created and when it expires. "sub" (subject) typically identifies the user or entity the token is about. None of these are required, but they're extremely common.
Typically just two fields: "alg" (the signing algorithm, e.g. HS256 or RS256) and "typ" (the token type, almost always "JWT").
You'll see a clear error explaining what's wrong — for example, that the token doesn't have three parts, or that a part isn't valid Base64URL or valid JSON — rather than a blank or misleading result.
No. Every part of the decoding happens locally in your browser using JavaScript. A JWT can contain real user data, so nothing you paste here is ever sent to Brekzy, logged, or stored anywhere.
Yes, completely free, with no account, sign-up, or usage limit.
Explore Brekzy's growing collection of free calculators, converters, AI tools, and practical resources.