A JWT (JSON Web Token) is a compact, URL-safe token used to securely transmit information between parties as a JSON object. It contains a header, payload, and signature separated by dots.

How do I decode a JWT token online?

Paste your JWT token into Just Formatter's JWT decoder. It instantly shows the decoded header, payload claims, and signature — no installation or account needed.

What is the difference between HS256 and RS256 in JWT?

HS256 uses a shared HMAC secret for both signing and verification — all parties must know the same secret. RS256 uses an RSA private key to sign and a public key to verify — the signer and verifier can be different parties. RS256 is preferred for public APIs where the resource server should not know the signing secret.

Is it safe to paste my JWT token into an online decoder?

Just Formatter decodes JWT tokens entirely in your browser using JavaScript. Your token is never sent to our servers. For sensitive production tokens, this browser-only approach is safe.

What does exp mean in a JWT payload?

The exp claim is the expiration time — a Unix timestamp (seconds since epoch) after which the token is no longer valid. Just Formatter displays it as a human-readable date and tells you whether the token is currently expired.

JWT Decoder

Free Online JWT Decoder & Token Analyzer

Paste a JWT and instantly read its decoded header algorithm, all payload claims, expiry timestamp, and issuer. The decoder works with any JWT regardless of signing algorithm — HS256, RS256, ES256, and others. No keys are required for decoding; only signature verification requires a secret.

JWTs are decoded entirely in your browser using JavaScript — your token is never sent to a server. Expiry times are displayed as human-readable dates so you can immediately see whether a token is still valid without parsing Unix timestamps manually.

What this tool does

✓Decode header, payload, and signature
✓Show algorithm (HS256, RS256, etc.)
✓Display exp, iat, nbf as readable dates
✓Show token expiry status instantly
✓All decoding runs in your browser

JWT Token Structure: Header, Payload, Signature

A JWT is three Base64url-encoded strings joined by dots: header.payload.signature. Each part serves a specific purpose.

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c3IxMjMiLCJuYW1lIjoiQWxpY2UiLCJpYXQiOjE3MTY4MjA4MDAsImV4cCI6MTcxNjgyNDQwMH0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Header (red)

Contains the token type (typ) and the signing algorithm (alg). Example: {"alg":"RS256","typ":"JWT"}

Payload (purple)

Contains the claims — the data the token carries. Standard registered claims include sub (subject), iss (issuer), exp (expiry), and iat (issued at). Plus any custom claims your application adds.

Signature (green)

Cryptographic proof that the header and payload have not been tampered with. Computed using the algorithm from the header and a secret or private key. Decoding the signature without the key reveals only its bytes — it cannot be verified without the signing key.

Standard JWT Claims Reference

RFC 7519 defines these registered claim names. They are not required, but when present, they must follow the standard semantics:

Claim	Full Name	Type	Description
iss	Issuer	String	Identifies who issued the token. Usually the auth server URL, e.g. https://auth.example.com
sub	Subject	String	Identifies the principal the token is about. Usually a user ID or service account identifier.
aud	Audience	String or Array	Identifies the recipients the token is intended for. The consuming service must check that its ID is in the audience.
exp	Expiration Time	NumericDate	Unix timestamp (seconds). The token must be rejected after this time.
nbf	Not Before	NumericDate	Unix timestamp. The token must not be accepted before this time. Useful for delayed-activation tokens.
iat	Issued At	NumericDate	Unix timestamp when the token was issued. Used to measure token age.
jti	JWT ID	String	A unique identifier for the token. Used to prevent replay attacks by tracking already-used JTIs.

JWT Signing Algorithms: HS256, RS256, ES256

The alg field in the JWT header tells the verifier which algorithm was used to sign the token. The three most common are:

HS256

HMAC-SHA256 · Symmetric

Uses a single shared secret for both signing and verification. Both the issuer and verifier must know the same secret. Fast and simple, but the verifier must be trusted with the signing key.

Common use: Internal services, single-application tokens

RS256

RSA-SHA256 · Asymmetric

Uses an RSA private key to sign and a public key to verify. The public key can be distributed openly — verifiers don't need the signing secret. Preferred for public APIs.

Common use: OAuth 2.0, OpenID Connect, multi-tenant APIs

ES256

ECDSA-SHA256 · Asymmetric

Elliptic curve equivalent of RS256. Produces shorter signatures with comparable security. Faster than RSA at equivalent security levels. Increasingly common in modern systems.

Common use: Mobile apps, IoT tokens, performance-sensitive systems

The alg: "none" value disables signature verification entirely. Accept tokens with alg: "none" only in contexts where authenticity is guaranteed by other means — accepting them blindly is a critical security vulnerability.

JWT Security Best Practices

✓Always verify the signature server-side: Decoding a JWT is not verification. Anyone can decode a JWT without a key — that just reads the payload. Verifying the signature with the correct key proves the token was issued by the expected authority and has not been modified.

✓Check the exp claim on every request: Expired tokens should be rejected. Do not rely on the client to stop sending tokens after expiry — the server must check exp on every authenticated request.

✓Validate the aud claim: If your service receives tokens intended for multiple audiences, check that the aud claim includes your service. Failing to do so means a token issued for Service A can be replayed against Service B.

✓Never put sensitive data in the payload: JWT payloads are Base64url-encoded, not encrypted. Anyone who intercepts the token can read the payload. Don't put passwords, credit card numbers, or PII in JWT claims — use opaque reference tokens instead.

✓Keep token lifetime short: Short-lived access tokens (5–15 minutes) limit the blast radius if a token is stolen. Use refresh tokens for longer sessions — they can be revoked server-side, unlike access tokens.

✓Reject alg: "none" explicitly: Some JWT libraries historically accepted tokens with alg: "none" and no signature. Always specify the expected algorithm on the server side rather than trusting the alg claim in the token header.

JWT Debugging Patterns

When your API returns a 401 Unauthorized, the JWT decoder is your first diagnostic tool. Here are the most common causes and how to identify them:

Token expired

Check: Decode the token and look at exp. Compare it to the current time. If exp is in the past, the token is expired.

Fix: Issue a new token via your refresh token flow. Investigate whether the token lifetime is too short for the use case.

Wrong audience (aud)

Check: Decode the payload and check the aud claim. It must match the identifier your server expects.

Fix: Request a token with the correct audience parameter. In OAuth, specify the resource parameter or audience claim when requesting the token.

Algorithm mismatch

Check: Decode the header and check the alg claim. Verify it matches what your server is configured to accept.

Fix: Ensure the token issuer and your verification configuration agree on the algorithm. If you switched from HS256 to RS256, old tokens will fail.

Wrong issuer (iss)

Check: Decode the payload and check the iss claim. It must match the expected auth server URL.

Fix: Ensure you are using the correct auth server in your application config. This commonly happens in multi-environment setups where a production token is used against a dev server.

Token from different environment

Check: Decode the iss and sub claims. Production tokens will have different issuer URLs than staging.

Fix: Use the correct environment's auth flow to obtain a valid token for that environment.

For a complete debugging walkthrough, see the blog posts on JWT decoder checklist for auth bugs and validating JWT signatures without a library.

Frequently Asked Questions

Can I decode a JWT without the secret key?

Yes. JWT decoding (reading the header and payload) does not require the signing key — the payload is only Base64url-encoded, not encrypted. Signature verification requires the key. This tool decodes and displays the payload without a key.

What is the difference between decoding and verifying a JWT?

Decoding reads the payload claims by Base64url-decoding the middle segment. Verifying checks the cryptographic signature to confirm the token was issued by the expected authority and has not been tampered with. Decoding alone is not sufficient for security — always verify server-side.

Why does my JWT have three dots but the signature is empty?

A JWT with alg: 'none' has no signature — the third segment is an empty string. This is a special (and potentially dangerous) case used only in contexts where signature verification is handled by other means.

How long should a JWT access token be valid?

Best practice is 5–15 minutes for access tokens. Short lifetimes limit the window of exposure if a token is stolen. Use refresh tokens (valid for hours or days) to issue new access tokens without requiring the user to log in again.

Why does the decoded timestamp not match my timezone?

JWT timestamps (exp, iat, nbf) are Unix timestamps — seconds since January 1, 1970 UTC. The decoder converts them to local time using your browser's timezone. The underlying value is always UTC.