JWT Decoder & Encoder

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).
• Signature - proves the token wasn't tampered with.

What this tool does

• Decode - Paste any JWT to instantly see its header and payload.
• Verify - Supply a secret (HMAC) or public key (RSA/ECDSA/EdDSA) to cryptographically verify the signature.
• Encode - Build and sign your own JWTs.

Supported algorithms

• HMAC - HS256, HS384, HS512
• RSA PKCS#1 - RS256, RS384, RS512
• RSA-PSS - PS256, PS384, PS512
• ECDSA - ES256, ES384, ES512
• EdDSA - Ed25519, Ed448 (subject to browser WebCrypto support)

How to use the decoder

1. Paste a token into Encoded Token. Spaces and line breaks are removed automatically, and the three parts are coloured so you can see where each one starts.
2. Read the Decoded Header and Decoded Payload. Switch either panel to Claims Breakdown for a table that names each standard claim and shows time claims as a readable UTC date.
3. Check the status line under the token. It confirms the structure, and warns when exp is in the past or nbf is still in the future.
4. To verify, paste the HMAC secret or, for RS, PS, ES and EdDSA tokens, the PEM public key into the verification box. Turn on BASE64URL ENCODED if your secret is stored in that form. The result reads Signature Verified or Invalid Signature.
5. Use the JWT Encoder tab to edit a header and payload and sign a new token, or pick an algorithm under Generate example to get a ready-made token with a matching secret or key pair.

Anatomy of a real token

The header {"alg":"HS256","typ":"JWT"} encoded with base64url is eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9. The payload {"sub":"1234567890","name":"John Doe","admin":true,"iat":1516239022} becomes eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImlhdCI6MTUxNjIzOTAyMn0. The signature is an HMAC-SHA256 of those two strings joined by a dot, computed with the secret, and encoded the same way. The iat value is a count of seconds since 1 January 1970, so 1516239022 means 18 January 2018 at 01:30:22 UTC.

Decoding is not verifying

Base64url is an encoding, not encryption. Anyone who holds a JWT can read its payload in seconds, exactly as this page does, so never put passwords, card numbers or other secrets in a claim. Reading a token also proves nothing about who issued it. Only checking the signature with the right key shows that the header and payload have not been changed. A server that accepts a token should verify the signature, reject tokens whose alg it does not expect (including none), and check exp, iss and aud before trusting any claim.

Common mistakes

• Milliseconds instead of seconds - exp, nbf and iat are in seconds. A 13-digit value usually means someone used Date.now() without dividing by 1000.
• Wrong key format - verification expects a public key in the BEGIN PUBLIC KEY PEM form, and signing expects a private key in the BEGIN PRIVATE KEY (PKCS#8) form. Keys labelled BEGIN RSA PRIVATE KEY or BEGIN EC PRIVATE KEY need converting first, and JWK keys are not accepted here.
• Encoded versus plain secret - if your server stores the HMAC secret in base64url, the same characters typed as plain text form a different key and the check fails.
• Short HMAC secrets - for HS256, use a random secret of at least 32 bytes. A short or guessable secret can be brute-forced offline from any captured token.

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. Even so, treat a live production token like a password, and prefer test tokens when you can.