JWT Decoder

How Can You Decode and Verify a JWT with a Worked Example?

Paste a three-part token into JWT token or Bearer token to reveal Header, Payload, Signature (hex) and Time claims (device clock). Results appear as you type; there is no separate decode action. This example uses a deliberately public demonstration secret, demo-secret, and small timestamps so that signature verification and expiration can be examined independently.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJkZW1vLXVzZXIiLCJpYXQiOjEwMCwibmJmIjoxMTAsImV4cCI6MTYwfQ.xRc-6d0BWN-mE4RosqYs5Oq0fgZKLO9TFkMM_ZctD5o

The header decodes to {"alg":"HS256","typ":"JWT"}. The payload decodes to {"sub":"demo-user","iat":100,"nbf":110,"exp":160}. Select HS256 in Expected signature algorithm, choose UTF-8 in HMAC secret encoding, enter demo-secret in HMAC secret, and click Verify signature. The signature matches the supplied key. Its expiration is nevertheless long past on a present-day device clock: a matching signature does not make an expired token usable.

For a second way to supply the same key bytes, choose Base64 and enter ZGVtby1zZWNyZXQ=. With Base64URL, enter ZGVtby1zZWNyZXQ. All three representations verify this example because they decode to the same bytes. Leaving UTF-8 selected while pasting either encoded representation uses those characters literally and supplies a different key. Never reuse this published demonstration secret for a real token.

How Do You Decode a JWT and Inspect Its Claims?

A compact signed JWT has three dot-separated sections: header, payload and signature. The decoder removes an optional case-insensitive Bearer prefix and surrounding whitespace, making an authorization-header value convenient to inspect. It does not remove unexpected characters within the token. Copy the token value rather than the full header line: the text Authorization: is not a supported prefix.

The first two sections must be Base64url-encoded UTF-8 JSON objects. Accented names, emoji and non-Latin scripts remain readable. Arrays, null and primitive JSON values are rejected as section roots, although arrays and other JSON values are allowed inside an object. The signature is decoded into hexadecimal bytes, not text. An empty third section can be inspected and appears as Empty signature; that is not proof of a valid signature.

Header and Payload each have a copy control. Long values wrap in the output panels for inspection on narrow screens. For further JSON work, use the JSON Formatter; for separate encoding experiments, use the Base64 Encoder and Decoder. Readable claims remain untrusted data until the receiving application accepts them.

How Can You Verify an HMAC JWT Signature?

Select the algorithm your application expects: HS256, HS384 or HS512. The selection starts at HS256 and must match the token header. Enter the secret and explicitly choose UTF-8, Base64 or Base64URL. UTF-8 preserves spaces, so a leading or trailing space changes the key bytes. Base64 requires canonical encoding with padding when needed; Base64URL requires canonical unpadded encoding with its URL-safe alphabet.

Click Verify signature to run the browser's Web Crypto verification over the original encoded header and payload joined by a dot. It does not sign the reformatted JSON visible in the panels. Changing whitespace in a decoded JSON object and encoding it again changes the signed input, even when the parsed claims look equivalent. A mismatch can therefore indicate changed token bytes as well as an incorrect secret or secret encoding.

Changing the key, encoding or algorithm resets the verification status. Changing the algorithm also clears the key input; editing the token remounts the verifier with its defaults. This prevents an earlier matching result from remaining attached to a different input. Verification requires Web Crypto, available in a supported secure context such as HTTPS or localhost.

Which Public Keys and Signature Algorithms Are Supported?

For asymmetric verification, choose RS256, RS384, RS512, ES256, ES384 or PS256 and paste a PEM SPKI public key or public JWK. PEM input must use the BEGIN PUBLIC KEY and END PUBLIC KEY markers; a certificate or private-key PEM is not this format. A JWK is one public-key object, not a JWKS collection. RSA keys need n and e; EC keys need crv, x and y. JWK objects containing d or k are rejected.

Public-key verification choices implemented by the decoder

Selection	Verification configuration
RS256, RS384, RS512	RSASSA-PKCS1-v1_5 with SHA-256, SHA-384 or SHA-512
ES256, ES384	ECDSA with P-256 or P-384 and the corresponding hash
PS256	RSA-PSS with SHA-256 and a 32-byte salt length

The public-key input allows up to 100,000 characters. Keys are imported locally; the decoder does not retrieve a JWKS endpoint or choose a remote key from kid. Supply the key that your service expects. Algorithms outside the selection list, including ES512 and PS384, are not verification options. This tool inspects tokens and checks signatures; it does not issue replacement tokens.

How Do You Debug Expiration and Activation Times?

The time panel reads exp, nbf and iat as NumericDate values in seconds since the Unix epoch, as defined by JSON Web Token (RFC 7519). It displays dates in UTC and refreshes comparisons every second against the device clock. The clock tolerance starts at zero and is bounded from zero to 3,600 seconds. Tolerance changes comparisons, not the token's raw timestamps or your device clock.

The exact expiration rule is now >= exp + tolerance. The not-active rule is now + tolerance < nbf; the same comparison produces a warning for a future iat. With the example payload above and a hypothetical clock reading of 105 seconds, zero tolerance reports not active yet because 105 is below 110. A tolerance of 10 seconds lets that activation check pass because 105 + 10 reaches beyond 110. The interface has no historical-clock selector; these calculations explain its rules.

For that same payload, expiration occurs at 160 seconds with zero tolerance, or at 170 seconds with a tolerance of 10. Equality is expired in both cases. Quoted numbers such as "160", null and dates outside the supported date range are invalid. A missing exp gets a separate no-expiration message. No check here enforces a maximum age from iat or compares the ordering of iat, nbf and exp.

Are Large Numbers and Duplicate Claims Preserved?

The displayed and copied JSON preserves original number and string tokens instead of reserializing them through JavaScript numbers. For example, an identifier written as 9007199254740993 remains that exact number token in Payload. Formatting adds indentation, so the result is not a byte-for-byte copy of the original JSON whitespace. Signature verification still uses the original encoded sections.

Time analysis uses a separate parsed representation with JavaScript number semantics. Preserving a numeric token in the display therefore does not promise arbitrary-precision date arithmetic. Duplicate payload keys remain visible and produce a duplicate-key notice; the parsed value used by time checks takes the last occurrence of a repeated top-level key. Duplicate header keys block verification. The JSON parser also limits nesting to 512 container levels; excessively deep input is rejected rather than expanded indefinitely.

What Should You Check Before Trusting a Token?

Start with the signature and a trusted key, then enforce your application's issuer, audience and authorization rules. Compare iss and aud with the receiving service's configuration and interpret scopes or roles according to its policy. The decoder does not perform those application checks. An unexpired token might belong to another environment, and a matching signature only establishes consistency with the key you supplied.

An alg value of none produces an unsigned-token warning. Verification refuses headers containing crit or b64 extensions rather than guessing their semantics. Five-part encrypted JWTs receive an unsupported-JWE explanation; they are not decrypted. Invalid Base64url characters, padding, non-canonical encodings and malformed UTF-8 are rejected. These limits distinguish an inspectable token from a format this decoder can safely interpret.

Parsing and verification keep inputs in component state without uploading tokens or keys, fetching remote keys, writing browser storage or adding values to the URL. Clear removes the token, decoded output and verifier inputs. Clipboard copies remain outside that lifecycle: copying claims is an explicit disclosure to your clipboard, and Clear does not erase it. Use this page to diagnose a token, then apply the full validation policy in the application that consumes it.