JWT Decoder & Encoder — Decode, Verify and Sign JSON Web Tokens

Decode a JWT's header and payload, read the expiry in plain language, verify HS, RS, PS and ES signatures, or sign a new token. Nothing leaves your browser.

Token

Header

{
  "alg": "HS256",
  "typ": "JWT"
}

Payload

{
  "sub": "user_42",
  "name": "Ada Lovelace",
  "role": "admin",
  "iat": 1757320000,
  "exp": 1788856000
}

Claims

sub	Subject	user_42
name		Ada Lovelace
role		admin
iat	Issued at	1757320000
exp	Expires	1788856000

Verify signature (HS256)Secret is Base64 / Base64URL encoded

The example token is signed with the secret demo-secret-do-not-use.

Decoding never checks the signature: anyone can read a JWT, only the signature proves who issued it. HS* tokens need the shared secret; RS*, PS*, ES* and EdDSA need the issuer's public key (PEM, certificate, JWK, or the JWKS from its /.well-known/jwks.json, matched by kid). Do not paste production secrets or private keys into any web page, this one included; use test keys.

Tokens and keys are processed in your browser with WebCrypto and never sent anywhere; still, treat a pasted production token or key as a credential. Browse all free tools.

Found a problem, or something that could be better? We read every message and we fix things quickly.

This free JWT decoder shows the header, payload and claims of a JSON Web Token, turns exp, iat and nbf into readable dates with a clear valid or expired verdict, verifies the signature (HMAC with a secret, or RSA, RSA-PSS, ECDSA and Ed25519 with a public key, certificate or JWK), and has an encoder that signs new tokens for testing. Everything happens in your browser, which matters here more than for most tools: a pasted token is often a live credential, and it should not be sent to anyone's server, including ours.

A JWT is three Base64URL sections separated by dots: a header naming the algorithm, a payload of claims, and a signature. The first two are not encrypted, only encoded, so anyone can read them; the signature is what proves who issued the token and that it was not altered. Decoding is therefore not the same as trusting, and the page keeps that distinction visible.

How to use

Paste the token. A leading “Bearer ” from an Authorization header is fine; it is stripped.
Read the status line: valid for how long, expired since when, or not yet valid.
Check the payload and the claims table. Time claims are shown as local dates alongside the raw Unix seconds.
To verify, press Verify after entering the key: the shared secret for HS256/384/512, or for RS, PS, ES and EdDSA tokens the issuer's public key as PEM, certificate, JWK or the whole JWKS (the key is picked by the token's kid).
To create a token, switch to Encode & sign, pick the algorithm, edit the header and payload JSON, and enter a secret or paste a PKCS#8 private key (or generate a test key pair). Sign, then open it in the decoder to verify.
Copy the payload or header as formatted JSON if you need it in a bug report or a test fixture.

Frequently asked questions

Is it safe to paste a real token here?

The token is decoded with JavaScript in your browser and is never transmitted; you can disconnect from the internet and the page keeps working. That said, treat a production token like a password: do not paste it into any page you do not trust, and prefer a short-lived test token when you can.

Why can I read the payload without the secret?

Because JWTs are signed, not encrypted. The payload is Base64URL-encoded JSON that anyone can decode. The secret (or private key) is only needed to create or verify the signature. Never put sensitive data in a JWT payload unless you are using JWE, the encrypted variant, which this tool does not decode.

What do exp, iat and nbf mean?

They are Unix timestamps in seconds. exp is when the token expires; iat is when it was issued; nbf (not before) is the earliest moment it is valid. A verifier must reject a token after exp or before nbf. The status line here applies both rules to the current time.

How do I verify an RS256 or ES256 token?

You need the issuer's public key, never the private one. Identity providers publish it as a JWKS at a URL such as https://issuer/.well-known/jwks.json (Auth0, Okta, Cognito, Azure AD and Google all do). Paste the whole JWKS and the key whose kid matches the token header is used, or paste a single JWK, a PEM public key (BEGIN PUBLIC KEY) or an X.509 certificate. The page fetches nothing itself, so copy the JWKS from your browser.

Can I create and sign a JWT here?

Yes. Encode & sign takes header and payload JSON and signs with HS256/384/512 and a secret, or with RS, PS, ES or EdDSA and a private key in PKCS#8 PEM format (BEGIN PRIVATE KEY). Older BEGIN RSA PRIVATE KEY files are PKCS#1; convert them with openssl pkcs8 -topk8 -nocrypt -in key.pem. Use test keys only: a production signing key pasted into any web page should be considered compromised.

What does “alg: none” mean and why the warning?

It declares the token has no signature. Some libraries historically accepted such tokens as valid, which let attackers forge any payload. A properly configured verifier rejects alg none outright. If you see it in a real system, that is a security finding, not a curiosity.

Anatomy of a JWT

Header: {"alg":"HS256","typ":"JWT"} tells the verifier which algorithm signed the token. Payload: the claims, a JSON object of whatever the issuer chose to include, plus the registered claims (iss, sub, aud, exp, nbf, iat, jti) that verifiers understand. Signature: HMAC or a digital signature over base64url(header).base64url(payload). Change one character of the payload and the signature no longer matches, which is the whole point.

Common JWT mistakes

• Trusting the payload without verifying the signature, or verifying with the algorithm named in the token rather than the one the server expects (algorithm confusion).

• Long-lived access tokens. Keep exp short (minutes to an hour) and use a refresh token for longer sessions.

• Putting personal or secret data in the payload; it is readable by anyone who holds the token.

• Storing tokens in localStorage on a site with any XSS exposure. An httpOnly cookie is safer for browser sessions.

• Forgetting to check aud and iss, which lets a token issued for one service be replayed against another.

• HMAC secrets that are too short or human-chosen. HS256 needs at least 256 bits (32 random bytes); a guessable secret can be brute-forced offline from a single token.

Which signing algorithm to choose

• HS256 (HMAC-SHA256): one shared secret both signs and verifies. Simple and fast, but every service that verifies can also mint tokens. Fine inside one backend.

• RS256 (RSA PKCS#1 v1.5 with SHA-256): the most widely supported asymmetric option; the issuer keeps the private key, everyone else verifies with the public key. Signatures are 256 bytes with a 2048-bit key.

• PS256 (RSA-PSS): same keys as RS256 with a more modern padding scheme; use it when every consumer supports it.

• ES256 (ECDSA P-256): much smaller keys and 64-byte signatures with comparable security; common in newer systems and required by some (Apple, WebAuthn-adjacent APIs).

• EdDSA (Ed25519): fast, deterministic signatures, increasingly supported by libraries; browser support arrived later than the others.

Related free tools

Base64 Encoder / Decoder — Encode text or files to Base64, turn images into data URIs with CSS and <img> snippets, and decode Base64 back to a previewable file. Nothing leaves your browser.
JSON Formatter — Pretty-print, minify and validate JSON, with parse errors located by line and column. In your browser, no upload.
Password Generator — Generate a strong random password, a memorable passphrase or a PIN. Runs entirely in your browser, nothing is sent or stored.