Toolivaro

Free JWT Decoder

Decode JWT header, payload, and claims locally — with optional HMAC signature verification. Nothing leaves your browser.

The JWT decoder reads the JSON Web Tokens your APIs issue and consume — the compact header.payload.signature form used by OAuth 2.0, OpenID Connect, and countless auth libraries — and renders them as readable, pretty-printed JSON: the header with its algorithm and key id, the payload with its claims, and the raw signature segment. The decode happens entirely in your browser: base64url-decoding and JSON parsing are local, so the tool is safe to use with production tokens that carry real user identifiers, emails, and session details — nothing is uploaded, logged, or stored. What this decoder will not do is overclaim. It can verify an HMAC signature when you paste the secret: the tool computes the HMAC with WebCrypto and reports Signature valid or Signature invalid, so you can confirm a token was actually signed with the secret you hold and has not been tampered with in transit. That check is honest about its scope: only HS256, HS384, and HS512 can be verified with a shared secret in the browser. Asymmetric tokens — RS256, ES256, PS256 and their siblings — are the norm in production, and verifying them requires the signer's public key, which a client-side tool cannot obtain for you; the decoder says exactly that instead of guessing. Tokens with alg=none, the famously unsafe configuration, are flagged as unsecured with no signature. Expiry and issue-time claims (exp, iat, nbf) appear in their raw epoch form inside the payload JSON, exactly as the token carries them — the tool does not convert or interpret, because silent conversion is where decoders lie. Paste a token from your logs, your network inspector, or your tests and read it as the server would.

Processed locally in your browser

Paste the full token — header.payload.signature.

Verifies HS256/384/512 signatures locally — the secret never leaves your browser.

How is the result calculated?

Reading an ID token from your logs

Your service's access logs contain a token like the RFC 7515 example — a header declaring HS256, a payload with a subject, a name, and an issue time, and a signature segment. Decode it to read the claims as the server would, then paste the shared secret to confirm the signature actually matches — a tampered sub or an expired iat shows up as Signature invalid.

Example input and output
Input Value
token eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
secret your-256-bit-secret
Result {"sub":"1234567890","name":"John Doe","iat":1516239022} — Signature valid

What is the formula and its assumptions?

JWT compact serialization

JWT = base64url(header) + "." + base64url(payload) + "." + base64url(signature)

Formula terms
Symbol Meaning
header the JSON header: alg, typ, and often kid — the signing algorithm and key id
payload the JSON claims: registered (sub, iat, exp, nbf, iss, aud) plus custom claims
base64url base64 with URL-safe characters (- and _) and no padding

RFC 7519 §3.1. The tool decodes segments with base64url and pretty-prints the JSON; it never re-orders or interprets claims.

HMAC signature verification

valid = verify(HMAC-{SHA-256|384|512}(secret), base64url(header.payload), signature)

Formula terms
Symbol Meaning
secret the shared HMAC secret you paste — used only in the browser, never sent
base64url(header.payload) the signing input: the first two segments exactly as carried in the token
signature the third segment, decoded to the raw MAC bytes

crypto.subtle.verify performs a constant-time comparison, so a mismatch can never leak timing. Asymmetric algorithms need the signer's public key and are reported as unverifiable locally.

What are the most common mistakes?

  • Trusting a token because it decodes — decoding shows the claims, not who signed them; only a valid signature check proves origin, and only for HMAC tokens with the right secret.
  • Assuming alg=none tokens were "fine to decode" — they are unsigned and must be rejected by any library that accepts them.
  • Pasting production tokens into online decoders that upload them — this tool is fully local; many web services keep your token and claims.

What are the assumptions and limitations?

  • Signature verification covers HMAC (HS256/384/512) only — asymmetric tokens are reported as unverifiable locally.
  • Claims are displayed raw (epoch seconds for exp/iat/nbf); the tool does not convert them.
  • Opaque access tokens are not JWTs and cannot be decoded.

Where do the numbers come from?

Last reviewed August 12, 2026 · Version 1.0.0 · Toolivaro does not guarantee external content.

Frequently asked questions

Is my token uploaded anywhere?

No. Decoding and signature verification run entirely in your browser with WebCrypto — no network request is made with your token or secret. That makes the tool safe even for production tokens carrying real user claims.

Why can't you verify RS256 tokens?

RS256 and the other asymmetric families are verified with the signer's public key, which lives at the issuer's JWKS endpoint — a client-side tool has no trustworthy way to fetch and trust that key for you. The decoder reports such tokens as unverifiable locally instead of faking a result. HMAC (HS256/384/512) tokens only need the shared secret, so those are checked when you provide it.

What does it mean when a token says alg=none?

alg=none declares the token was not signed at all. Libraries that accept none are the source of infamous authentication bypasses. The decoder flags such tokens as unsecured, with no signature segment to check.

Why are exp and iat shown as raw numbers?

Because that is how the token carries them — NumericDate epoch seconds per RFC 7519. The tool does not silently convert or interpret claims: silent conversion is where decoders lie, and the raw value is the ground truth the server sees.

Can this tool decode OAuth 2.0 access tokens?

Only if they are JWTs. Many providers (Okta, Auth0, Azure AD) issue JWT access tokens, and those decode here. Opaque tokens — random strings that are just identifiers — have no JSON inside and are not JWTs; no decoder can turn those into claims.

Part of Password, hashing, and security tools

Found a mistake or have a correction? Report it — we review every correction.

Was this helpful?

Reviewed by the Toolivaro editorial team per our methodology Methodology · Editorial policy