Home/Tools/JWT Decoder

JWT Decoder & Encoder

Decode, verify, and sign JSON Web Tokens — HS, RS, PS, ES, EdDSA. 100% client-side, nothing leaves your browser.

Generate example

Paste a JWT below that you'd like to decode, validate, and verify.

Encoded Token
JSON Web Token (JWT)
Decoded Header
Decoded Payload
JWT Signature Verification (Optional)
Enter the secret used to sign the JWT below:
 Secret
What is a JSON Web Token?
A JSON Web Token (JWT) is an open standard (RFC 7519) for securely transmitting information between parties as a compact, URL-safe string. A JWT consists of three base64url-encoded segments separated by dots: header.payload.signature.
  • Header — declares the token type (typ) and signing algorithm (alg).
  • Payload — carries the claims (statements about the subject). Standard claims include iss, sub, aud, exp, nbf, iat, jti.
  • Signature — proves the token wasn't tampered with. Computed over base64url(header) + "." + base64url(payload) using the chosen algorithm.
What this tool does
  • Decode — Paste any JWT to instantly see its header and payload, with standard claims annotated and time values shown in human-readable form.
  • Verify — Supply a secret (HMAC) or public key (RSA/ECDSA/EdDSA) to cryptographically verify the signature.
  • Encode — Build and sign your own JWTs. Edit the header and payload as JSON, provide a signing key, and copy the resulting token.
  • Generate example — Produce working sample tokens for every supported algorithm to explore how each one looks.
Supported algorithms
  • HMAC — HS256, HS384, HS512 (symmetric secret)
  • RSA PKCS#1 — RS256, RS384, RS512
  • RSA-PSS — PS256, PS384, PS512
  • ECDSA — ES256 (P-256), ES384 (P-384), ES512 (P-521)
  • EdDSA — Ed25519, Ed448 (subject to browser WebCrypto support)
Privacy & security
All decoding, signing, and verification happens locally in your browser using the native Web Crypto API. No tokens or keys are ever sent to our servers. That said, avoid pasting real production tokens into any online tool — tokens are credentials.
Frequently Asked Questions
The decoder runs entirely in your browser using the Web Crypto API — tokens, secrets, and keys are never uploaded, logged, or stored on any server. That said, a JWT is a credential. If a token grants access to a production system, treat it like a password: do not paste it into any online tool, including this one. Use expired tokens, tokens from a test environment, or generate fresh example tokens with the Generate example dropdown.
Paste the token into the Encoded Token panel. The tool automatically decodes the header and payload. To verify the signature, scroll to the JWT Signature Verification section and enter the signing material: an HMAC secret (for HS256/384/512) or a public key in PEM or JWK format (for RS, PS, ES, or EdDSA). The status indicator will turn green if the signature matches, or red if the token has been tampered with or signed with a different key.
HS256 uses HMAC-SHA256 with a shared secret — both parties sign and verify with the same key. Fast and simple, but both sides must trust each other with the secret. RS256 uses RSA-SHA256 with a public/private key pair — only the issuer holds the private key, while anyone with the public key can verify. ES256 uses ECDSA over P-256 — same public/private model as RS256 but produces much shorter signatures and keys, making it a good choice for bandwidth- or storage-sensitive applications.
These are the standard "registered claims" defined in RFC 7519. iss (issuer) identifies who issued the token. sub (subject) identifies whom the token is about. aud (audience) is the intended recipient. exp (expiration time) is a UNIX timestamp after which the token must be rejected. nbf (not before) is the earliest time the token is valid. iat (issued at) is when the token was created. jti (JWT ID) is a unique identifier useful for preventing replay. The Claims Breakdown tab shows these values in human-readable form with annotations.
Technically yes — the encoder produces real, standards-compliant signed tokens. However, in a production system, tokens should be issued by your backend using a private key that never leaves the server. Use this tool for learning, debugging, generating test tokens, or verifying that a third party's tokens decode correctly — not as part of an authentication flow.
The decoder checks the exp claim against the current UTC time in your browser. If exp is in the past, the token is flagged as expired — even if the signature is valid. Expired tokens should be rejected by any well-behaved server. If you need to inspect an expired token, the decoded header and payload are still visible; only the validity status changes.