JWT Decoder

Decode JWT (JSON Web Token) header, payload and signature instantly. See exp, iat, nbf claim status. 100% client-side, no uploads, no tracking.

Decode JWTs without uploading your tokens

Instant JWT decoding with claim status indicators and pretty-printed JSON — right in your browser. No uploads, no sign-up, no limits.

100% private

Instant decoding

Free forever

How to use

1
Paste Your JWT
Copy a JWT and paste it into the input box at the top. The tool will decode it instantly — no buttons to click.
2
Review Header & Payload
The decoded header (algorithm and token type) and payload (claims) appear as pretty-printed JSON below the input.
3
Check Claim Status
The iat, nbf and exp claims are parsed and compared to the current time. Expired or not-yet-valid tokens are flagged in red or yellow.
4
Copy If Needed
Use the Copy button to copy the decoded header or payload JSON to your clipboard for further analysis.

Why Use This JWT Decoder?

Instant decoding with claim validation, right in your browser.

Instant Local Decoding

Header and payload are decoded and pretty-printed as JSON the moment you paste the token — no buttons to click, no server round-trips.

Claim Status Indicators

The `exp`, `nbf` and `iat` claims are parsed and compared to the current time, with clear color-coded status for expired, not-yet-valid and active tokens.

UTF-8 Safe

Correctly decodes Base64URL payloads that contain non-ASCII characters, including emoji and international text.

Pretty-Printed JSON

The decoded header and payload are formatted with proper indentation for easy reading and debugging.

100% Private

All decoding happens locally in your browser. Your token is never uploaded, logged, or stored.

Free with No Limits

No registration, no API key, no daily quotas. Free for personal and commercial use, forever.

Understanding JSON Web Tokens (JWT)

What is a JWT?

A JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. JWTs are commonly used for authentication and authorization in web applications. After a user logs in, the server issues a JWT containing claims about the user (such as their user ID and roles). The client includes this JWT in the Authorization header of subsequent requests, allowing the server to verify the user's identity without storing session state.

A JWT consists of three parts separated by dots: `header.payload.signature`. The header specifies the token type (JWT) and the signing algorithm (e.g., HS256, RS256). The payload contains the claims — statements about the user and additional metadata. The signature is used to verify that the token hasn't been tampered with. Only the header and payload are Base64URL-decoded to read the claims; the signature is a binary value used only for verification.

Decoding vs. verifying a JWT

Decoding a JWT means Base64URL-decoding the header and payload to read the claims. This does not require any secret key — anyone can decode a JWT. Decoding tells you what the token claims, but it does not prove that the claims are true or that the token was issued by a trusted party.

Verifying a JWT means checking the signature using the secret key (for HMAC algorithms) or public key (for RSA/ECDSA algorithms). This confirms that the token was issued by the holder of the secret/private key and that it hasn't been modified since. Only verified tokens should be trusted for security decisions. Our tool decodes JWTs but does not verify them — for verification, use a library like jsonwebtoken (Node.js) or PyJWT (Python).

Common JWT claims

Registered claims (defined in RFC 7519): `sub` (subject — the user ID), `iss` (issuer), `aud` (audience), `exp` (expiration time), `nbf` (not before), `iat` (issued at), `jti` (JWT ID). Private claims: custom claims agreed upon by the parties, such as `role`, `permissions`, `email`, or `name`. Our tool displays all claims in the payload as formatted JSON.

Common Use Cases

Real-world scenarios where a JWT decoder is essential.

Debugging Authentication

Inspect the claims of a JWT issued by your auth server to confirm the user ID, roles, or expiration time.

API Development

Quickly verify that the JWT you generate on the server contains the expected payload before sending it to the client.

Learning JWT Structure

See exactly how a JWT is structured — header, payload, signature — without writing any code or installing libraries.

Troubleshooting Expired Tokens

Instantly see whether a 401 error is caused by an expired `exp` claim or a not-yet-valid `nbf` claim.

How does this compare to other JWT decoders?

A side-by-side comparison of popular JWT decoding tools.

Feature	NovaTools	JWT.io	JWT.ms
Privacy (no upload)	100% local	Uploads to server	Uploads to server
Price	Free unlimited	Free with ads	Free
Claim status (exp/nbf/iat)	Color-coded
Pretty-printed JSON
UTF-8 safe decoding			Limited
Mobile friendly		Limited	Limited
Works offline	After page load

JWT.io and JWT.ms upload your token to their servers for decoding. Our tool decodes everything locally — your JWT never leaves your browser.

JWT Quick Reference

Key facts about JSON Web Tokens.

Token Structure

Symbol / Code	Description	Example
`header.payload.signature`	Three Base64URL-encoded parts separated by dots.	`eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjMifQ.abc123`
`header`	JSON object with algorithm (alg) and token type (typ).	`{"alg":"HS256","typ":"JWT"}`
`payload`	JSON object with claims about the user and token.	`{"sub":"123","exp":1735689600}`
`signature`	HMAC/RSA/ECDSA signature. Not decoded, only verified.	`HMAC-SHA256(header.payload, secret)`

header.payload.signature

Three Base64URL-encoded parts separated by dots.

Example:eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjMifQ.abc123

header

JSON object with algorithm (alg) and token type (typ).

Example:{"alg":"HS256","typ":"JWT"}

payload

JSON object with claims about the user and token.

Example:{"sub":"123","exp":1735689600}

signature

HMAC/RSA/ECDSA signature. Not decoded, only verified.

Example:HMAC-SHA256(header.payload, secret)

Registered Claims

Symbol / Code	Description	Example
`sub`	Subject — identifies the user or entity.	`"sub":"user-123"`
`iss`	Issuer — identifies who issued the token.	`"iss":"auth.example.com"`
`aud`	Audience — intended recipient of the token.	`"aud":"api.example.com"`
`exp`	Expiration time (Unix timestamp in seconds).	`"exp":1735689600`
`iat`	Issued at (Unix timestamp in seconds).	`"iat":1735603200`
`nbf`	Not before — token is not valid before this time.	`"nbf":1735603200`

sub

Subject — identifies the user or entity.

Example:"sub":"user-123"

iss

Issuer — identifies who issued the token.

Example:"iss":"auth.example.com"

aud

Audience — intended recipient of the token.

Example:"aud":"api.example.com"

exp

Expiration time (Unix timestamp in seconds).

Example:"exp":1735689600

iat

Issued at (Unix timestamp in seconds).

Example:"iat":1735603200

nbf

Not before — token is not valid before this time.

Example:"nbf":1735603200

Algorithms

Symbol / Code	Description	Example
`HS256`	HMAC with SHA-256. Symmetric — same secret for sign and verify.	`{"alg":"HS256"} + shared secret`
`RS256`	RSA signature with SHA-256. Asymmetric — private key signs, public key verifies.	`{"alg":"RS256"} + RSA 2048-bit key pair`
`ES256`	ECDSA with P-256 and SHA-256. Asymmetric — smaller signatures than RSA.	`{"alg":"ES256"} + EC P-256 key pair`
`none`	No signature. INSECURE — never use in production.	`{"alg":"none"} — CRITICAL vulnerability`

HS256

HMAC with SHA-256. Symmetric — same secret for sign and verify.

Example:{"alg":"HS256"} + shared secret

RS256

RSA signature with SHA-256. Asymmetric — private key signs, public key verifies.

Example:{"alg":"RS256"} + RSA 2048-bit key pair

ES256

ECDSA with P-256 and SHA-256. Asymmetric — smaller signatures than RSA.

Example:{"alg":"ES256"} + EC P-256 key pair

none

No signature. INSECURE — never use in production.

Example:{"alg":"none"} — CRITICAL vulnerability

FAQ

Does this tool verify the JWT signature?

No. This tool only decodes the token — it does not verify the signature. Decoding tells you what the token claims, but anyone can create a token with any claims. Verification requires the signing secret (for HMAC algorithms like HS256) or the public key (for RSA algorithms like RS256, or ECDSA algorithms like ES256). Never trust a JWT's claims for security decisions without verifying its signature first. If you need to verify a JWT, use a library like jsonwebtoken (Node.js), PyJWT (Python), or jose (JavaScript/TypeScript) with the correct secret or key.

Is it safe to paste my JWT here?

Yes. All decoding happens locally in your browser using JavaScript. The token is never sent to a server, never stored, and never logged. You can verify this by opening your browser's DevTools Network tab — no network requests are made when you paste or decode a token. However, you should still avoid pasting tokens into untrusted sites, and never share JWTs in screenshots, support tickets, or public channels. Even though our tool is safe, other online JWT decoders may upload your token to their server.

What do the iat, nbf and exp claims mean?

These are registered claims defined in RFC 7519 that control the token's temporal validity. `iat` (issued at) is a Unix timestamp indicating when the token was created. `nbf` (not before) is a Unix timestamp indicating the earliest time the token is considered valid — before this time, the token should be rejected. `exp` (expiration) is a Unix timestamp indicating when the token expires — after this time, the token should be rejected. All three are stored as seconds since the Unix epoch (January 1, 1970, 00:00:00 UTC). Our tool parses these claims and shows a color-coded status: green for active, yellow for not-yet-valid, and red for expired.

Why does my token have three parts?

A JWT consists of three Base64URL-encoded parts separated by dots: `header.payload.signature`. The header describes the token type (JWT) and the signing algorithm (e.g., HS256, RS256). The payload contains the claims — statements about an entity (typically the user) and additional metadata. The signature is used to verify that the sender of the JWT is who it says it is and to ensure that the message wasn't changed along the way. To decode a JWT, you only need to Base64URL-decode the header and payload — the signature is not decoded, it's a binary value used only for verification.

What is Base64URL encoding and how is it different from Base64?

Base64URL is a variant of Base64 designed to be safe for use in URLs and filenames. It replaces the `+` character with `-` and the `/` character with `_`, and it omits the `=` padding character at the end. This is necessary because `+` and `/` have special meanings in URLs (they represent spaces and path separators, respectively). JWT uses Base64URL for encoding the header, payload, and signature. If you try to decode a JWT part with standard Base64, you may get an error because `-` and `_` are not valid standard Base64 characters.

What are the most common JWT claims?

The most common registered claims are: `sub` (subject — the user ID), `iss` (issuer — who issued the token), `aud` (audience — who the token is intended for), `exp` (expiration time), `nbf` (not before), `iat` (issued at), and `jti` (JWT ID — a unique identifier for the token). Custom claims can also be included, such as `role`, `permissions`, `email`, or `name`. Our tool displays all claims in the payload as a formatted JSON object.

Can I decode a JWT without the secret key?

Yes. Decoding a JWT does not require the secret key — you only need to Base64URL-decode the header and payload. The secret key is only required for verifying the signature, which confirms that the token was issued by a trusted party and hasn't been tampered with. This is a common source of confusion: decoding is not the same as verifying. Anyone can decode a JWT, but only someone with the secret key can verify it.

What happens if I paste an invalid JWT?

The tool will display an error message indicating what went wrong. Common errors include: not having exactly three dot-separated parts, containing characters that are not valid Base64URL, or having a payload that is not valid JSON after decoding. The error message will tell you exactly what is wrong so you can fix the input.

Does the tool work on mobile devices?

Yes. The tool is fully responsive and works on iOS Safari and Android Chrome. The interface adapts to small screens with a vertical layout — input at the top, decoded header and payload in the middle, and claim status at the bottom. Decoding runs locally on your phone, so it works even on slow network connections.

Can I use this tool for commercial projects?

Yes. The tool is free for both personal and commercial use with no watermarks, no attribution required, and no usage limits. You retain full ownership of your tokens. There is no registration, no API key, and no subscription required.

100% Client-Side & Private

JWT decoding happens entirely in your browser.

Your token is never uploaded, logged, or stored.
All decoding is performed locally using JavaScript — no network requests are made when you paste or decode a token.
For highly sensitive tokens (like production access tokens), consider using an offline tool or a local script.
Even though our tool is safe, you should never paste production tokens into any web-based tool as a general security practice.

Explore the topic

All tools in this categoryCodes & Data Tools Guides for this topicDeveloper tools

Barcode & QR Code Tools

Generate and scan all common barcode and QR code formats.

JSON Formatter

Beautify and validate JSON data.

Base64 Encoder/Decoder

Encode and decode Base64 text, including URL-safe strings.