JWT Decoder: Inspect Token Header, Payload, and Signature Instantly

There are few things more frustrating in backend development than a mysterious 401 Unauthorized response with no useful error message. Usually it comes down to a bad JWT: expired, wrong audience claim, mismatched issuer, or a field that's simply not what the server expects. The CalcHub JWT Decoder lets you paste a token and immediately see what's inside — no secret key needed to read the claims.

What a JWT Actually Is

A JSON Web Token is three Base64url-encoded JSON objects joined by dots:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9    ← Header
.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ    ← Payload
.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c    ← Signature

The header tells you the algorithm (alg) and token type (typ). The payload contains the claims — who the user is, what they can access, when the token expires. The signature is a cryptographic hash that proves the token wasn't tampered with.

The header and payload are not encrypted — anyone can decode them. The signature is what makes the token trustworthy, and you need the server's secret key to verify it. The decoder reads the claims; it cannot verify the signature without the key.

How to Use the Tool

1. Copy a JWT token from wherever you have it — a browser devtools Authorization header, an API response, a .env file in development
2. Paste it into the CalcHub JWT Decoder
3. The tool splits the three parts and shows you the decoded header and payload as formatted JSON
4. Check the expiry time, claims, and algorithm at a glance

The tool also calculates the expiry status — showing you whether the token is still valid based on the exp claim, and how long until it expires (or how long ago it expired).

Standard JWT Claims

Claim	Name	What it means
iss	Issuer	Who created the token
sub	Subject	Who the token is about (usually user ID)
aud	Audience	Who the token is intended for
exp	Expiration Time	Unix timestamp when the token expires
nbf	Not Before	Token isn't valid before this time
iat	Issued At	When the token was created
jti	JWT ID	Unique identifier for this token

Custom claims sit alongside these. A typical access token payload might look like:

{
  "sub": "usr_01HQXG4K7F3BZMN9P2R5S8T6W",
  "iss": "https://auth.yourapp.com",
  "aud": "https://api.yourapp.com",
  "exp": 1745654400,
  "iat": 1745650800,
  "email": "user@example.com",
  "roles": ["editor", "viewer"],
  "org_id": "org_7b2c4d8e"
}

Paste it in the decoder and you'll see exactly this, formatted and with the exp and iat timestamps converted to readable dates.

Debugging Authentication Issues

This is the main thing the decoder is for. Common problems and what the decoded token will show you:

Token expired. The exp claim is in the past. Your auth middleware is probably checking this and rejecting the token correctly. Solution: refresh the token or re-authenticate. Wrong audience. Your API checks that aud matches its own identifier, but the token was issued for a different service. This happens when you have multiple APIs sharing the same auth server but the client is sending a token meant for Service A to Service B. Missing claims. Your middleware expects a roles or permissions claim that isn't there. The user might have been issued a token before that claim was added to your token schema. Algorithm mismatch. The token header says alg: HS256 but your server is configured to only accept RS256 (asymmetric). This is actually a security feature — none algorithm attacks are a real vulnerability, and your server should reject algorithm mismatches. Clock skew. The iat claim shows the token was issued 5 minutes in the future relative to your server's clock. NTP sync issues on either end can cause this.

JWT Algorithm Types

Algorithm	Type	How it works
HS256, HS384, HS512	Symmetric (HMAC)	Single secret shared between issuer and verifier
RS256, RS384, RS512	Asymmetric (RSA)	Private key signs, public key verifies
ES256, ES384, ES512	Asymmetric (ECDSA)	Elliptic curve variant, smaller signatures
PS256, PS384, PS512	Asymmetric (RSA-PSS)	RSA with probabilistic padding

For single-service auth, HS256 is common and simple. For multi-service setups where multiple services need to verify tokens without sharing a secret, RS256 is the better choice — only the auth server holds the private key, and anyone can verify with the public key.

Security Notes

Never paste production tokens with sensitive user data into public tools. The CalcHub decoder runs client-side, but as a habit, use dev/staging tokens when debugging. For production token inspection, use your own local decode (e.g., jwt.decode() in Node.js without verification, or a local script). Decoding is not verifying. You can read the claims without a key, but that doesn't mean the claims are trustworthy. Token verification (checking the signature cryptographically) is what your server does — the decoder just shows you what's inside.

---

Why can I decode a JWT without a secret key?

The payload and header are Base64url-encoded, not encrypted. Encoding is a reversible transformation with no secret. The signature prevents tampering — if someone modifies the claims, the signature won't match the server's expected value, and the server will reject the token. But reading the claims requires no key.

How long should JWT access tokens last?

Short-lived access tokens (15 minutes to 1 hour) paired with longer-lived refresh tokens (days to weeks) is the standard pattern. The shorter the access token lifetime, the smaller the window of exposure if a token is stolen. Use the decoder's expiry check to verify your tokens are expiring when they should.

What's the difference between a JWT and an opaque token?

A JWT is self-contained — the server can verify it without a database lookup by checking the signature and claims. An opaque token is just a random string the server looks up in a database to retrieve the associated session data. JWTs are better for distributed systems and microservices; opaque tokens are simpler to revoke (just delete the DB record).

---

Related Tools on CalcHub

• Base64 Encoder/Decoder — JWTs are Base64url-encoded; decode the parts manually
• JSON Formatter — the decoded payload is JSON — format it for easier reading
• Hash Generator — understand the HMAC-SHA256 signing behind HS256 tokens
• Regex Tester — write patterns to extract JWT tokens from log files