JWT Decoder, Generator & Verifier

About JWT Decoder, Generator & Verifier

JWT Decoder, Generator & Verifier splits a token into its header and payload, renders the time claims as readable timestamps, verifies a signature against a key you supply, and signs a payload of your own for testing. Decoding needs no key at all, which is the single most important fact about the format.

A JSON Web Token is three Base64URL segments joined by dots: a header naming the algorithm, a payload of claims, and a signature over the first two. The first two are encoded, not encrypted, so anyone holding the token can read every claim in it. The signature proves something narrow but valuable: whoever created the token held the key, and neither segment has changed since. Everything else, the issuer being the one you expect, the audience matching, the token still being within its window, is policy your application has to check.

How to use this developer tool

Choose Decode to inspect a token, Verify to check a signature, or Sign to build a test token from a payload.
Paste the token into the left pane. In sign mode that pane holds the claims JSON instead.
For verify and sign, pick the algorithm that matches the token header, then choose the key format: text, Base64, or hex for HS algorithms, and PEM or JWK for RS, PS, ES, and EdDSA.
Paste the shared secret or the key into the key field below the panes.
Run the action and read the result: decoding adds a timeClaims block with iat, nbf, and exp converted to ISO timestamps.

Worked example: decoding without a key

A real HS256 token. No secret was supplied, and every claim is still readable, which is exactly the point.

Token

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkRldiBUb29scyIsInJvbGUiOiJlZGl0b3IiLCJpYXQiOjE3NzAwMDAwMDAsImV4cCI6MTc3MDAwMzYwMCwiaXNzIjoiaHR0cHM6Ly9hdXRoLmV4YW1wbGUuY29tIiwiYXVkIjoiYXBpOi8vcmVwb3J0cyJ9.eJqfDF6kCs5lS3B-IoYdxY4V5azCgcxZStnJtWQl3Nc

Decoded

{
  "header": {
    "alg": "HS256",
    "typ": "JWT"
  },
  "payload": {
    "sub": "1234567890",
    "name": "Dev Tools",
    "role": "editor",
    "iat": 1770000000,
    "exp": 1770003600,
    "iss": "https://auth.example.com",
    "aud": "api://reports"
  },
  "timeClaims": {
    "iat": "2026-02-02T02:40:00.000Z",
    "exp": "2026-02-02T03:40:00.000Z"
  }
}

The role claim was read without any key, so a token in a screenshot or a log leaks whatever it contains. The timeClaims block also shows this token expired one hour after it was issued; verifying it today fails with an exp claim timestamp check, before the signature result even matters.

Registered claims and header parameters

The claims in RFC 7519 are optional by specification and mandatory by good sense. The last rows are header parameters rather than claims.

Name	Meaning	Type	What to check
iss	issuer	string or URI	Must equal the issuer you configured, exactly
sub	subject	string	The principal; unique and stable within the issuer
aud	audience	string or array	Your service must be in it, or reject the token
exp	expiration time	seconds since epoch	Reject after this instant, allowing small clock skew
nbf	not before	seconds since epoch	Reject before this instant
iat	issued at	seconds since epoch	Useful for age limits and replay windows
jti	JWT ID	string	Unique id, the hook for one-time-use tracking
alg	algorithm (header)	string	Pin the expected value; never take it from the token
kid	key id (header)	string	Selects the key from a JWKS document

Troubleshooting

The token decodes but verification says signature verification failed.

Why it happens Almost always the key, not the token. A shared secret stored as Base64 or hex and typed as plain text produces different bytes, and a trailing newline copied with the value changes the key too.

Fix Set the key format selector to match how the secret is stored: text, Base64, or hex. Compare the byte length of the key you pasted with what the issuing service configured.

Verification fails with an algorithm not allowed error.

Why it happens The algorithm you selected differs from the alg in the token header, and verification is deliberately restricted to the algorithm you named.

Fix Decode the token first and read header.alg, then select exactly that. In your own services, pin the accepted algorithms server-side; accepting whatever the header claims is the classic JWT vulnerability.

An RS256 token will not verify with a key that works elsewhere.

Why it happens Verification needs a public key in SPKI PEM form, beginning with BEGIN PUBLIC KEY, or a JWK. A certificate, a PKCS#1 key beginning with BEGIN RSA PUBLIC KEY, or a private key cannot be imported for verification.

Fix Extract the public key with openssl x509 -in cert.pem -pubkey -noout, or copy the matching JWK object out of the provider's JWKS document and select the JWK key format.

A token from an identity provider cannot be decoded at all.

Why it happens It is not a signed JWT. Tokens with five segments are encrypted JWEs, and many providers issue opaque reference tokens that only look like random strings. A value copied from a URL may also still be percent-encoded.

Fix Count the dots: two means a JWS you can decode here. Decode percent-encoded values with the URL tool first. Opaque tokens can only be inspected through the provider's introspection endpoint.

Verification succeeds, yet the request is still rejected by the API.

Why it happens A valid signature says nothing about issuer, audience, scope, or revocation. The API is applying policy that the signature check does not cover.

Fix Compare iss and aud against what the API expects, check that the required scopes or roles are present, and confirm the token was not revoked on the server side.

When this tool is the right choice

Reading the claims of a token attached to a bug report without asking anyone for a key.
Converting exp, nbf, and iat into readable timestamps to explain why a session ended when it did.
Confirming during an integration that a public key or JWKS entry really validates the tokens a provider issues.
Generating a test token whose claims match what your application expects, including a deliberately expired one.

When to use something else

Anything involving a production signing key. Keep those in a key management service and sign there.
Deciding whether a token should be trusted. That requires issuer, audience, scope, and revocation policy, which verification does not cover.
Reading encrypted JWE tokens or opaque provider tokens; neither is a signed JWT and neither can be decoded without the provider.

Privacy and data handling

Decoding, verification, and signing all run in this browser tab through the Web Crypto API; the key you paste lives in the memory of the page and is discarded when you leave. Nothing is uploaded. That is a statement about transport, not about exposure: a production signing secret should never leave the system that holds it, so prefer a test key and a redacted token.

Related developer tools

Frequently asked questions

Does decoding a JWT verify it?

No. Decoding reverses Base64URL and parses JSON, which anyone can do with no key. Verification recomputes or checks the signature with a key and a pinned algorithm, and only then do the claims mean anything.

If anyone can read the payload, what stops them editing it?

The signature. Changing one character in the header or payload invalidates it, and forging a new signature requires the key. That is the entire security model, which is why the alg header must never be trusted blindly.

Which key formats are accepted?

For HS256, HS384, and HS512 a shared secret as text, Base64, or hex. For RS, PS, ES, and EdDSA algorithms, a PEM private key when signing, a PEM public key when verifying, or a JWK object in either direction.

Can I verify against a JWKS URL?

No, the tool never makes a network request. Open the provider's JWKS document yourself, copy the single JWK whose kid matches the token header, and paste that object with the JWK format selected.

Why can I generate a token with alg none?

Because it is useful as a test case. A token with alg none carries no signature at all; any service that accepts one is vulnerable, and generating one is the fastest way to prove that yours does not.

Should personal data go into a JWT?

No. The payload is readable by anyone who obtains the token, including proxy logs and anything that captures a URL. Keep claims to identifiers and authorization facts.