JWT Decoder

Need to decode a JWT and read what is inside it? Paste the token to decode the JWT header and payload instantly, in the browser. JWTs are not encrypted by default, so the header and payload are Base64url-encoded rather than sealed. Pasting a token into a typical third-party decoder hands the entire claims set to a remote service. This decoder runs on WebAssembly so the token never leaves the tab, letting you inspect expiry, issuer, and custom claims without a credential leak risk.

How to decode a JWT

1. Paste the token in the JWT Token field. Leading and trailing spaces or line breaks are trimmed.
2. Remove any prefix such as Bearer copied from an Authorization header: the field must contain only the token.
3. Click Decode.
4. Read the Header and Payload panels, each pretty printed with two space indentation, and copy either one with its copy button.

JWT structure: header, payload, signature

A JSON Web Token is three Base64url-encoded segments joined by dots, in the form header.payload.signature. The header declares the signing algorithm (for example HS256 or RS256) and token type. The payload carries the claims, which is the actual data: registered claims like iss (issuer), sub (subject), aud (audience), exp (expiry), and iat (issued-at), plus any custom claims your application adds. The signature is computed over the first two segments and is what proves the token has not been tampered with.

Reading the most common claims

• exp, iat, nbf: expiry, issued at and not before. They are Unix timestamps in seconds and are shown as raw numbers. Paste one into the Unix timestamp converter to see the date and check whether the token has expired.
• iss and aud: who issued the token and which API it is meant for. A mismatch here is a frequent cause of 401 responses.
• sub: the subject, usually the user or client ID.
• scope, roles, tenant IDs: custom or provider specific claims that drive authorization in your app.
• alg and kid in the header: the signing algorithm and the key ID used to select the verification key from a JWKS.

Decoding is not verifying

This is the single most important thing to understand about a JWT decoder. Decoding simply Base64url-decodes the header and payload so you can read them, and anyone can do that because the segments are not encrypted. Verifying is a separate, cryptographic step that checks the signature against a secret or public key to confirm the token is authentic and unaltered. This tool decodes only, it does not verify the signature, so never trust a decoded payload as proof of identity in production. Verification must happen server-side with the correct key.

Errors and edge cases

• Not three segments: the token must contain exactly two dots. Encrypted tokens (JWE) have five segments and cannot be decoded without the key, so they are rejected with expected 3 parts separated by dots.
• Invalid encoding: segments must be Base64url without = padding, as the JWT specification requires. A stray character such as the space in Bearer eyJ... triggers an encoding error.
• Not JSON: the header and the payload must both decode to valid JSON objects.
• Signature segment: its content is ignored. An unsigned token with an empty signature (header.payload.) still decodes.

Common use cases

• Debugging auth flows: check why a request is rejected by reading the exp claim to see if the token is expired or the aud claim to confirm it targets the right audience.
• Inspecting custom claims: confirm that roles, scopes, tenant IDs, or feature flags were embedded correctly during login.
• Learning and documentation: see exactly how a provider structures its tokens before integrating.

Compared with the command line

You can decode a payload in a terminal by splitting on dots and Base64 decoding the middle segment, but Base64url uses - and _ and omits padding, so a plain base64 -d often fails until you translate characters and add = signs. This page handles that for you and formats the JSON.

Privacy: the token stays in your tab

Access tokens are credentials. Sending one to a remote decoder, even briefly, exposes it to logging and interception, and a token that has not expired can be replayed against your API. Here the JWT is decoded entirely client-side by a Rust module compiled to WebAssembly, so nothing is uploaded, transmitted, or stored. Close the tab and the token is gone.

Frequently asked questions

Does this tool verify the JWT signature?

No. It only decodes the header and payload. Signature verification requires the secret or public key and must be done by your server or a JWT library.

Is it safe to paste a production token?

The token is not sent anywhere: decoding happens in your browser. Still, treat a live token like a password and avoid leaving it in shared screens or clipboard history.

Why do I get "expected 3 parts separated by dots"?

The input is not a signed JWT. It may be truncated, contain a prefix, be an opaque access token that is not a JWT at all, or be an encrypted JWE with five segments.

How do I know if the token is expired?

Read the exp claim in the payload and convert it from Unix seconds to a date with the timestamp converter. If that date is in the past, the token is expired.

Can it decode an encrypted JWT (JWE)?

No. A JWE payload is encrypted, so it cannot be read without the decryption key.

Can I edit the claims and re-sign the token?

No. The tool is read only and does not create or sign tokens.

Related tools

The individual JWT segments are Base64url-encoded, so the Base64 encoder and decoder is handy for working with raw values, and the decoded payload is JSON you can clean up with the JSON formatter. When a token travels in a URL or query string, the URL encode and decode tool helps you handle the percent-encoding correctly.