Is JWT decoding safe? Will my token be uploaded to a server?

Completely safe. The entire decode process uses your browser's native Base64 API — no network request is ever made and your token never leaves your device. Open DevTools → Network and watch for yourself: zero requests while you paste your token.

What information is in a JWT Header and Payload?

The Header contains alg (signing algorithm, e.g. HS256 or RS256) and typ (always JWT). The Payload contains claims: standard ones include sub (subject / user ID), iat (issued-at timestamp), exp (expiry timestamp), and nbf (not-before timestamp). Everything else is application-specific — roles, org IDs, email addresses, custom metadata, and so on.

What do iat, exp, sub, and nbf mean in a JWT?

These are JWT Registered Claims: sub is the Subject (typically a user ID); iat is Issued At (Unix timestamp in seconds of when the token was created); exp is Expiration (token is invalid after this time); nbf is Not Before (token must not be accepted before this time). This tool automatically converts all three timestamps to human-readable local time and flags whether the token has expired.

How can I tell if a JWT token has expired?

Paste the token into the input field. If the Payload contains an exp claim, the tool converts it to local time and shows an expiry badge: green means still valid, red means expired. The exp value is a Unix timestamp in seconds — the moment after which the token is no longer accepted.

JWT Decoder Online

What Is a JWT? The Header, Payload & Signature Structure Explained

JSON Web Tokens (JWTs) are the most widely used authentication credential format in 2026. Almost every modern web app — from REST APIs and OAuth flows to single-sign-on systems — issues JWTs. A token looks like this:

eyJhbGci...（Header）.eyJzdWIi...（Payload）.SflKxwRJ...（Signature）

It's three Base64URL-encoded strings joined by dots:

Header: A JSON object containing alg (the signing algorithm, e.g. HS256, RS256, ES256) and typ (always JWT).
Payload: A JSON object containing claims. Standard fields include sub (user ID), iat (issued-at timestamp), exp (expiry timestamp), and nbf (not-before timestamp). Everything else is application-specific — roles, org IDs, permissions, etc.
Signature: An HMAC or RSA/EC signature over the first two parts. The server uses this to verify the token hasn't been tampered with.

The Header and Payload are only Base64URL-encoded, not encrypted — anyone with the token can read them without a key. That's exactly how this decoder works: pure client-side Base64 decoding, no key required.

Is It Safe to Paste Your JWT Into an Online Tool? Why jwt.io Raises Concerns

The most familiar JWT inspector is jwt.io. But security teams have a standing concern: you're pasting potentially sensitive production tokens into a third-party website. JWT payloads routinely contain user IDs, role assignments, email addresses, and org identifiers — data that strict security policies say shouldn't leave a controlled environment.

Even if jwt.io's code is never malicious, your browser extensions, your company's network proxy, or a future code change could capture that content. When handling production tokens, this isn't paranoia — it's basic security hygiene.

MeTool's JWT Decoder is built on a single principle: your token never leaves your browser. The entire decode process uses the browser's native atob() function — no network request is ever made. Open DevTools → Network tab and verify it yourself: paste a token and the network panel stays completely empty.

JWT Claim Reference: What iat, exp, sub, nbf, iss, aud, and jti Mean

JWT defines a set of Registered Claims — standard fields with precise, interoperable meanings:

sub (Subject): The principal the token represents, typically a user ID or account identifier.
iat (Issued At): Unix timestamp (seconds) of when the token was created. Used to track token age.
exp (Expiration Time): Unix timestamp (seconds) after which the token must be rejected. The most common claim checked server-side.
nbf (Not Before): Unix timestamp (seconds) before which the token must be rejected. Used for pre-issued tokens that become valid in the future.
iss (Issuer): Identifies who generated the token, e.g. https://auth.example.com.
aud (Audience): Identifies the intended recipient(s). Servers verify they are listed in aud before accepting the token.
jti (JWT ID): A unique identifier for this token, used to prevent replay attacks.

This tool automatically converts iat, exp, and nbf to human-readable local time and shows them alongside the raw value — no more manually running new Date(exp * 1000) in the console.

Debugging Common JWT Auth Problems with an Online Decoder

Here are the most frequent JWT-related bugs in development, and how to diagnose them in seconds:

Token Expired (401 Unauthorized)

Paste the token and check the exp field in the Payload claims table. The tool shows "Expired" or "Expires at [local time]" — faster than mentally converting a Unix timestamp.

Algorithm Mismatch (Signature Verification Fails)

Check the alg field in the Header and confirm it matches your server config. HS256 and RS256 are the most common point of confusion: HS256 is symmetric (same key signs and verifies), RS256 is asymmetric (private key signs, public key verifies).

Missing or Wrong Role/Permission (403 Forbidden)

Expand the custom claims in the Payload — roles, permissions, scope — and confirm the token carries the expected access level. Remember: with stateless JWTs, permission changes don't propagate until the user gets a new token.

Inspecting Nested JSON Claims

Some systems embed nested objects or arrays in the Payload — user profile data, multi-tenant org info, feature flags. The claims detail table detects nested structures, shows a type badge (e.g. Object {3} or Array [5]), and lets you expand/collapse them. Each nested value has its own copy button that copies the fully formatted JSON.