JWT Decoder

Decode a JSON Web Token without uploading it

Paste a compact JWT to inspect its header and payload as formatted JSON. Registered claims such as issuer, audience, expiration and not-before time are pulled into a readable table, and NumericDate values are shown in your local time.

The token stays in the current browser tab. It is not uploaded, logged or written into the page address. That last detail matters: JWTs are often bearer credentials, and a URL can be saved in browser history, analytics and referrer data.

Three compact parts

A signed JWT commonly travels as a JWS Compact Serialization with three parts separated by periods:

BASE64URL(header).BASE64URL(payload).BASE64URL(signature)

The header describes the token, often including its declared signing algorithm and type. The payload is a JSON object containing claims. The final part carries the signature bytes. Base64URL makes those values safe to transport in a compact string; it does not make them secret.

A compact token with five parts is generally an encrypted JWE. Its protected content cannot be inspected without the appropriate decryption key, so this three-part decoder reports it rather than pretending it is malformed JSON.

Decoding is not verification

This distinction is the security boundary of the tool. Decoding proves only that two token segments contain readable JSON. Anyone can make a token with a plausible-looking header, an administrator role and an expiration date in the future.

Signature verification needs a trusted key and an explicit algorithm policy. A real application must also check the issuer and audience it expects and apply its own rules to time claims. None of that trust context exists on a generic decoder page, so this tool never labels a token valid and never claims the signature was checked.

The declared alg value is data supplied by the token creator, not proof of the algorithm that a recipient should accept. In particular, alg: "none" describes an unsecured JWT with no cryptographic signature and triggers an additional warning here.

Registered claims and time

JWT defines a set of registered claim names. Common examples include iss for issuer, sub for subject, aud for audience and jti for a token identifier. Applications can add private claims as well, which remain visible in the formatted payload.

exp, nbf and iat use NumericDate values: seconds since the Unix epoch. The tool compares exp and nbf with the current browser time and flags an expired or not-yet-active claim. That is useful inspection, but it still does not authenticate the token or the person who supplied it.

Treat tokens as credentials

A JWT payload is readable, and it should never carry a secret merely because it looks encoded. A signed JWT protects integrity, not confidentiality. Anyone who receives the token can inspect its claims.

Many JWTs also grant access to an API when presented as bearer tokens. Local processing reduces accidental exposure, but it does not make a live production token harmless. Prefer a redacted or expired example whenever that is enough to diagnose the issue.

Frequently asked questions

What does a JWT contain?

A typical signed JWT has three period-separated parts: a protected header, a payload containing claims, and a signature. The first two are Base64URL-encoded JSON. They are readable by anyone who has the token; they are not encrypted.

Does decoding verify the JWT?

No. Decoding only reveals the JSON. Verification requires a trusted key plus an explicit policy for the allowed algorithm, issuer and audience. This tool has none of that context, so it deliberately labels every result decoded — not verified.

Can I trust claims shown by this decoder?

Not by themselves. Anyone can create a token containing any header and claims they want. An application may trust them only after cryptographic verification and all of its issuer, audience, algorithm and time checks succeed.

What are exp, nbf and iat?

exp is the expiration time, nbf is the time before which the token must not be accepted, and iat records when it was issued. JWT represents these as NumericDate values: seconds since 1970-01-01T00:00:00Z. This page formats them as readable local dates.

Why does my token have five parts?

A five-part compact token is generally JWE: encrypted rather than merely signed. Its protected data cannot be decoded without the decryption key, so a decoder for three-part JWT/JWS compact tokens cannot inspect it.

What does alg none mean?

It declares an unsecured JWT with no cryptographic signature. Supporting such a token is a policy decision for a receiving system; it must never be accepted simply because its claims decode successfully. The tool shows an extra warning when it sees alg: "none".

Is my token uploaded or put in the URL?

No. Decoding happens entirely in your browser, and the token is kept only in the current tab's state. It is never placed in the page address, browser history or a share link. Even so, treat production bearer tokens like passwords and avoid exposing them unnecessarily.