JWT Decoder
Decode JWT headers and payloads locally in your browser. Inspect claims, expiry, issuer, and timestamps without sending tokens anywhere.
You just tested your JWT Decoder — Try JSON Formatter & Validator next →
What Is a JWT Decoder?
A JSON Web Token (RFC 7519) is three Base64URL-encoded segments separated by dots: header.payload.signature. The header declares the signing algorithm (alg: HS256, RS256, ES256, etc.) and token type. The payload carries claims — Registered (iss, sub, aud, exp, iat, nbf, jti per RFC 7519 §4.1), Public (IANA-registered names like email, name), and Private (any custom field your app defines). The signature is HMAC or RSA/ECDSA over the concatenated header.payload string using a key the verifier knows. This decoder reads the header and payload locally — it does not verify the signature, because verification needs the secret or public key, and pasting either into a web tool would defeat its purpose. Decode ≠ verify: a valid-looking JWT can have a forged signature, an expired exp, or an alg: none header that some careless libraries accept (the 2015 alg: none vulnerability still appears in audits). Use this decoder for inspection during integration work, never as the gate before authorising a request.
How to Use the JWT Decoder
Paste the full token (three dot-separated segments) into the input. The tool splits at the dots, Base64URL-decodes each segment, and renders the header and payload as formatted JSON. Numeric claims like iat, nbf, and exp (Unix seconds since 1970) are converted to ISO-8601 dates alongside the raw value. The status banner reports expired (now > exp), not-yet-valid (now < nbf), or active. If decoding fails, the error pinpoints which segment was malformed — usually a token truncated by a copy-paste, a Base64URL string missing characters, or accidentally pasting an opaque session ID instead of a JWT. Use Copy to grab the JSON of either segment for further inspection in jq, Postman, or your IDE. The signature segment is shown raw — verification is intentionally out of scope.
Why JWT Inspection Matters
When auth breaks, the first inspection step is always the token: which claims are present, has it expired, does aud match the API expecting it, is the iss the right authorisation server, did the client request the right scope. Without a local decoder, developers paste production tokens into random online sites — every paste is a potential credential leak to whoever owns that site's logs, analytics, or backend. Local Base64URL decoding stops the leak. Beyond debugging, JWT literacy matters for security review: spotting an alg: none token, noticing an exp that is years in the future, or catching an unexpected role claim in the payload all take seconds with a decoder and minutes without. JWTs are bearer tokens — possession is authorisation. Treating them with care during inspection is the same hygiene as treating production database credentials with care.
Frequently Asked Questions
Does this verify the JWT signature?
No. This page only decodes the header and payload locally. It does not validate signatures or trust the token.
Why use this instead of jwt.io?
TeaFun emphasises privacy-first decoding. Your token stays in your browser and is never uploaded for processing.
What timestamps are shown?
If present, exp, iat, and nbf are converted from Unix timestamps into readable ISO dates and local time, so you can see exactly when a token was issued, expires, or becomes valid.
Use this tool inside a bigger workflow
These collections group follow-up tools and guides that commonly belong in the same job.
Browse same tags
Jump to other tools that share the same workflow, format, or use case.