Zellio.io

JWT Decoder

Decode JWT header and payload locally — no secret, no upload.

Runs locallyWorks offlineShare link carries settings, never your data
Send output toBase64 Encode / DecodeCode FormatterRegex Tester & BuilderBuild a workflow from thisOutput stays on this page until you send it.

Frequently asked questions

Is my token sent anywhere?

No. The token is decoded locally in your browser. No secret is needed and the token is never uploaded or logged. Decoding a JWT requires only Base64URL decoding, which is a purely local, offline operation with no network requests. Your token remains in your browser's memory and never leaves your device, making it safe to inspect tokens containing production secrets or sensitive claims. This privacy-first approach is ideal for debugging authentication issues in development or inspecting tokens from staging and production without risking exposure.

Does this verify the signature?

No — it decodes and displays the header and payload so you can read the claims. Signature verification requires the secret or public key on your server. Decoding a JWT reveals its contents, but signature verification ensures the token hasn't been tampered with after creation — something only your authentication server can do with the signing key. For debugging purposes, reading the contents is usually sufficient to understand token structure and claims. For actual authentication or authorization, always validate the signature on the server before trusting the token's contents.

Why can I read the payload without a key?

A JWT payload is only Base64URL-encoded, not encrypted. Anyone can read it, which is why you should never put secrets inside a token. Base64URL encoding is a reversible text encoding (like converting to/from hex), not a security measure — it's only used to safely transmit binary data through text channels. Any attacker who intercepts a JWT can decode it and read every claim it contains, including user ID, roles, and permissions. This means JWTs are safe for transmitting user information (since the server trusts its own signed tokens), but they must never contain passwords, API keys, or other confidential data.

Pro tips

  • Check exp first. Expiry accounts for a large share of authentication failures and is the fastest thing to rule out.
  • Treat any production token you paste into any tool as compromised, and rotate it if it protects something that matters.
  • Remember that decoding is not verification — a tampered payload decodes perfectly and only signature checking will reject it.
  • Compare aud against the service actually rejecting the token when several services share one identity provider.
  • Look for nbf when a freshly issued token is refused; a clock skew between issuer and consumer makes valid tokens temporarily unusable.

About JWT Decoder

Decoding is not verification. A JWT payload is Base64-encoded, not encrypted, so anyone holding the token can read it, and reading it here proves nothing about whether the signature is valid. Treat any production token you paste anywhere as exposed.

Decode a JSON Web Token's header and payload to inspect its claims, issuer, audience and expiry. JWTs are widely used for authentication and API authorisation, and being able to read them quickly is essential when debugging login flows.

The payload carries claims like issuer, audience and expiry, which is usually enough to explain why a login failed. An expired token and one signed with the wrong key look identical to the user, but the exp claim separates them in seconds.

A JSON Web Token is three Base64URL segments separated by dots: a header naming the signing algorithm, a payload of claims, and a signature computed over the first two. Only that third segment is cryptographic. The first two are merely transport-encoded, which means every claim inside is legible to whoever is carrying the token — and to anything that logs it along the way. Two rules follow: put nothing confidential in a payload, and never treat a decode as proof of anything, since well-formed Base64 is trivial to produce.

When a login fails, a handful of claims explain most cases. `exp` and `iat` give expiry and issue time as Unix timestamps, and an expired token looks identical to an invalid one from the user's side. `iss` and `aud` identify who issued the token and who it was meant for, and an audience mismatch is a common failure when several services share an identity provider. `nbf` sets a not-before time, which produces the confusing case of a token that is genuinely valid and not yet usable.

Common use cases

  • Debugging a login or API authorisation failure by reading the claims the server saw.
  • Confirming which scopes or roles a token actually carries versus what was expected.
  • Checking token lifetime while tuning refresh behaviour in an application.
  • Inspecting a token from a third-party identity provider during an integration.
  • Teaching or reviewing how JWTs are structured without wiring up a library.
How it comparesjwt.io is the reference implementation and also verifies signatures when you supply the secret — genuinely useful, and it means pasting a production secret into a web page. Decoding covers the debugging case without ever asking for the key.