What Is a JWT?
The JWT Decoder reveals what is inside a JSON Web Token without sending it anywhere. Paste a token and the tool splits it into its three parts, Base64URL-decodes the header and payload, and pretty-prints both as JSON. It automatically interprets the standard time claims — issued-at (iat), not-before (nbf) and expiry (exp) — as human-readable dates and warns you clearly when a token has expired. Remember that a JWT payload is only encoded, not encrypted, so anyone can read it; this tool never verifies the signature and runs entirely in your browser, so your tokens stay on your device.
A JSON Web Token (JWT) is a compact, URL-safe string used to represent claims between two parties. It consists of three Base64URL-encoded sections separated by dots: a Header (algorithm and token type), a Payload (claims such as user ID, expiry time and roles) and a Signature (used to verify the token has not been tampered with). JWTs are the most common authentication token format in modern web APIs and single-page applications.
What people get wrong about JWTs
Most JWT incidents are not cryptographic breaks — they are misunderstandings about what the format guarantees.
Assuming the payload is hidden
A JWT is signed, not encrypted. Anyone holding the token can Base64url-decode the payload and read every claim in it, no key required — that is exactly what this page does. Email addresses, internal user IDs, role names and permissions are all readable by whoever has the token, including the browser it was issued to.
Trusting the alg header
The header states which algorithm signed the token, and a naive verifier reads that field to decide how to check the signature. An attacker who changes it to "none" and strips the signature can forge any payload against a server that honours it. Verification must pin the expected algorithm server-side and ignore what the token claims.
Confusing decoding with verifying
Decoding shows you the contents; it says nothing about whether the signature is valid. A tampered token decodes just as cleanly as a genuine one. Only the holder of the signing key can tell them apart, which is why verification belongs on the server and never in the client.
Reading exp and iat as milliseconds
The registered time claims exp, iat and nbf are seconds since the Unix epoch, while JavaScript's Date.now() returns milliseconds. Comparing them directly makes every token look valid until the year 55000 — a bug that hides completely in testing and only surfaces when an expired token is accepted in production.
How JWT Decoding Works
Decoding a JWT is straightforward: the tool splits the token on dots, Base64URL-decodes each of the three parts and parses the resulting JSON. Base64URL is a variant of Base64 that replaces + with - and / with _, and omits = padding, making tokens safe for use in URLs and HTTP headers.
Decoding is not the same as verifying. This tool can read the claims in any JWT without the signing key — just as any recipient can read the payload of a JWT. Verification (checking the signature against the server's secret or public key) requires the key and must be done server-side. Never rely on a decoded JWT as proof of authenticity without signature verification.
Use Cases
- Inspecting what claims a token carries — user ID, email, expiry, roles — without needing a server.
- Debugging authentication issues by checking whether a token has expired or carries the wrong claims.
- Understanding the algorithm in the header (HS256, RS256, etc.) to know how the token is signed.
- Learning how JWT structure works as a developer or security engineer.
Token Decoding, No Transmission
JWT tokens are decoded using JavaScript libraries that run in your browser. The token data you provide is processed locally on your machine — it is never sent to our servers or anywhere else.