What is a JWT (JSON Web Token)?

A JSON Web Token (RFC 7519) is a compact, URL-safe means of representing claims to be transferred between two parties. It consists of three Base64URL-encoded parts separated by dots: Header, Payload, and Signature.

Is it safe to decode my JWT here?

Yes. Sys-Metrics decodes your JWT 100% client-side in your web browser using JavaScript. No tokens or sensitive payload data are ever transmitted to any external server.

What does the 'exp' claim in a JWT mean?

The 'exp' (expiration time) claim identifies the Unix epoch timestamp after which the JWT must not be accepted for processing. Our tool automatically calculates whether the token is still valid or expired.

JWT Token Decoder & Inspector

Decode, inspect claims, and evaluate expiration of RFC 7519 JSON Web Tokens client-side.

Paste a JWT

⚡ Quick Reference Answer (AEO Summary)

JSON Web Token (JWT) is a compact open standard composed of three Base64URL-encoded JSON structures separated by periods: Header.Payload.Signature. Tokens are decoded client-side by splitting the string and running Base64URL decoding on each component. Crucial security claims include exp (expiration), iat (issued at), and iss (issuer).

Encoded Token (header.payload.signature)

Token Expiration Status:

—

Header (Algorithm & Token Type)

Payload (Claims & Data)

🔒 100% In-Browser Execution: Your token is never uploaded, tracked, or saved. Signature verification should always occur on your trusted backend servers using your private secret or public key.

Anatomy of a JSON Web Token (RFC 7519)

A JSON Web Token consists of three distinct segments delimited by dots (.):

Header: Specifies the cryptographic algorithm used (e.g., HMAC SHA-256, RSA, ECDSA) and token type.
Payload: Encodes the claims—statements about an entity (typically, the user) and additional metadata.
Signature: Generated by hashing the encoded header and payload with a secret or private key to ensure tamper-proofing.

Standard JWT Claims Reference

Claim	Full Name	Standard Definition & Purpose
`iss`	Issuer	Identifies the principal that issued the JWT (e.g., `https://auth.company.com`).
`sub`	Subject	Identifies the subject of the JWT (e.g., internal user ID or service name).
`aud`	Audience	Identifies the recipients that the JWT is intended for.
`exp`	Expiration Time	Unix epoch timestamp identifying when the token expires.
`nbf`	Not Before	Identifies the time before which the JWT must not be accepted.
`iat`	Issued At	Unix epoch timestamp identifying when the JWT was created.
`jti`	JWT ID	Unique identifier for the token, preventing replay attacks.

JWT Best Practices for Infrastructure & Security

When implementing JWT authentication in modern distributed systems:

Keep payloads small: JWTs are frequently sent in HTTP headers (Authorization: Bearer <token>). Large payloads increase latency on every network hop.
Never store passwords or private keys: Base64URL encoding is not encryption; anyone who intercepts the token can read the payload claims.
Enforce short TTLs with refresh tokens: Keep access tokens valid for 10–15 minutes while storing cryptographically random refresh tokens in secure HttpOnly cookies.
Reject none algorithm: Explicitly configure your backend verifier to disallow the insecure "alg": "none" bypass exploit.