JWT Decoder

Paste a JSON Web Token. The header, the payload and the dates are decoded in your browser. The signature is not verified, and nothing is sent to a server.

Header

The header will show up here.

Payload

The payload will show up here.

Learn more about JSON Web Tokens

What is this tool?

A JSON Web Token (JWT) is a compact way to carry claims between two parties. Defined by RFC 7519, it is three Base64URL segments separated by dots: a header, a payload and a signature. The header names the algorithm. The payload is a JSON object. The signature is what allows a recipient who knows the key to check that the token was not altered.

This tool decodes the header and the payload, and turns the time claims exp , iat and nbf into calendar dates. It does not verify the signature, and it does not decrypt an encrypted token. Anyone can build a token with any payload: what you see here is the content, not a proof that it is authentic.

Typical use cases

Reading a token returned by an API while debugging a client.
Checking whether exp is already in the past, in your local time and in UTC.
Seeing which algorithm the header declares, including the unsecured value none .
Comparing the claims you received with the ones the server is supposed to issue.

How to use it

Paste the token. A leading Bearer and line breaks are ignored.
Read the header and the payload. They are shown as indented JSON.
Read the registered claims. Dates are shown in your local time, with the UTC time and the raw number of seconds beside them.
Use Copy on the token, the header, the payload or the signature.

Decoding runs entirely in your browser. The token stays on your machine: nothing is uploaded.

The signature is not verified. A decoded payload is not evidence that the token was issued by the server you think.

Before / after examples

Sample token, payload only

Before

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

After

{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022
}

Token with issuance and expiration

Before

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwczovL2V4YW1wbGUuY29tIiwic3ViIjoiYWRhIiwiYXVkIjoiZHRrIiwiaWF0IjoxNTE2MjM5MDIyLCJuYmYiOjE1MTYyMzkwMjIsImV4cCI6MTUxNjI0MjYyMn0.y0vdUxyCXkB-xer_-Tls6XYEmF2maiZ0u7U49aYTLyU

After

{
  "iss": "https://example.com",
  "sub": "ada",
  "aud": "dtk",
  "iat": 1516239022,
  "nbf": 1516239022,
  "exp": 1516242622
}

In the second token, iat and nbf are 2018-01-18T01:30:22Z and exp is exactly one hour later, 2018-01-18T02:30:22Z. The tool therefore shows the token as expired. The header of both examples is {"alg":"HS256","typ":"JWT"} . The signatures are not checked.

Common mistakes

Most surprises come from treating a decoded token as authenticated, from the unit of the dates, or from characters that are not part of the compact token.

Expiration written in milliseconds

Invalid

"exp": 1516242622000

Valid

"exp": 1516242622

Token wrapped in quotes

Invalid

"eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.sig"

Valid

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.sig

Unsecured algorithm

Invalid

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

Valid

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

Changing none to HS256 in the header does not make a token authentic. The signature still has to be produced with the right key, and this page never checks it. Do not grant access from a payload you have only decoded.

Good to know

The signature segment is displayed and nothing more. Verification would need the secret or the public key, which this tool never asks for.
Time claims use NumericDate from RFC 7519: seconds since 1970-01-01T00:00:00Z, not milliseconds. A fractional part is allowed. exp is still valid only while the current time is strictly before it. nbf is valid from that second onward.
The comparison uses the clock of your machine. A server may accept a token for a few extra minutes to absorb clock skew.
An encrypted token (JWE) has five segments. Its payload is not readable without the key, so this tool refuses it instead of showing ciphertext as JSON.
Only the compact serialization is accepted: three segments on one line. The JSON serialization of a JWS is rejected.
A leading Bearer , spaces and line breaks are removed before decoding. Surrounding quotes are not. Padding = may be missing, and both the Base64 and Base64URL alphabets are accepted.
A share link stores the token text you pasted. The header, the payload and the dates are computed again when the link is opened.

Did you know?

JWT is specified by RFC 7519, published in May 2015 by Michael B. Jones, John Bradley and Nat Sakimura. The RFC suggests pronouncing JWT like the English word "jot".
The same month, the IETF published the rest of the JOSE set: JWS (RFC 7515), JWE (RFC 7516), JWK (RFC 7517) and JWA (RFC 7518).
RFC 7515 requires Base64URL for the segments, and it omits the = padding. That is why a JWT can sit in a URL without escaping.
The sample token widely shown in JWT introductions carries the payload {"sub":"1234567890","name":"John Doe","iat":1516239022} . That iat is 2018-01-18T01:30:22Z.
RFC 7518 (section 3.6) defines the algorithm none : no signature is computed, and the signature segment is empty. An implementation must not accept that token unless the application has explicitly allowed this particular token to be unprotected.

Frequently asked questions

Is my token sent to a server?: No. Decoding and the share link run in your browser. The token is neither stored nor transmitted. A share link keeps it in the URL fragment, which is not sent to the server.
Does this page check the signature?: No. Checking a signature needs the secret or the public key, and it has to be done by the service that trusts that key. This page only shows what is inside the token.
The API accepts the token, but here it looks expired. Why?: The date is compared with the clock of your computer, with no grace period. Servers often allow a few minutes of skew. Compare the UTC time shown here with the server clock before treating the token as rejected.
What is the difference between a signed token and an encrypted one?: A signed token (JWS) has three segments and a readable payload. An encrypted token (JWE) has five segments. Its payload stays hidden without the encryption key, so this tool does not display it.
Can I trust the claims I see?: No. Anyone can write a header and a payload and encode them. The signature is the part that binds those bytes to a key. Until that signature is verified with the right key, the claims are just text.