JWT Decoder — Decode & Inspect JWT Tokens Online

JWT Inspector decodes JSON Web Tokens (JWTs) and displays the header and payload as formatted JSON. You do not need the signing secret to read the claims — the tool simply decodes the Base64url-encoded parts. It shows all standard claims (iss, sub, aud, exp, iat, jti) along with any custom claims. All decoding runs in the browser; your token never leaves your machine.

Anatomy of a JSON Web Token

A JWT is a compact, URL-safe string composed of three Base64url-encoded sections separated by dots: HEADER.PAYLOAD.SIGNATURE. The header is a JSON object declaring the token type ("JWT") and the signing algorithm (e.g. "alg": "HS256"). The payload is a JSON object containing claims — statements about the user or session. The signature is computed from the header and payload using the chosen algorithm and a secret or private key.

Because the header and payload are only Base64url-encoded, not encrypted, anyone who possesses the token can read its contents without knowing the secret. This is by design: JWTs are transparent containers for claims. The signature proves the token was created by a trusted party and has not been tampered with, but it does not hide the data inside.

The three sections always decode to the same structure. A typical header looks like: {"alg":"HS256","typ":"JWT"}. A typical payload might contain: {"sub":"user_123","iat":1700000000,"exp":1700003600,"roles":["admin"]}.

Standard JWT Claims Explained

"iss" (Issuer) identifies who created the token — usually your authorization server URL. "sub" (Subject) is the principal identifier, typically a user ID. "aud" (Audience) specifies the intended recipient(s) of the token; a resource server should reject a token if it is not listed in aud. "exp" (Expiration Time) is a Unix timestamp after which the token is invalid. "iat" (Issued At) is the Unix timestamp when the token was created. "jti" (JWT ID) is an optional unique identifier for the token, useful for revocation.

Tokens commonly also carry custom claims beyond these registered ones: "email", "name", "roles", "permissions", "org_id", and so on. These are application-specific and not standardised by the JWT specification. When debugging an auth issue, the first step is to decode the token and check that the expected custom claims are present and correct.

A frequent debugging scenario: a user receives a 401 from an API. Decode the token and check "exp" — is it in the past? Check "aud" — does it match the API's expected audience? Check "roles" or "permissions" — does the user have the right scope? Ninety percent of JWT auth bugs are answered by reading the payload.

Security Considerations

Never trust the "alg" header blindly. The infamous "alg: none" attack involves an attacker sending a JWT with no signature and the algorithm set to "none". Servers that accept this will skip signature verification entirely. Always hard-code the accepted algorithm on the server side.

JWT payloads are visible to anyone who has the token. Never put passwords, credit card numbers, or other secrets in the payload. Treat a JWT like a signed, readable ID badge — it proves identity but should not carry classified information.

Short expiry times reduce the damage window if a token is stolen. For access tokens, 15 minutes is a common default. Use refresh tokens (which should be rotated and stored server-side) to obtain new access tokens without re-authenticating the user.

Common Use Cases

Inspecting the claims inside an access token or ID token
Checking token expiry (exp) and issued-at (iat) timestamps
Debugging authentication issues with JWT-based APIs
Reading the algorithm (alg) and key ID (kid) from the header
Verifying that your server generates the expected payload claims

Frequently Asked Questions

How do I decode a JWT token without a secret?

Paste your JWT into SmartDevBox. The JWT Inspector decodes the header and payload and displays them as formatted JSON. You do not need the signing secret to read the claims — only to verify the signature.

Is it safe to paste a JWT into an online decoder?

SmartDevBox decodes entirely in your browser with no server communication. Your token never leaves your machine. For maximum safety, avoid pasting production tokens with long expiry into any online tool.

What is the structure of a JWT?

A JWT consists of three Base64url-encoded parts separated by dots: header.payload.signature. The header specifies the algorithm; the payload contains the claims; the signature verifies the token was not tampered with.

Can SmartDevBox verify the JWT signature?

The JWT Inspector shows the signature string but marks it as "not verified" because signature verification requires the secret key. Use the JWT Encoder tool on SmartDevBox to sign tokens with HS256/HS384/HS512.

Privacy & Security

This tool runs entirely in your browser using client-side JavaScript. No data is sent to a server — your input never leaves your machine. SmartDevBox has no account system, no usage tracking, and no paid tier. See the Privacy & Security page for full details.

JWT EncoderCreate and sign JWT tokens using HMAC HS256, HS384, or HS512 in your browser. Free, no sign-up, 100% client-side.
Base64 DecoderDecode any Base64 string back to plain text instantly in your browser. Free, no sign-up, 100% client-side. Supports standard and URL-safe Base64.
URL DecoderDecode any percent-encoded URL string back to readable text instantly in your browser. Free, no sign-up, 100% client-side.
JSON FormatterFormat and pretty-print JSON instantly in your browser. Validates syntax and shows error location. Free, no sign-up, 100% client-side.

Decode Azure AD JWTsInspect an access token or ID token locally so you can confirm issuer, audience, scopes, roles, tenant, and expiry before blaming the API.
Find secrets in logsUse local extraction and inspection tools to catch common sensitive values before a log leaves your machine.