JWT encoder and decoder
Edit a header and payload, enter a secret and get a signed JSON Web Token instantly. Paste any token below to read its claims and check its signature.
Runs in your browser. Nothing you enter is uploaded.
The payload is only base64url-encoded, not encrypted: anyone with the token can read it. Never put passwords or secrets in it.
Decode and verify
How to use the JWT encoder & decoder
- Edit the Header and Payload JSON; use + iat and + exp to add issued-at and expiry times.
- Enter your secret and choose HS256, HS384 or HS512; the encoded token updates as you type.
- Click Copy to use the token in an API request or a test.
- To inspect a token, paste it under Decode and verify, and add the secret to check its signature.
How is a JWT built?
A JSON Web Token has three parts separated by dots: a header, a payload and a signature. The header and payload are JSON objects encoded with base64url, a URL-safe form of base64 without padding. The header names the signing algorithm, for example {"alg":"HS256","typ":"JWT"}, and the payload carries the claims, such as a user id and an expiry time.
The signature is calculated over the first two parts with the secret. With HS256 that is an HMAC using SHA-256. Anyone can decode the header and payload, but only someone who knows the secret can produce a valid signature, so a server can trust that the claims have not been changed since it issued the token.
What do iat, exp and the other claims mean?
The JWT standard (RFC 7519) defines a few registered claims. sub is the subject, usually a user id; iss is the issuer and aud the intended audience. iat is when the token was issued, exp when it expires and nbf the time before which it is not valid, all as whole seconds since 1 January 1970 UTC. The decoder shows iat and exp as readable dates, so you can see at a glance whether a token has expired.
Choosing a secret
For HS256 the secret should be at least 256 bits long, about 32 random bytes; HS384 and HS512 call for 48 and 64 bytes. A short or guessable secret can be brute-forced from a single token, after which anyone can forge tokens. Generate secrets with a cryptographic random generator, keep them on the server, and use separate test secrets when trying things out in tools like this one.
Frequently asked questions
Is the JWT payload encrypted?
No. A signed JWT is only base64url-encoded, so anyone who has the token can read its payload. The signature protects it from being changed, not from being read. Never put passwords or other secrets in a JWT; if the content itself must be hidden, an encrypted token (JWE) is needed.
What is the difference between HS256, HS384 and HS512?
They all use HMAC with a shared secret but different hash functions: SHA-256, SHA-384 and SHA-512. The longer hashes give longer signatures, 43, 64 and 86 characters respectively. HS256 is by far the most common and is secure with a strong secret.
Does this tool support RS256 or ES256?
No. It signs and verifies HMAC tokens (HS256, HS384, HS512), which use one shared secret. RS256 and ES256 use a private key to sign and a public key to verify; tokens with those algorithms can still be decoded here to read the header and payload, but their signatures are not checked.
Why does my token fail verification?
The most common reasons are a different secret, an algorithm that does not match the header, or a header or payload that changed after signing; even a different amount of whitespace in the JSON produces a different signature. Servers also reject tokens whose exp has passed, so check the expiry shown under the decoded payload.
Is my secret sent anywhere?
No. Signing and verification use your browser's built-in Web Crypto functions, and nothing you type leaves your device. Even so, it is good practice to use test secrets in online tools and keep production secrets only on your servers.