UtilityKit

500+ fast, free tools. Most run in your browser only; Image & PDF tools upload files to the backend when you run them.

JWT Decoder

Decode and inspect JWT tokens

About JWT Decoder

JWT Decoder is a browser-only tool for decoding and inspecting JSON Web Tokens. Paste a JWT — the three base64URL dot-separated segments produced by any standard authentication system — and the tool splits and decodes the header and payload into readable, syntax-highlighted JSON panels. The signature segment is shown as a hex string. Standard registered claims (exp, iat, nbf) are rendered as both raw Unix timestamps and human-readable local date-time strings, and a status badge shows whether the token is currently active, expired, or not yet valid. No secret key is required or accepted — this is decode-only, not a verification tool. All processing runs in your browser with no network requests, making it safe to inspect real access tokens from OAuth2 flows, API gateways, or JWT-based session systems.

Why use JWT Decoder

Human-Readable Timestamp Conversion

JWT expiry (exp), issued-at (iat), and not-before (nbf) values are stored as Unix epoch seconds. The tool converts them to local date-time strings automatically, eliminating the mental arithmetic of decoding timestamps and making token lifetimes immediately clear.

Live Expiry Status Indicator

A clearly labelled status badge tells you at a glance whether the token is currently active, has already expired, or is not yet valid — critical information when debugging a 401 Unauthorized error and not sure whether the token, the clock, or the server logic is the problem.

Colour-Coded Header and Payload Panels

Header and payload are decoded and displayed as separate, syntax-highlighted JSON blocks, making it easy to locate a specific claim — such as sub, scope, or roles — in a payload with dozens of fields without reading raw base64.

Zero Secret Key Exposure Risk

This tool decodes only. It accepts no signing secret and performs no cryptographic verification, so there is no risk of accidentally entering a private key or symmetric secret into an online form. Verification should always happen server-side with your secret.

Instant Malformation Detection

Tokens with fewer than three segments, non-base64URL payload, or malformed JSON in the claims are flagged immediately with a specific error message — making it fast to diagnose a truncated token, a copy-paste error, or a Bearer prefix accidentally left in the string.

Algorithm Identification in the Header

The alg field in the header — RS256, HS256, ES256, none, or others — is highlighted prominently. Seeing 'none' or an unexpected algorithm in a token you receive is an important security signal that is easy to miss when reading raw base64.

How to use JWT Decoder

  1. Paste the full JWT string — all three dot-separated segments — into the input field at the top.
  2. The header and payload JSON panels populate immediately, with keys and values syntax-highlighted.
  3. Review the claims summary panel: iat, exp, and nbf timestamps are shown alongside their human-readable equivalents.
  4. Check the expiry status indicator: the tool shows 'Active', 'Expired', or 'Not Yet Valid' based on the current time versus the exp and nbf claims.
  5. Copy either the header or payload JSON using the copy buttons if you need to paste them into another tool or document.
  6. To inspect a different token, clear the input or paste over it — the panels update instantly without a page reload.

When to use JWT Decoder

  • Debugging a 401 Unauthorized API error by checking whether the token is expired or has the wrong scope.
  • Inspecting the claims in a JWT returned by an OAuth2 authorization server to confirm the correct scopes and subject were granted.
  • Verifying that a newly issued token from your authentication service contains the expected custom claims before testing downstream services.
  • Reading the alg field of a received token to confirm the signing algorithm matches your verification configuration.
  • Checking the exp and nbf timestamps of a token when debugging a clock-skew related authentication failure.
  • Quickly understanding the structure of a JWT format used by a third-party service before implementing a parser in code.

Examples

Decode a signed access token

Input: eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c3JfMTIzIiwibmFtZSI6IkFsaWNlIiwic2NvcGUiOiJyZWFkOm9yZGVycyIsImlhdCI6MTcxNjA3NjgwMCwiZXhwIjoxNzE2MDgwNDAwfQ.<signature>

Output: Header: { "alg": "RS256", "typ": "JWT" } Payload: { "sub": "usr_123", "name": "Alice", "scope": "read:orders", "iat": 2024-05-19 10:00:00, "exp": 2024-05-19 11:00:00 } Status: EXPIRED

Detect an unsigned (none) token — security risk

Input: eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJhZG1pbiIsInJvbGUiOiJhZG1pbiJ9.

Output: Header: { "alg": "none", "typ": "JWT" } Payload: { "sub": "admin", "role": "admin" } Warning: alg is 'none' — this token has no cryptographic signature and should never be trusted.

Inspect exp timestamp unit error

Input: Payload with exp: 1716076800000 (milliseconds instead of seconds)

Output: exp decoded: year 56357 — token appears to never expire. Root cause: exp was set with Date.now() (ms) instead of Math.floor(Date.now()/1000) (seconds).

Tips

  • If the token starts with 'Bearer ', remove that prefix before pasting — the tool expects just the three-segment JWT string without the Authorization header scheme prefix.
  • Check the alg field in the header first when debugging unexpected verification failures — if it says 'none' or a different algorithm than your server expects, that is the root cause.
  • Compare the exp timestamp to the current time in your browser's DevTools console with Date.now()/1000 to calculate exactly how many seconds remain before expiry.
  • If a token payload contains a roles or scope claim, copy it out to verify that the user's permission set matches what the API endpoint requires before looking at other potential causes of a 403.
  • JWT header typ: 'at+JWT' (access token) versus typ: 'JWT' indicates an OAuth2 Access Token per RFC 9068 — useful when debugging token type mismatches in OAuth2 resource server validation.

Frequently Asked Questions

Does this tool verify the JWT signature?▾
No. Decoding and verifying are different operations. This tool decodes — it base64URL-decodes the header and payload so you can read the claims. Verification requires the secret or public key and must happen server-side. Never trust decoded claims without server-side signature verification.
Is it safe to paste a real production JWT here?▾
All decoding runs entirely in your browser with no network requests. The token is never sent to any server, logged, or stored. That said, real access tokens are credentials — treat them like passwords and rotate or revoke them if you suspect exposure.
What are the three parts of a JWT?▾
A JWT consists of three base64URL-encoded segments separated by dots: the header (algorithm and token type), the payload (claims about the user or session), and the signature (a cryptographic value computed from the header, payload, and a secret or private key).
What does the 'none' algorithm in the header mean?▾
The alg: none value means the token has no cryptographic signature. This is a known JWT attack vector — some libraries that are misconfigured will accept unsigned tokens as valid. If you see alg: none in a token you receive, treat it as potentially forged.
What is the difference between exp and nbf claims?▾
exp (expiration time) is the Unix timestamp after which the token must be rejected. nbf (not before) is the timestamp before which the token must also be rejected. Together they define a validity window. Both are optional but widely used in practice.
Why does the tool show the token as expired even though I just issued it?▾
JWT exp is a Unix timestamp in seconds, not milliseconds. If the token was mistakenly issued with an exp value in milliseconds (e.g., Date.now() instead of Math.floor(Date.now()/1000)), the expiry would be in the year 571900+, not a few minutes from now — or conversely, a too-small value would appear already expired. Check the raw exp value and the tool's decoded date.
Can I decode a JWE (encrypted JWT)?▾
JWEs use a different compact serialisation: five dot-separated parts, with the payload encrypted rather than base64URL-encoded JSON. This tool handles JWS (signed JWTs with readable payloads) only. Decoding a JWE requires the recipient's private key.
What is the sub claim?▾
sub (subject) is a standard registered claim that identifies the principal — typically a user ID or service account name — that the token was issued for. It is a string value and must be unique within the issuer's domain.

Explore the category

HTML Entities Encoder Decoder Encode and decode HTML entities in named/basic and numeric modes. Base64 Encode and decode Base64 strings URL Encoder Encode and decode URLs JSON Escape / Unescape Escape plain text for JSON or decode escaped text JavaScript String Escape Encode and decode JavaScript escape sequences for safe string handling. Data URL Builder Build and decode data URLs with MIME, charset, and Base64 options.
JWT Tokens Explained: Structure, Security, and Common Pitfalls A JWT looks like random text until you decode it — then you find a header, a payload, and a signature. This post explains exactly what each Jan 2026 · 10 min How OAuth 2.0 Works: Flows, Tokens, and Security in Plain English OAuth 2.0 is the standard behind every "Sign in with Google" button — yet the underlying flow confuses many developers. This post maps out e Feb 2026 · 11 min API Keys: How They Work, Best Practices, and What to Avoid API keys are the workhorse of server-to-server authentication, but a leaked key can mean thousands of dollars in fraudulent charges. Here's May 2026 · 9 min

Glossary

JWT
JSON Web Token — a compact, URL-safe token format defined in RFC 7519 consisting of a base64URL-encoded header, payload, and signature separated by dots.
Claims
Key-value pairs in the JWT payload that assert facts about the subject or the token itself. Registered claims (iss, sub, exp, iat, nbf, aud, jti) have standardised meanings; custom claims are application-defined.
Base64URL
A variant of Base64 encoding that uses - instead of + and _ instead of / and omits padding, making the output safe for use in URLs and HTTP headers without percent-encoding.
exp Claim
The expiration time claim — a Unix epoch timestamp (seconds since 1970-01-01 00:00:00 UTC) after which the JWT must not be accepted. Absence means the token does not expire.
JWS
JSON Web Signature — the signed form of a JWT where the payload is base64URL-encoded and readable. Distinct from JWE (JSON Web Encryption) where the payload is encrypted and opaque.
alg
The algorithm header parameter identifying the cryptographic algorithm used to sign the token — for example RS256 (RSA + SHA-256), HS256 (HMAC-SHA256), ES256 (ECDSA + SHA-256), or none (unsigned).