~/jwt-decoder

JWT Decoder

Decode, inspect and verify JSON Web Tokens. HS256 signature verification supported. Everything runs in your browser — your tokens are never sent anywhere.

jwt token
// how to use

Decode a JWT in three steps.

  1. 01Paste your token into the JWT input.Use the “load sample” button to try the tool with an example HS256 token, or paste any token in the standard header.payload.signature format.
  2. 02Inspect the decoded sections.The header reveals the algorithm and token type. The payload shows all claims with timestamps converted to readable dates. The signature is the cryptographic proof.
  3. 03(Optional) Verify the signature.For HS256 tokens, paste the secret used by the issuer. The tool computes the expected signature locally and compares it to the one in the token.
// background

What is a JWT, and how does it actually work?

A JSON Web Token (JWT) is a compact, self-contained way to transmit signed data between two parties. Defined in RFC 7519, it's the most common format for stateless authentication tokens in modern web applications and APIs.

A JWT is made of three Base64-URL encoded parts joined by dots: header.payload.signature. The header declares the signing algorithm. The payload carries the claims (data about the user, expiration, etc). The signature is computed over the header and payload, allowing the receiver to verify the token hasn't been altered.

Crucially, a JWT is signed, not encrypted. Anyone holding the token can decode and read its payload — that's exactly what this tool does. The signature only proves authenticity, not confidentiality. Never put secrets inside a JWT payload.

Standard registered claims

issIssuerWho created and signed the token
subSubjectWhom the token is about (often a user ID)
audAudienceWhom the token is intended for
expExpirationTimestamp after which the token is invalid
nbfNot beforeTimestamp before which the token is invalid
iatIssued atWhen the token was created
jtiJWT IDUnique identifier, useful to prevent replay

Common JWT pitfalls

  • ×Accepting tokens with alg=none — always reject these
  • ×Storing secrets in the payload (it's readable by anyone)
  • ×Using long-lived tokens without refresh tokens
  • ×Confusing JWT signing keys with API keys — they're not the same
  • ×Trusting the alg header without enforcing it server-side (algorithm confusion attacks)
  • ×Putting personal data in tokens that get logged or cached
// faq

Frequently asked questions.

Is it safe to paste my JWT here?+
Yes. All decoding and verification runs entirely in your browser using the native Web Crypto API. Your tokens are never sent to any server, logged, or stored. You can verify this by opening the browser's network tab — no requests are made when you decode a token.
Why is my JWT signature showing as invalid?+
Three common reasons: the secret you entered doesn't match the one used to sign the token, the token has been tampered with after signing, or the token uses an algorithm we don't yet verify (RS256, ES256). For HS256 tokens, double-check that you're using the exact same secret string the issuer used.
Does this tool support RS256, ES256, or other asymmetric algorithms?+
Currently only HS256 (HMAC with SHA-256) signature verification is supported. RS256 and ES256 (which require pasting a public key or certificate) are on the roadmap. You can still decode tokens signed with these algorithms — only the verification step is limited.
What does 'alg: none' mean?+
It means the token has no signature. The 'none' algorithm exists in the JWT specification but is dangerous: a server that accepts 'alg: none' tokens has effectively no authentication. Reject any token with alg=none in production.
What is the difference between a JWT and a JWS?+
JWS (JSON Web Signature) is the underlying signed-payload format. A JWT (JSON Web Token) is a specific use of JWS where the payload is a JSON object containing claims. In casual usage, the terms are often interchangeable. JWE (JSON Web Encryption) is a different, encrypted variant that this tool does not currently decode.
Why do exp, iat, and nbf use Unix timestamps?+
The JWT spec (RFC 7519) defines these as NumericDate values — seconds since Unix epoch in UTC. This avoids timezone ambiguity and keeps tokens compact. The decoder shows both the raw timestamp and the human-readable UTC date for convenience.
// related

You might also need:

JSON Formatter

Beautify payloads.

Base64

Encode binary data.

UUID Generator

Generate identifiers.