ToolSahla, Tools Sahla

My developer sent me a JWT access token for a store integration. Can I read it here, and does decoding it mean it is genuine?

Yes, you can read it: paste only the middle part, between the two dots. It is URL-safe Base64 without padding; the tool adds the missing = signs and shows the JSON inside. But decoding does not check the signature, so it tells you what the token claims, not that it is genuine. And a live token grants access, so treat it like a password.

Published · 3 min read

What a JWT is made of

A token has three parts separated by dots. The first describes the signature type, the second is the content, the 'claims' such as the user ID, its role and when the token expires, and the third is the signature. The first two parts are plain JSON written in Base64, with no encryption at all. That is why anyone who sees the token can read what is in it.

Example: reading the content

The middle part of a test token was:

eyJzdWIiOiIxMjMiLCJyb2xlIjoiYWRtaW4ifQ

Pasted in 'Decode' mode, it showed:

{"sub":"123","role":"admin"}

with a note: 'Padding is missing: 2 = sign(s) were added to complete the length. This is normal for URL-safe Base64.' So the token claims to belong to user 123 with the admin role. Decoding the first part of another token gave {"alg":"HS256","typ":"JWT"}, the signature type.

Do not paste the whole token

We tried pasting all three parts together, and the tool refused with 'Position 37: a character that is not in the Base64 alphabet', pointing at the first dot. A dot is not in the alphabet, so each part is decoded on its own. The third part, the signature, is bytes rather than text, so there is nothing to gain from decoding it.

  1. Copy the token, then copy from it only what lies between the first and second dots.
  2. Open the Base64 encoder/decoder tool, choose 'Decode' and paste the middle part.
  3. Read the resulting JSON, and if it is long, format it in the JSON formatter and validator to follow it easily.
  4. Clear the box when you are done, and do not keep the token in a note or chat.

Why decoding does not mean the token is genuine

Verifying a JWT means computing a signature from the first two parts with the secret key and comparing it with the third part. That needs the key held by the system that issued the token, and neither this tool nor any Base64 decoder does it. Anyone can write {"role":"admin"}, encode it, and put it in a forged token that looks fine when decoded. Decoding only answers 'what does the token say?'.

The token is a secret, even though its content is readable

  • A valid token works like a temporary password: whoever holds it can use the permissions in it until it expires.
  • This tool runs in your browser and sends the token nowhere, but be wary of pasting it into tools when you do not know where they send data.
  • If your developer sent it in a public chat or shared mailbox, ask them to revoke it and issue a new one.
  • Because the content is readable by anyone who sees the token, it should never contain secrets such as passwords.

Common questions

What does the exp field in the content mean?

It is when the token expires, written as a number of seconds since the start of 1970. The tool shows it as a raw number and does not convert it to a date.

Why are there no = signs in JWTs?

Because these tokens use the URL-safe alphabet and drop the padding. The tool fills in the missing signs and says so in a note.

Can the tool check the signature if I give it the key?

No. It only encodes and decodes; verification happens in the system that issued the token.