JWT Decoder

Decode JWT Header and Payload Instantly

JWT tokens appear in every authorization header, but the three dot-separated segments look like random noise until you decode them. The JWT Decoder splits a token into its header and payload, base64url-decodes each part, and pretty-prints the JSON so you can see the algorithm, the claims, and the expiry at a glance. Debugging a 401 response, checking which claims your identity provider issued, or explaining a token to a colleague becomes a ten-second task. One warning matters more than the rest: this tool never verifies the signature. Decoding only reads the visible parts of the token; proving authenticity requires the issuer's secret or public key, which this page never asks for.

How to Decode a JWT

1. Copy the full token, including all three segments and their dots, from your request headers or application logs.
2. Paste it into the input box. The decoder splits on the dots and decodes the first two segments for display.
3. Read the header, which names the signing algorithm such as HS256 or RS256.
4. Read the payload, which holds the claims like sub, exp, and iat.
5. Check the exp claim against the current time to see whether the token is already expired.
6. Copy the decoded output into your ticket, bug report, or integration notes.

Real Example: Reading a Token's Claims

Take the classic example token issued with the key your-256-bit-secret. The decoder renders the first two segments as readable JSON and leaves the signature segment untouched, because inspecting it would require the secret key.

Pasted together, the full token is eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c. The payload here carries an email-less identity: sub is the subject identifier, and iat is the issuance time as Unix seconds. Because the header and payload are only encoded, not encrypted, this same inspection works for any token — an access token from an OAuth provider, a session token from your own login service, or a token pasted into a bug report. That is exactly when a decoder earns its keep: you need to know what a token claims and when it expires, without standing up a verification stack to find out.

What the Decoder Does Not Do

• No signature verification — the tool cannot confirm a token is authentic; only the issuer, holding the secret or public key, can do that.
• No tamper detection — edit a claim, re-encode it, and the decoder will happily display the forged payload. A verifier, by contrast, would reject it.
• No expiry evaluation — the exp claim is shown as a raw number; compare it with the current Unix time yourself or use a timestamp converter.
• No key handling — secrets live only on the servers that issue and validate tokens. This page never asks for one, and neither should any decoder you trust.

Working Safely with JWTs

• Never paste production tokens into unknown third-party sites — a real token can remain valid for hours or days; treat it with the same care as a password.
• Convert exp to a readable date — pair this tool with a timestamp converter to see exactly when the token stops being valid.
• Keep the full token intact — a missing dot, surrounding quotes, or URL-escaped characters such as %2E break decoding.
• Do not judge authenticity from decoded content — anyone can forge a header and payload. Only signature validation proves where a token came from.

JWT Decoder FAQ