JWT Decoder
Decode and inspect JSON Web Tokens instantly. Everything is processed locally in your browser.
Signature
Signature information will appear here after decoding.
Standard Claims
Custom Claims
Custom claims will appear here after decoding.
Token Status
Status information will appear here after decoding.
-
Algorithm
-
Type
0
Claims
0
Token Length
0 B
Header Size
0 B
Payload Size
0 B
Signature Size
Privacy
Your JWT is processed entirely within your browser. No data is uploaded or stored.
How To Use
Paste your JWT
into the Encoded JWT editor, or upload a .txt file containing the token.
Click Decode JWT
to split the token into its header, payload and signature.
Review the decoded JSON
in the Header JSON and Payload JSON panels, plus the Standard and Custom Claims cards.
Check the token status
to see whether the token is active, expired, or not yet valid.
Copy any section
to your clipboard, or click Back to Editor to decode another token.
About JWT Decoder
The DevToolVerse JWT Decoder helps you decode and inspect JSON Web Tokens (JWT) directly in your browser. Whether you're debugging an authentication flow, inspecting an API token, or learning how JWTs work, the decoder breaks a token down into its Header, Payload and Signature so you can read every claim at a glance.
All processing happens locally in your browser, meaning your token is never uploaded to a server. This keeps sensitive claims and credentials private while giving you instant, accurate decoding.
Features
Instant JWT decoding
reveals the header, payload and signature the moment you click Decode.
Human-readable standard claims
Issuer, Subject, Audience, Issued At, Expires, Not Before and JWT ID are labeled and parsed automatically.
Custom claim detection
surfaces every non-standard claim your token carries.
Token status at a glance
shows whether a token is expired, active, or not yet valid.
Upload token files
for quick inspection without retyping.
Copy header, payload or signature
to your clipboard with one click.
Automatic statistics
including algorithm, type, claim count and byte size for every section.
Helpful error messages
for malformed tokens, invalid Base64URL and invalid JSON.
Runs entirely in your browser
your token never leaves your device.
How JWTs Work
A JWT is three Base64URL-encoded sections joined by dots:
Header.Payload.Signature
Header
A small JSON object describing the token, such as the signing algorithm (alg) and token type (typ). Not every JWT uses the same algorithm — the header simply states whichever one was used for that particular token.
Payload
A JSON object containing the claims — the actual data the token carries, such as who it identifies and when it expires. This decoder Base64URL-decodes and parses the payload the same way it parses the header.
Signature
The third section, used by the issuing server to detect tampering. This decoder displays it exactly as received — it isn't JSON, so it isn't decoded or parsed, and this tool does not cryptographically verify it. Verifying a signature requires the secret or public key used to sign the token, which this tool never has.
Decoding a JWT does not prove that the token is authentic or trustworthy. Decoding just makes the Base64URL-encoded header and payload readable — anyone holding the token can do the same, with or without this tool.
The decoder already pretty-prints the decoded Header and Payload for you. If you want to independently validate, minify or further reformat that JSON, JSON Formatter is available for that.
Reading Token Status
"Format: Valid JWT" and "Signature: Present" are not trust signals. They mean the token was structurally readable — not that its signature is cryptographically valid, that it came from a trusted issuer, that it hasn't been modified, or that it hasn't been revoked. This tool never performs signature verification.
| Status | Possible Values | What It Actually Means |
|---|---|---|
| Format | Valid JWT | The decoder successfully recognized three dot-separated sections and could Base64URL-decode and JSON-parse the header and payload. It does NOT mean the signature is cryptographically valid, that the token came from a trusted issuer, that it hasn't been modified, or that it hasn't been revoked. |
| Expiry | No Expiry Claim · Expired · Active | Based on comparing the payload's exp claim with the browser's current time. "No Expiry Claim" means the token has no exp field at all. |
| Not Before | No Claim · Pending · Active | Based on comparing the payload's nbf claim with the browser's current time. "Pending" means the token isn't valid yet. |
| Signature | Present · Missing | "Present" only means the third section of the token contains non-empty text. It does NOT mean the signature is valid — this tool does not perform cryptographic signature verification. |
| Algorithm | Raw alg value, or unavailable | Shows the header's alg value exactly as written. A missing algorithm is shown as unavailable. Displaying an algorithm name does not mean it was checked or validated. |
JWT Claims Quick Reference
The seven standard claims this decoder recognizes and labels automatically. Any other claim in the payload is surfaced under Custom Claims instead.
| Claim | Label | Typically Represents |
|---|---|---|
| iss | Issuer | Who issued the token. |
| sub | Subject | Who the token is about — typically a user or account ID. |
| aud | Audience | Who the token is intended for. |
| iat | Issued At | When the token was created. |
| exp | Expires | When the token stops being considered valid. |
| jti | JWT ID | A unique identifier for this specific token. |
| nbf | Not Before | The earliest time the token should be accepted. |
iat, exp and nbf are Unix timestamps in seconds — the decoder shows both the human-readable date and the raw number. Recognizing these seven claims doesn't mean the decoder checks them against a server's authorization policy; it only labels and displays whatever the token actually contains.
Common JWT Mistakes
Pasting the Authorization Header Instead of the Token
When copying Authorization: Bearer eyJhbGciOi..., paste only the token itself — everything after "Bearer ". Including the prefix makes the first section start with "Bearer ", which isn't valid Base64URL, so the decoder reports an invalid header. (JWTs often appear to start with "eyJ" because a header object commonly Base64URL-encodes that way — that's a common pattern, not a rule every JWT follows.)
Wrong Number of Sections
A JWT must contain exactly three dot-separated sections — Header.Payload.Signature. Pasting a partial token, or text with extra or missing dots, fails immediately with an invalid-format error before any decoding is attempted.
Invalid Base64URL / Corrupted Token
JWTs use Base64URL encoding — a variant that replaces + and / with - and _ and omits padding. Standard Base64 output, a truncated token, or any corrupted text in a section will fail to decode.
Seconds vs. Milliseconds
exp, iat and nbf are Unix timestamps in seconds, not JavaScript-style milliseconds. Passing a millisecond value in one of these claims produces a wildly incorrect decoded date.
Assuming Decoded Means Verified
Anyone holding a JWT can decode its header and payload — Base64URL is not encryption. Successfully decoding a token proves nothing about whether it's authentic or was issued by a trusted server.
Example: Decoding a Token
A fabricated, non-sensitive example token — not a real credential — decoded the same way this tool decodes any token:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJkZXZ0b29sdmVyc2UtZXhhbXBsZSIsInN1YiI6InVzZXJfMTIzNCIsImV4cCI6MTcwMDAwMDAwMCwicm9sZSI6ImFkbWluIn0.ZXhhbXBsZS1zaWduYXR1cmUtbm90LXZlcmlmaWVk
Header
{
"alg": "HS256",
"typ": "JWT"
}Payload
{
"iss": "devtoolverse-example",
"sub": "user_1234",
"exp": 1700000000,
"role": "admin"
}Standard Claims
Custom Claims
iss, sub and exp appear under Standard Claims because they're among the seven recognized keys; role appears under Custom Claims because it isn't. Because this example's exp is in the past, Expiry reports Expired above.
If you need to compare the payloads of two JWTs — for example, before and after reissuing one — decode each token here first, then use JSON Diff to compare the resulting JSON.
FAQ
A JSON Web Token (JWT) is a compact, URL-safe token format used to represent claims between two parties, most commonly for authentication and authorization. A JWT consists of three Base64URL-encoded sections separated by dots: a Header, a Payload and a Signature.
Yes. The JWT Decoder is completely free to use with no registration required.
No. Everything is processed locally in your browser. Your JWT is never uploaded to any server.
No. This tool decodes and displays the header, payload and signature exactly as they appear in the token, but it does not perform cryptographic signature verification. Verifying a signature requires the secret or public key used to sign the token.
Yes. Decoding works regardless of whether a token is expired. The Token Status section shows whether the exp claim indicates the token is expired, active, or not yet valid, but expiration never blocks decoding.
The header describes the token type and signing algorithm. The payload contains the claims — the actual data such as issuer, subject and expiration. The signature is used by the issuing server to verify the token hasn't been tampered with, and is displayed here exactly as received.
Yes. Base64URL decoding is not encryption — anyone holding a JWT can already read its header and payload. This tool simply makes that data easier to read, entirely inside your browser, without sending your token anywhere.