Client-Side Only — Your JWT tokens are decoded entirely in the browser. No data is sent to any server.

JWT Decoder

Signature Verification

Header

Decoded header will appear here...

Payload

Decoded payload will appear here...

Signature

Signature will appear here...

Real-time Decoding

Instantly decode JWT tokens as you type with debounced processing.

100% Client-Side

Your tokens never leave the browser. Completely private and secure.

Signature Verification

Verify HMAC signatures (HS256/384/512) using the Web Crypto API.

About the JWT Decoder

The JWT Decoder splits a JSON Web Token (RFC 7519) into its three Base64URL-encoded segments — header, payload, and signature — and renders the header and payload as readable JSON, all inside your browser. Paste a token from an Authorization header, an OAuth response, or a debugging log, and the decoder shows the algorithm, claims, expiry, and any custom fields without sending the token to a server. Optional signature verification accepts a public key (RS256/ES256/EdDSA) or a shared secret (HS256) and runs the check via Web Crypto, so even production tokens stay on your device while you confirm whether the signature is valid.

Updated: May 8, 2026

Related Tools

HTTP Header CheckerInspect Authorization, WWW-Authenticate, and other auth-related response headers.Try it Base64 EncoderJWT segments are Base64URL — decode them manually when you need the raw bytes.Try it Hash GeneratorHMAC-SHA-256 is the algorithm behind HS256 — generate matching digests inline.Try it OTP GeneratorTOTP codes are often the second factor whose successful check produces a JWT.Try it cURL ConverterGenerate code that attaches a JWT to the Authorization header in 21 languages.Try it

How to use the JWT decoder

  • Paste the JWT (three Base64URL segments separated by dots, e.g., `eyJhbGciOi...eyJzdWIiOi...sBL5z3...`) into the input area.
  • The header and payload panels render the decoded JSON immediately, with claim names highlighted (`iss`, `sub`, `aud`, `exp`, `iat`, `nbf`, `jti`).
  • Inspect the `alg` field in the header — JWS algorithms are listed in RFC 7518 (HS256, RS256, ES256, EdDSA, etc.). Reject `none` and `HS*` when you expected an asymmetric algorithm.
  • Optional signature verification: paste the matching key (an HMAC secret for HS algorithms, a PEM-formatted public key for RS/ES/EdDSA) and the verifier runs through `crypto.subtle.verify` for a green or red badge.
  • Copy individual claims, the full decoded JSON, or the canonicalized JWT back to your clipboard with one click.

Common use cases

  • Debugging an authentication flow. Inspect the `exp`, `iat`, and `nbf` claims when a service rejects a token; clock-skew issues and short-lived tokens that expire mid-flight are the two most common causes.
  • Verifying token issuer and audience. Confirm that `iss` matches your identity provider and `aud` matches your intended resource server before you trust the rest of the payload.
  • Inspecting OAuth 2.0 / OIDC tokens. Access tokens, ID tokens, and refresh tokens issued by Auth0, Okta, AWS Cognito, Keycloak, and similar IdPs are JWTs whose claims tell you exactly what scopes and identities are encoded.
  • Pen-test and security review. Audit the `alg` field for `none` algorithm acceptance (CVE-2015-9235), check for the `kid` header injection pattern, and confirm that signing keys rotate as documented.
  • Learning the JWT spec. Decoding a real token alongside RFC 7519 (JWT), RFC 7515 (JWS), and RFC 7518 (JWA) is the fastest way to internalize the structure and the standard claim names.

Privacy and security

Decoding runs entirely in your browser via standard string splitting and `atob` (with UTF-8 fixup for non-ASCII payloads). Signature verification uses `crypto.subtle.verify` from the Web Crypto API — the same primitive that powers TLS in your browser. Tokens, signing keys, and decoded claims never leave the page; no analytics, no logging, no proxy. The URL is not auto-updated with the token, so refreshing the tab clears the input. You can decode production tokens here without exposing them to a third party.

Tips and pitfalls

  • Reject `alg: none`. The `none` algorithm — defined in RFC 7515 § 3.6 for unprotected JWS — is a legitimate part of the spec but a catastrophic vulnerability if your verifier accepts it on user input. Every mainstream JWT library has had a CVE for this exact mistake.
  • Algorithm confusion (HS256 vs RS256). If the verifier accepts both and uses the same key field, an attacker can sign a token with the public key as an HMAC secret. Pin the algorithm at verification time.
  • `exp` is seconds-since-epoch, not milliseconds. Off-by-1000 errors silently accept expired tokens or reject valid ones.
  • `kid` injection. The `kid` header lets servers select which key to use; if the server passes `kid` directly into a file path or SQL query, classic injection vulnerabilities apply.
  • JWTs are signed, not encrypted. The payload is Base64URL-encoded plaintext; never put secrets, PII, or credentials in a JWT unless you are using JWE (RFC 7516). Use opaque session tokens when you need server-side revocation.

Frequently Asked Questions

What is a JWT and how is it structured?
A JSON Web Token (RFC 7519) is three Base64URL-encoded segments separated by dots: header (algorithm + token type), payload (claims), and signature. The signature is computed over the first two segments using the algorithm declared in the header. The whole thing is meant to be a compact, URL-safe credential that a client carries on every request.
How is a JWT different from a session cookie?
A session cookie is an opaque identifier that the server resolves against a database; a JWT carries the claims directly inside the token. JWTs scale horizontally without a session store but cannot be revoked server-side without an extra deny-list, which is why they are best paired with very short expiry windows (5-15 minutes for access tokens) plus a longer-lived refresh token.
Are JWTs encrypted?
JWS-style JWTs (the common kind) are signed but not encrypted — the payload is plaintext to anyone who can read the token. JWE (RFC 7516) is the encrypted variant; if you need confidentiality of the payload, use JWE rather than putting secrets in a JWS payload.
What is the difference between `exp`, `iat`, and `nbf`?
`iat` is issued-at (when the token was created), `nbf` is not-before (the earliest time the token is valid), and `exp` is expiry. All three are NumericDate values per RFC 7519 § 2 — seconds since the Unix epoch, not milliseconds. Verifiers should reject tokens where the current time is outside [`nbf`, `exp`].
Which algorithm should I use — HS256, RS256, or EdDSA?
HS256 is fine for single-tenant systems where the same party issues and verifies tokens (the shared secret is a private deployment detail). For multi-tenant or distributed systems prefer RS256 or, ideally, EdDSA — they let consumers verify signatures with a public key without ever holding the signing key. EdDSA (Ed25519) is faster and produces shorter signatures than RS256.
How should I handle refresh tokens?
Issue a short-lived (5-15 minute) JWT access token alongside an opaque, server-revocable refresh token stored in an HttpOnly cookie. When the access token expires, the client exchanges the refresh token for a new access token. Refresh-token rotation (one-time-use refresh tokens) further limits the blast radius of a stolen refresh token.
What are the most common JWT vulnerabilities?
`alg: none` acceptance, algorithm confusion (HS vs RS with the same key field), `kid` parameter injection, and weak HMAC secrets. The OWASP API Security Top 10 and the JWT BCP (RFC 8725) are the canonical references for hardening a verifier.
When should I NOT use JWTs?
When you need instant server-side revocation, when the payload is large enough that carrying it on every request becomes a bandwidth concern, or when the client cannot be trusted with the token at all (use opaque session IDs instead). For short-lived authentication tokens between cooperating services, JWTs are an excellent fit.
Does the decoder verify the signature?
Yes — paste the matching key (HMAC secret for HS*, PEM public key for RS/ES/EdDSA) and the verifier runs `crypto.subtle.verify`. The verification result is a green or red badge. Verification is optional — the decoder will display claims even without a key.