JWT Decoder — Decode, Verify, and Generate

Decode, verify, and generate JSON Web Tokens in your browser. HMAC HS256/384/512 and RS256 with a PEM key. Secrets never leave this page.

Reviewed by Olgun Ozoktas

JWT Token

0 characters0 parts

Decoded

Enter a JWT token above to decode it

Decoding, verify, and sign all run in this browser. This page does not send the token, secret, or PEM to a server.

How to decode, verify, and generate a JWT

  1. 1

    Paste and decode the token

    Open the Decode tab and paste a JWT. The tool splits the three Base64URL segments and shows the header, payload, and signature. The exp claim is converted to ISO 8601. Decode does not prove the signature is valid.
  2. 2

    Verify HMAC (HS256, HS384, or HS512)

    Open the Verify tab and paste the shared secret. The tool reads alg from the header and checks the HMAC with Web Crypto. A matching signature shows as verified. A wrong secret shows as failed.
  3. 3

    Verify RS256 with a PEM key

    For RS256 tokens, paste an SPKI public key or a PKCS8 private key in PEM form. The tool imports the key in the browser and checks the RSA signature. Algorithm none always fails, even if a key is present.
  4. 4

    Generate a signed token

    Open the Generate tab. HS256, HS384, and HS512 need an HMAC secret. RS256 needs a PKCS8 PEM private key, or use Create test RSA key pair. Open the result in Decode, then verify it with the same secret or public key.

Common Use Cases

1

Debugging Authentication Flows

When login or API requests fail with 401 or 403 errors, decoding the JWT reveals whether claims like exp, aud, or iss contain the expected values. Then verify the signature with the real secret or public key before you change server code.
2

Inspecting API Gateway Tokens

API gateways attach JWTs to requests. Decode these tokens to inspect scopes and roles, then verify HS256 or RS256 with the gateway key so you know the token was not rewritten in transit.
3

Creating test tokens

Generate HMAC or RS256 tokens with known claims and expiration, then paste them into local API calls. Keep the secret or private key on this page only.
4

Rejecting unsigned tokens

If the header alg is none, this page refuses to mark the token as verified. That matches the rule a production verifier must also enforce.

Why use this JWT decoder?

Decode a JSON Web Token, verify its signature with an HMAC secret or RSA public key, and generate HS256, HS384, HS512, or RS256 tokens. Expiration claims display as ISO 8601 timestamps. Signature stays unverified until you run Verify. All of this runs in your browser.

JSON Web Tokens (JWTs) are the standard mechanism for transmitting identity and authorization data in modern web applications. Every time a user logs in through OAuth 2.0, OpenID Connect, or a custom authentication system, the server issues a JWT that the client attaches to subsequent requests. This page lets you paste any signed JWT and view its three parts: the header that specifies the signing algorithm, the payload that carries claims about the user, and the signature. Expiration displays as ISO 8601. Processing happens entirely in your browser, so tokens, secrets, and PEM keys are never transmitted over the network.

Decoding is not verification. A decoded payload can be read by anyone who has the token. A valid signature is the only proof that the issuer signed those bytes. Open the Verify tab and supply an HMAC secret for HS256, HS384, or HS512, or a PEM public key for RS256. Algorithm none always fails. Generate HMAC tokens, or sign RS256 with an imported PKCS8 private key, then inspect the result on Decode. Pair this page with the Base64 Encoder to inspect individual segments, the JSON Formatter for nested claims, or the Unix Timestamp Converter to cross-check date claims.

Whether you are a backend developer troubleshooting a microservices authorization chain, a frontend engineer verifying scopes after login, or a security auditor reviewing token policies, this page takes a raw token string to decoded claims and a real signature check without sending keys off the device.

How It Compares

Many JWT pages decode the header and payload and then label the token valid. That label is wrong until a key is checked. This page keeps decode honest: the signature stays unverified until you run Verify. Verify uses Web Crypto HMAC for HS256, HS384, and HS512, and Web Crypto RSASSA-PKCS1-v1_5 for RS256. Secrets and PEM keys stay in the browser.

Command-line tools can decode Base64URL and check HMAC, but they require extra steps for timestamps and RSA PEM import. This page does those steps in one view, with ISO 8601 expiration and a clear verified or failed result.

Tips for Working with JWTs

1
Never share a valid JWT publicly. Even though the payload is only Base64URL-encoded (not encrypted), a valid signature lets anyone use the token until it expires.
2
Check the exp claim first when debugging. This decoder converts the Unix timestamp to ISO 8601 so you can see whether the token is expired.
3
Use short expiration times for access tokens (5 to 15 minutes) and longer lifetimes for refresh tokens. Generate both and inspect the exp values.
4
The alg field in the header should never be none in production. This page fails verify for none even if you paste a secret.
5
Verify RS256 with the public key, not the HMAC secret. Do not treat a PEM file as an HMAC secret.

Frequently Asked Questions

1

What is a JWT?

A JSON Web Token (JWT) is a compact, URL-safe token format used for transmitting information between parties. It consists of three parts: header, payload, and signature, each separated by a dot and encoded in Base64URL format.
2

Is my token secure when using this tool?

Decoding, signature verify, and signing run in your browser. The token, HMAC secret, and PEM key are not sent to a server and are not logged. You can disconnect from the network after the page loads and still use the tool.
3

Can this tool verify JWT signatures?

Yes. Open the Verify tab. HS256, HS384, and HS512 use an HMAC secret. RS256 uses an SPKI public key or a PKCS8 private key in PEM form. The check uses Web Crypto in the browser. Algorithm none always fails, even if a secret is present.
4

What do the common JWT claims mean?

Registered claims include sub (subject identifier), iat (issued at timestamp), exp (expiration timestamp), nbf (not before), iss (token issuer), aud (intended audience), and jti (unique token ID). Custom claims can contain any application-specific data.
5

Why are some timestamps shown as ISO dates?

Standard JWT timestamp claims like iat, exp, and nbf are stored as Unix epoch seconds. This tool converts those fields to ISO 8601 so you can see the exact expiration without a timezone guess from the local clock display.
6

What does the alg field in the header mean?

The alg field specifies the cryptographic algorithm used to sign the token. This page verifies HS256, HS384, HS512, and RS256. The algorithm none means the token is unsigned and never verifies as valid on this page.
7

Can I decode an expired JWT?

Yes. Expiration only affects whether a server should accept the token. The decoder reads any structurally valid JWT and flags expired when exp is in the past. You can still run Verify on an expired token.
8

What is the difference between decoding and decrypting a JWT?

Decoding a JWT means Base64URL-decoding the header and payload, which does not require a key. Decrypting applies to JWE tokens where the payload is encrypted. This tool handles standard signed JWTs (JWS), not encrypted JWE tokens.
9

How do I know if my JWT has been tampered with?

Open the Verify tab and supply the HMAC secret or RSA public key that the issuer used. If the signature does not match the header and payload bytes, the token was altered or the key is wrong. Decode alone cannot detect tampering.
10

What is the maximum size a JWT can be?

This page rejects tokens larger than 32 KB and keys larger than 16 KB. Tokens are typically sent in HTTP headers, which most servers cap at 8 KB. Keep payloads small and store only essential claims.

Rate This Tool

0/1000

Get Weekly Tools

Suggest a Tool