EasyDeveloper

JWT Decoder

Inspect the header, payload and claims of a JSON Web Token - decoded locally, never uploaded.

Local ProcessingYour data stays in your browser. Nothing is uploaded.

A JSON Web Token looks like an opaque blob of characters, but its middle segment - the payload - is just base64-encoded JSON that anyone can read. This decoder splits a token into its three parts, decodes the header and payload in your browser, and turns the numeric claims into dates you can actually understand.

Paste a token and press Decode. You get the header (which algorithm and token type), the payload rendered as both a claims table and raw JSON, and the signature shown separately. Standard claims like iat, exp, nbf, iss, aud and sub are interpreted - an epoch timestamp becomes a readable date with a relative hint such as "3 h ago".

One important caveat, and it is the most important sentence on this page: decoding a JWT does not verify its signature. This tool only reads the encoded data. It cannot tell you whether a token is authentic or whether it was issued by the party you think it was - verification requires the issuer's key, which this tool never sees.

Features

  • Split a JWT into header, payload and signature automatically.
  • Decode the header and payload to readable JSON, rendered as both a table and raw text.
  • Interpret standard claims - iat, exp, nbf, iss, aud, sub - and show epoch timestamps as readable dates with relative hints.
  • Show the signature separately and clearly explain that it is not verified.
  • Everything runs locally: the token is decoded in your browser and never uploaded.
  • Paste a realistic example token with one click to see the tool in action.

How to Use

  1. 1

    Paste the token

    Copy the full JWT - all three dot-separated segments - into the input box. Trimming whitespace is handled automatically.

  2. 2

    Press Decode

    Hit Decode or press Ctrl+Enter. The header, claims and payload render immediately beneath the input.

  3. 3

    Read the claims

    The claims table interprets the standard fields. Timestamps like iat and exp are shown as dates with a relative hint, so "1750000000" becomes "2026-06-15 ... in the future" instead of a number.

  4. 4

    Understand the warning

    Treat the warning bar as the most important output: decoding does not verify the signature. Use this tool to inspect what a token says, never to decide that a token is genuine.

Example

Example token

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyXzEyMzQiLCJuYW1lIjoiQWRhIiwiaWF0IjoxNzAwMDAwMDAwLCJleHAiOjE3NTAwMDAwMDB9.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

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

Payload: { "sub": "user_1234", "name": "Ada", "iat": 1700000000, "exp": 1750000000 }

iat = issued at (2023-11-14)
exp = expires at (2025-06-15)

Common Problems

Confusing decoding with verification

The biggest mistake is treating a readable payload as proof of authenticity. Anyone can base64-encode arbitrary JSON. A decoded token tells you what it claims - not that the claim is true.

Missing or extra segments

A JWT always has three dot-separated parts. If the token has two or four segments, it is malformed or not a JWT at all, and the decoder reports the segment count.

Invalid base64url in the header or payload

The segments use base64url encoding with URL-safe characters. If a segment contains characters outside that alphabet, it cannot be decoded and the tool reports the problem rather than guessing.

Payload is not an object

While the payload of a JWT is conventionally a JSON object of claims, a malformed token may carry an array or a scalar. The decoder flags this instead of misinterpreting it.

Technical Details

A JWT is three base64url-encoded segments separated by dots: header.payload.signature. The header declares the signing algorithm (alg) and token type (typ); the payload carries the claims; the signature is a binary value over the first two segments.

Decoding converts each segment from base64url back to raw bytes and parses the JSON. This tool performs no signature check at all - the signature segment is displayed verbatim, which is why the decode result must never be read as authentication.

Standard claims are interpreted when present: iat (issued at), nbf (not before), exp (expiration), iss (issuer), aud (audience) and sub (subject). Time claims are seconds since the Unix epoch and are converted to UTC dates plus a relative hint computed against the current time.

Decoding happens entirely in the browser. The token is read in memory and nothing is transmitted, so it is safe to inspect tokens that might be sensitive.

base64url is the URL-safe variant of base64: it swaps + and / for - and _, and drops padding. The decoder restores the standard form before decoding.

Frequently Asked Questions

Does decoding a JWT verify its signature?

No. Decoding only reads the encoded header and payload. Verifying a signature requires the issuer's secret or public key and a cryptographic check. This tool does neither, and it never claims to. A decoded token is informative, not authentic.

Is it safe to paste a real token here?

From a privacy standpoint, yes - the token is decoded entirely in your browser and never uploaded. From a security standpoint, treat any real token as sensitive and avoid pasting production tokens into any tool unless you must. For routine inspection, use a throwaway or test token.

Why is the payload readable without a secret key?

The payload is base64url-encoded JSON, not encrypted. Base64 is an encoding, not encryption - anyone who has the token can read its claims. The secret key protects the signature, not the readability of the payload.

What do iat, exp and nbf mean?

iat is the time the token was issued, exp is the time it expires, and nbf ("not before") is the earliest time it is valid. Each is a Unix timestamp in seconds, and this decoder converts them to readable dates with a relative hint.

How can I tell if a token is real?

You cannot tell from the payload alone. Verification requires checking the signature against the issuer's key, and for RS256/ES256 tokens that means the issuer's public key. If you only have a token, treat it as untrusted regardless of what its claims say.

What does the alg field tell me?

The header's alg field names the signing algorithm - HS256 (HMAC with a shared secret), RS256 (RSA with a private key) or ES256 (ECDSA). It describes how the token was intended to be signed, but it says nothing about whether this particular token actually was. A token whose header says "none" is not signed at all, and any properly configured verifier will reject it.

Data & Privacy

Your data stays in your browser. Nothing is uploaded.

Processing
Local
Upload
None
Server Storage
None
Account
Not required