All processing runs in your browser — no files or inputs are uploaded to a server.
Paste a JWT — three base64url segments joined by dots — and the header and payload appear as formatted JSON. If the payload has an "exp" claim, the expiry date shows next to the payload pane, with a red "expired" badge once that timestamp is past.
This is a debugging viewer, not a verifier. The signature segment is read for presence but never checked against a key, so a tampered token decodes just fine. Use it to inspect what a backend or identity provider (Auth0, Cognito, Firebase, Keycloak) actually put inside a token while you build or troubleshoot — then validate signatures server-side with a proper library.
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
// header
{
"alg": "HS256",
"typ": "JWT"
}
// payload
{
"sub": "1234567890",
"name": "John Doe",
"iat": 1516239022
}alg names the signing algorithm; typ is almost always JWT. iat is "issued at" in Unix seconds — convert with the Timestamp Converter tool if needed.
eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ1c2VyXzQyIiwiZXhwIjoxNjAwMDAwMDAwfQ.x
// payload
{
"sub": "user_42",
"exp": 1600000000
}
expired (2020-09-13)When an API returns 401, decoding the token often reveals the issue immediately — the exp claim is in the past, or the clock on the issuing service drifted.
eyJhbGciOiJIUzI1NiJ9.this-is-not-base64.sig
Failed to decode segments
Common when a token gets truncated in a log, double-URL-encoded, or copied with the "Bearer " prefix still attached. Strip the prefix and re-paste.
No. Signature verification needs the issuer's secret or public key, which a generic web tool cannot have. This decoder shows only what the header and payload contain. For verification use a server-side library (jsonwebtoken, jose, PyJWT, etc.) with the correct key.
No. The decode runs entirely in your browser via atob and TextDecoder. The token never leaves the page. Even so, treat production tokens with care — pasting them into any tool is one more place they could leak via clipboard history or screenshots.
All of them, because the decoder ignores the algorithm. HS256, RS256, ES256, EdDSA — the header and payload are just base64url-encoded JSON regardless of how the signature was produced. The algorithm only matters when verifying.
No. JWE has five segments, not three, and the payload is encrypted rather than base64-encoded JSON. You need the decryption key plus a JOSE library. Most "JWTs" in the wild are actually JWS (signed, not encrypted), which this tool handles.
JWT exp is Unix seconds in UTC, not milliseconds and not the local timezone. The badge displays the UTC date. If your server uses milliseconds (a non-standard but common mistake), the year will read 1970 — that's the signal to fix the issuer.
A JWT is three base64url-encoded segments — header, payload, signature — joined by dots. The header announces the signing algorithm (alg) and token type. The payload is a JSON object of "claims": registered ones like iss (issuer), sub (subject), aud (audience), exp (expiry), iat (issued-at), and any custom claims the issuer adds. The signature is computed over header + payload using the algorithm declared in the header.
Base64url differs from regular base64 in two characters (- and _ instead of + and /) and omits padding, which is why pasting a JWT into a normal base64 decoder usually fails. JWTs are not encrypted — anyone holding the token can read everything inside. Never put secrets in a payload; the signature only guarantees the payload was not modified, not that it is private. For encryption, the JOSE family defines JWE, which this tool does not decode.
Encode text to Base64 or decode Base64 back to text. UTF-8 safe.
Percent-encode or decode URL components.
Format and validate JSON. Indented or minified output, with clear error messages.
Generate random UUIDs (v4) in your browser. Bulk generation up to 100 at a time.