Encoding Tools

JWT Decoder

Decode JSON Web Tokens and inspect header, payload, and expiry timestamps.

Header

{
  "alg": "HS256",
  "typ": "JWT"
}

Payload

{
  "sub": "1234567890",
  "name": "DevToolBox",
  "iat": 1750000000,
  "exp": 1750003600
}

Issued at: 2025-06-15T15:06:40.000Z

Expires at: 2025-06-15T16:06:40.000Z

Understand the format

How JWT Decoder works

A JWT carries its claims in plain sight: the header and payload are only Base64URL-encoded, and the signature is the sole part that proves anything.

Three segments, two of them readable

A signed JSON Web Token is three Base64URL segments joined by dots: header.payload.signature. The header declares the signing algorithm and token type. The payload holds the claims. The signature is computed over the first two segments with a secret or private key, and it is the only part that ties the claims to an issuer you trust.

Because the first two segments are merely encoded, anyone holding the token can read every claim inside it. Never place data in a JWT payload that the bearer should not see. Encoding is not encryption; the separate JWE standard exists for tokens whose contents must stay confidential.

Decoding is not verification

This page decodes. It does not check the signature, and by design it cannot: verification requires the issuer key, which should never be pasted into a web page. A token can decode perfectly, show exactly the claims you expect, and still be forged, expired, or issued by the wrong environment.

Proper verification happens on the server and checks several things together: the signature against the expected key, that the algorithm matches what you expect rather than what the token requests, the issuer and audience, and the time claims. The historical "alg: none" vulnerability came from libraries trusting the header instead of enforcing a configured algorithm.

Step by step

How to use JWT Decoder

  1. Paste the token into the input box. A signature segment is optional for inspection.
  2. Read the decoded header to see which algorithm the issuer claims to have used.
  3. Read the payload for the claims, then check the converted issued-at and expires-at timestamps below it.
  4. Compare the issuer, audience, and scopes against the configuration of the service that rejected the token.

The token is split and decoded in the page using the browser Base64 and JSON APIs. It is never uploaded, logged, or stored, and no signature key is required or accepted.

Worked examples

JWT Decoder examples explained

A decoded header

Input

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

Result

{ "alg": "HS256", "typ": "JWT" }

HS256 is symmetric: the same secret signs and verifies. RS256 is asymmetric, so verifiers only need the public key.

Time claims converted

Input

"iat": 1750000000, "exp": 1750003600

Result

Issued at 2025-06-15T15:06:40Z, expires 2025-06-15T16:06:40Z

Both claims are Unix seconds, not milliseconds. The difference here is a one-hour lifetime.

Reference

Registered claims defined by RFC 7519

Registered claims defined by RFC 7519
ClaimNameWhat it means
issIssuerWho created the token. Must match the issuer your service trusts.
subSubjectWho or what the token is about, usually a user identifier.
audAudienceWho the token is for. A service must reject tokens addressed elsewhere.
expExpiration timeUnix seconds after which the token must be rejected.
nbfNot beforeUnix seconds before which the token is not yet valid.
iatIssued atUnix seconds when the token was created.
jtiJWT IDUnique identifier, used to detect replay or to revoke a single token.

Practical Guide

How teams use JWT Decoder

Common use cases

  • Check subject, audience, issuer, and expiry while investigating a failing login.
  • Verify whether an environment is issuing the claims your application expects.
  • Explain token contents during a support incident without sending the token to an external service.

Checks before trusting the result

  • Decoding a token says nothing about whether its signature is valid.
  • Always compare exp, iat, and nbf against the clock of the environment that rejected the token.
  • Treat every copied token as a live credential, even a short-lived one.

Troubleshooting

Common mistakes and how to fix them

A token is rejected immediately after issue.
Check nbf and clock skew between the issuer and the verifier. A few seconds of drift is enough when leeway is set to zero.
exp appears to be decades in the future.
The value was probably written in milliseconds. RFC 7519 requires seconds since the epoch.
Authorising a request from claims read on the client.
Anyone can craft a token with any claims. Only a server-side signature check makes claims trustworthy.

FAQ

JWT Decoder questions, answered

Is a JWT encrypted?

A signed JWT is not. The header and payload are Base64URL-encoded and readable by anyone holding the token. Encrypted tokens use the separate JWE format.

Can this tool verify the signature?

No, deliberately. Verification needs the issuer secret or key, and pasting that into any web page would be a serious mistake. Verify in your backend or with your identity provider library.

What is the difference between HS256 and RS256?

HS256 uses one shared secret for signing and verification, so every verifier can also mint tokens. RS256 signs with a private key and verifies with a public one, which is what you want when many services validate tokens.

Why does my token have only two segments?

It is unsigned, with an empty signature segment. Unsigned tokens must never be accepted by a service that relies on the claims.

Is it safe to paste a production token here?

Decoding happens entirely in your browser and nothing is transmitted. Even so, treat the token as a live credential: clear it when you are finished and prefer a token that has already expired.

Go deeper

Specifications and guides