A JSON Web Token (JWT) is an open standard (RFC 7519) for securely transmitting information between parties as a JSON object. It consists of three Base64URL-encoded parts separated by dots: a header (algorithm and token type), a payload (claims), and a signature. The signature is computed using a secret or private key and is used to verify authenticity.

Is it safe to decode a JWT in the browser?

Yes — decoding a JWT only reads the header and payload, which are simply Base64URL-encoded JSON. No secret key is needed to decode them. This tool never validates the signature; it only decodes and displays the contents. Never paste a production JWT containing sensitive data into any online tool unless you trust that tool completely.

What is the difference between exp and iat?

iat (issued at) is the Unix timestamp when the token was created. exp (expiration time) is the Unix timestamp after which the token must no longer be accepted. The difference between exp and iat gives the token's lifetime. For example, if iat is 1711234567 and exp is iat + 3600, the token is valid for exactly one hour.

JWT Builder & Decoder

Construct JWT payloads with standard claims and custom fields, or decode an existing token. No secrets required — 100% client-side.

Header

Algorithm (alg)

Type (typ)

Standard Claims

Issuer (iss)

Subject (sub)

Audience (aud)

JWT ID (jti)

Issued At (iat)

Expires (exp)

Not Before (nbf)

Custom Claims

Paste JWT Token

Standard JWT Claims (RFC 7519)

Claim	Name	Type	Description
`iss`	Issuer	String (URI)	Identifies the principal that issued the token. Usually the auth server URL.
`sub`	Subject	String	Identifies the principal that is the subject of the token. Typically a user ID.
`aud`	Audience	String or Array	Identifies the recipients for which the token is intended.
`exp`	Expiration Time	NumericDate	Unix timestamp after which the token MUST NOT be accepted.
`nbf`	Not Before	NumericDate	Unix timestamp before which the token MUST NOT be accepted.
`iat`	Issued At	NumericDate	Unix timestamp when the token was issued.
`jti`	JWT ID	String	Unique identifier for the token. Prevents replay attacks.

Common Algorithms

Algorithm	Type	Key Size	Notes
HS256	HMAC-SHA256	256-bit secret	Most common. Symmetric — same key signs and verifies.
HS512	HMAC-SHA512	512-bit secret	Stronger HMAC variant. Symmetric.
RS256	RSA-SHA256	2048+ bit RSA	Asymmetric. Private key signs, public key verifies.
ES256	ECDSA-P256-SHA256	256-bit EC	Smaller key than RSA with equivalent security.
none	Unsecured	—	No signature. Never use in production.

Fill in claims above and click Build JWT.

How to Use the JWT Builder

Build mode — Select the signing algorithm, fill in standard claims like sub, exp, and iat, add any custom claims, then click Build. The tool produces an unsigned Base64URL-encoded JWT for inspection.
Decode mode — Paste any existing JWT to instantly decode and view its header and payload claims in readable JSON format.
Reference tab — Browse the full IANA standard claims table and a guide to JWT algorithms.

What Is a JSON Web Token?

A JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. Defined in RFC 7519, a JWT has three parts separated by dots: the header (algorithm and token type, Base64URL-encoded), the payload (claims, Base64URL-encoded), and the signature (HMAC or RSA/ECDSA over the header and payload). The header and payload are not encrypted by default — they are simply encoded. Anyone who holds a JWT can decode and read its contents.

Why Use JWTs for Authentication?

JWTs are widely used in stateless authentication systems. When a user logs in, the server issues a signed JWT containing claims like the user ID and token expiry. The client stores this token (in memory or a secure cookie) and sends it with every request in the Authorization: Bearer <token> header. The server can verify the signature without consulting a database, enabling horizontally scalable microservices that share no session state. Popular frameworks like OAuth 2.0, OpenID Connect, and Auth0 all use JWTs as their token format.

Understanding the exp Claim

The exp (expiration time) claim is a Unix timestamp — the number of seconds since January 1, 1970 UTC. A token with "exp": 1711238167 expires at that specific moment. The date-time picker in this builder converts the human-readable date you select into the correct Unix timestamp automatically. Short-lived tokens (15 minutes to 1 hour) reduce the window of attack if a token is stolen. Pair short expiry with refresh tokens to maintain seamless user sessions.

Security Considerations

Never verify JWTs on the client side — always verify the signature server-side before trusting any claim. Watch out for the alg: none attack, where a malicious token sets the algorithm to none and removes the signature, tricking a vulnerable verifier into accepting it. Always explicitly specify the expected algorithm in your verifier, never trust the algorithm from the token itself. Store JWTs in HttpOnly cookies rather than localStorage to mitigate XSS attacks. For more on token security, see the Hash Generator and SSL Certificate Decoder.

Custom Claims and Namespacing

Beyond the standard IANA claims, you can add any custom claims to a JWT payload. To avoid collision with future standard claims, the JWT specification recommends namespacing custom claims using a URI prefix (e.g., https://yourapp.com/roles). Common custom claims include user roles (roles: ["admin", "editor"]), tenant identifiers, and permission scopes. Keep JWTs compact — every extra byte increases request overhead. For large amounts of data, store it server-side and reference it with a compact identifier claim in the token.

Frequently Asked Questions

A JSON Web Token (JWT) is an open standard (RFC 7519) for securely transmitting information between parties as a JSON object. It consists of three Base64URL-encoded parts: a header, a payload (claims), and a signature. The signature is computed using a secret or private key to verify authenticity.

Generating a valid JWT signature requires a secret key or private key. Exposing your secret to any online tool would be a serious security risk. This builder constructs the unsigned header and payload so you can inspect the structure and test claim values — you sign it in your backend where the secret remains private.

The IANA registry defines: iss (issuer), sub (subject), aud (audience), exp (expiration time), nbf (not before), iat (issued at), and jti (JWT ID). All are optional, but exp, iat, and sub are most commonly used for authentication tokens.

Yes — decoding only reads the Base64URL-encoded header and payload; no secret key is needed. This tool never validates the signature. Avoid pasting production JWTs containing sensitive personal data into any online tool unless you fully trust it.

iat (issued at) is the Unix timestamp when the token was created. exp (expiration time) is the Unix timestamp after which the token must be rejected. The difference gives the token lifetime. For example, iat + 3600 makes a token valid for exactly one hour.