Encoding Tools

JWT Decoder

Decode a JSON Web Token and read its header and payload in your browser.

Browser workspace
LOCAL PROCESSING

Input stays in this browser while you use the tool.

About this tool

The JWT Decoder reads a JSON Web Token (JWT) and shows what is inside it: the header and the payload, as readable JSON. A JWT is the long string of letters, digits, dots, hyphens and underscores that web applications and APIs use to carry login and authorisation information, for example in an Authorization header or in a cookie. It looks like random text, but its first two parts are only encoded, not encrypted, so anyone who holds the token can read them.

A JWT has three parts separated by dots, in the form header.payload.signature. The header describes the token, for example the signing algorithm in the alg field. The payload holds the claims, such as the user in sub, the issuer in iss, the audience in aud and the times in iat, nbf and exp. The signature lets the server check that the token has not been changed. The header and the payload are JSON written in Base64URL, which is Base64 with - and _ instead of + and / and without the = padding. The tool reverses that encoding for you.

Decoding is not verifying. The tool shows what the token claims. It does not prove that the token is genuine, unchanged or still accepted by a server. Checking the signature needs the secret or the public key, and it belongs on the server of the application that issued the token, using a JWT library.

The decoding runs in your browser, so the token is processed on your own device and is not sent to the BitToolsKit server. Even so, treat a real token like a password: whoever has a valid token can use it until it expires. For production systems, prefer expired or test tokens when you paste into any online tool.

Use cases

  • Debug an authentication problem. When an API answers with 401 or 403, decode the token and check the issuer, the audience, the subject and the roles or scopes it really contains.
  • Check when a token expires. Read the iat, nbf and exp claims and convert them to dates, to find out whether the token is already expired or not yet valid.
  • Find a token that belongs to the wrong environment. A token from a test system often has a different issuer or audience than the one your production API expects.
  • Inspect tokens from an identity provider. See which claims a login service puts into the token, so that you know what your application can rely on.
  • Check the signing algorithm. Read the alg and kid fields of the header to see which algorithm and which key the token claims to use.
  • Review what you put into a token. The payload is readable by everyone, so decoding your own token shows at once whether it holds data that should not be there, such as personal details or secrets.
  • Learn how JWTs work. Paste a token, look at each part and see how the dots, the encoding and the claims fit together.

How to use

  1. Copy the token. Take only the token itself, without the word Bearer, without quotation marks and without spaces or line breaks before or after it.
  2. Paste the token into the Input box.
  3. Click Run tool.
  4. Read the result in the Output box. The header shows the token type and the algorithm, and the payload shows the claims.
  5. Check the time claims. The values of iat, nbf and exp are seconds since 1 January 1970 UTC. Convert them with the Timestamp Converter to read the dates.
  6. If a message appears instead of a result, the text is not a decodable token. Check it against the common errors below and run the tool again.
  7. Click Copy output to copy the result, Download to save it, or Clear to remove the token from the boxes.

Remember that this tool only decodes the token. It cannot tell you whether the signature is valid.

Examples

Example 1: A signed token (HS256)

Input:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkFkYSBMb3ZlbGFjZSIsInJvbGUiOiJhZG1pbiIsImlhdCI6MTcwNDA2NzIwMCwiZXhwIjoxNzA0MDcwODAwfQ.vxkyoiso7ZwwdPSiHH2yy5zbnO94NdEgdssfeOrqb-E
What a decoder shows:
Header:
{"alg":"HS256","typ":"JWT"}

Payload:
{"sub":"1234567890","name":"Ada Lovelace","role":"admin","iat":1704067200,"exp":1704070800}

The third part is the signature. It is a binary value and is not turned into readable text.

Example 2: Reading the time claims

Payload claims:
iat: 1704067200
exp: 1704070800
What they mean:
iat = 2024-01-01 00:00:00 UTC (issued at)
exp = 2024-01-01 01:00:00 UTC (expires at)
exp minus iat is 3600 seconds, so the token is valid for one hour. The values are in seconds, not milliseconds.

Example 3: An edited payload still decodes

Original payload:
{"sub":"1234567890","role":"admin"}
Edited payload:
{"sub":"1234567890","role":"superuser"}
What happens:
A decoder shows the edited payload without complaint, because decoding does not check the signature. A server that verifies the signature rejects the token, because the signature was created for the original payload. Never trust a decoded token on its own.

Example 4: An unsigned token (alg none)

Input:
eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkFkYSBMb3ZlbGFjZSIsInJvbGUiOiJhZG1pbiIsImlhdCI6MTcwNDA2NzIwMCwiZXhwIjoxNzA0MDcwODAwfQ.
What a decoder shows:
Header: {"alg":"none","typ":"JWT"}
The token ends with a dot and its signature part is empty. It is unsigned, so anyone could have created it. A server must never accept such a token as proof of identity.

Example 5: A pasted Bearer prefix

Input:
Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIi...
What happens:
No readable result. The word Bearer and the space become part of the first segment, so it no longer decodes to JSON. Paste only the token.

Example 6: A token with five parts

Input:
aaaa.bbbb.cccc.dddd.eeee
What it means:
A token with five parts is usually an encrypted token (JWE). Its payload cannot be read without the decryption key, so a decoder cannot show its claims.

Common errors

The word Bearer is included in the input

The Authorization header looks like Bearer followed by a space and the token. Only the token is a JWT. Remove the word Bearer and the space, or the first part will not decode.

The token does not have three parts

A standard signed JWT has exactly two dots. A text with one dot is cut off or is not a JWT. A text with four dots, which means five parts, is an encrypted token (JWE) whose content cannot be read without the key.

The token was cut off when it was copied

Long tokens are shortened by logs, chat tools, terminals that wrap lines and fields with a length limit. Compare the end of your text with the original, and copy the whole token again.

Quotation marks, spaces or line breaks around the token

A token copied from JSON, a config file or a terminal often carries quotation marks or a line break. Remove everything except the three parts and the two dots.

A segment cannot be decoded as Base64

The header and payload use Base64URL. A normal Base64 decoder fails on the hyphen and the underscore, and a strict one fails on the missing equals signs. Swap hyphen for plus and underscore for slash, and add padding, or use a tool that supports Base64URL.

The decoded payload is not valid JSON

The segment may be corrupted, or it is not a JWT at all. Some systems use opaque tokens, which are random strings that only the server can look up. These cannot be decoded.

The exp date looks like 1970 or far in the future

The time claims are in seconds. A tool or a piece of code that expects milliseconds shows a date in January 1970, and the other way round gives a date far in the future. Check the unit before you decide that the token is wrong.

The token looks valid but the server rejects it

Decoding cannot show whether the signature is valid. Check the audience and issuer, the time claims including small clock differences between servers, and make sure that the token belongs to the same environment and was signed with the key the server expects.

You think the payload is private because it looks unreadable

Base64URL is an encoding, not encryption. Anyone can decode the payload in a second. Never put passwords, secrets or sensitive personal data into a JWT unless the token is encrypted.

The token has no exp claim

Not every token has an expiry time. If there is none, the server may use its own rules or accept the token for a very long time, which is a security risk. Check how your system limits the life of tokens.

Frequently asked questions

What is a JWT?

A JWT, or JSON Web Token, is a compact text format for passing claims between systems. It has three parts separated by dots: a header, a payload with the claims and a signature that protects the token against changes.

Is a JWT encrypted?

A normal signed JWT is not encrypted. The header and payload are only encoded with Base64URL, so anyone who has the token can read them. A separate format called JWE encrypts the content, and it has five parts instead of three.

Does decoding a JWT verify its signature?

No. Decoding shows the content of the token. Verifying the signature requires the secret or the public key and should be done on the server with a JWT library, never only by looking at a decoded token.

What do iat, nbf and exp mean?

They are time claims in seconds since 1 January 1970 UTC: iat is when the token was issued, nbf is the time before which it must not be accepted, and exp is the time when it expires.

What are sub, iss and aud?

sub is the subject, usually the user id. iss is the issuer, the system that created the token. aud is the audience, the system or service that the token is meant for.

What does alg none mean?

It means the token is unsigned. A token like that proves nothing, because anyone can create it. Servers must reject unsigned tokens, and they should accept only the algorithms they expect.

Why do the parts of a JWT have no equals signs at the end?

JWT uses Base64URL encoding, which usually leaves out the padding. Some Base64 decoders insist on the padding, so a decoder for JWTs has to add it back.

Is it safe to paste a token into this tool?

The tool runs in your browser and does not send the token to the BitToolsKit server. Even so, a valid token works like a password until it expires, so avoid pasting production tokens into any online tool, and replace a token that you have exposed.

Can I decode a token that is expired?

Yes. Decoding does not check the time claims. An expired token can still be read, which makes it useful for finding out when and why it expired.

How can I verify a JWT properly?

Use a maintained JWT library in your application. It checks the signature with the right key, rejects unexpected algorithms and validates claims such as exp, nbf, iss and aud.

Related tools

Share this page