JWT Decoder

Paste any JWT token and instantly inspect its header, payload and signature. Timestamp claims are converted to readable dates. Expired tokens are flagged automatically. Nothing leaves your browser.

Paste a JWT token — header, payload and timestamps are decoded instantly
JWT Decoder

JWT Token

Token stays entirely in your browser. Nothing is sent to any server.

Decoded

Paste a JWT token on the left

Header, payload and signature will appear here, decoded and syntax-highlighted.

About this tool

A privacy-first JWT decoder that parses and syntax-highlights all three sections of a JSON Web Token — header, payload and signature — as you type. No button needed. The structure is colour-coded (purple header · blue payload · green signature) so you can immediately identify each segment visually.

Timestamp claims (exp, iat, nbf) are automatically converted to human-readable local dates with a relative time indicator. Expired tokens trigger a prominent warning in the status bar. The tool decodes structure only — signature verification requires a key and must always be performed on your server.

How to use

1

Paste your JWT

Paste the full token string into the input on the left — it typically starts with 'eyJ'. Or click 'Sample' to try an example token with timestamps.

2

Inspect the structure

The colour-coded token preview shows the three segments at a glance. The status bar immediately tells you whether the token is valid, expired, or malformed.

3

Read the decoded sections

Header shows the algorithm and type. Payload shows all claims — timestamp fields are converted to readable dates with a relative time indicator (e.g. '3h from now').

4

Copy what you need

Use the copy buttons next to each section to copy individual JSON objects, or 'Copy all' to export the full decoded token as formatted text.

Frequently asked questions

Common questions about JWT tokens, claims, algorithms, and how to use this decoder.

JWT (JSON Web Token) is an open standard (RFC 7519) for securely transmitting information between parties as a compact, URL-safe string. JWTs are widely used for authentication — when a user logs in, the server issues a JWT that the client sends with every subsequent request. The server can verify the token without storing session state.

A JWT consists of three base64url-encoded sections joined by dots: the Header (algorithm and token type), the Payload (the actual claims — user ID, roles, expiry, etc.), and the Signature (a cryptographic value computed from the header and payload using a secret or private key). Only the header and payload can be read without a key; validating the signature requires the corresponding secret or public key.

These are registered claim names defined in RFC 7519. 'iat' (Issued At) is the Unix timestamp when the token was created. 'exp' (Expiration Time) is the Unix timestamp after which the token must not be accepted. 'nbf' (Not Before) is the Unix timestamp before which the token must not be accepted. All three are expressed as seconds since the Unix epoch (1 Jan 1970 UTC).

No. Signature verification requires access to the secret key (for HMAC algorithms like HS256) or the public key (for RSA/ECDSA algorithms like RS256/ES256). This tool only decodes the header and payload — it shows you what is inside the token, not whether the signature is valid. Never trust a JWT's contents for authorisation without first verifying its signature on your server.

All decoding runs entirely in your browser — your token is never sent to any server. That said, treat JWTs like passwords: avoid pasting tokens from production systems into any online tool when possible. For testing, use tokens from a development environment or generate sample tokens with non-sensitive payloads.

These are the signing algorithms declared in the JWT header. HS256 uses a symmetric HMAC-SHA256 key — the same secret signs and verifies the token, so both parties must share it. RS256 uses an RSA asymmetric key pair — the private key signs, the public key verifies, so the public key can be distributed freely. ES256 uses an ECDSA key pair and produces a shorter signature than RS256 with equivalent security.

No. JWE (JSON Web Encryption) produces tokens whose payload is encrypted rather than just base64-encoded. An encrypted JWT typically has 5 dot-separated parts and its payload appears as random ciphertext. Decrypting it requires the recipient's private key or shared symmetric key. This tool decodes JWS (signed tokens with a readable payload) only.