Decode and inspect JWT headers, payloads, and signatures with syntax highlighting and human-readable timestamps.
JWT compact serialization often looks opaque even though its first two sections are only Base64url-encoded. This inspector separates a three-section signed or unsecured token into its protected header, JSON claims payload, and signature section, adds JSON syntax highlighting, and renders recognized NumericDate values in readable form. The central trap is treating successful decoding as authentication. Anyone who has a token can read or alter those claims; trust requires independent signature verification and application-specific claim checks. Because tokens can contain identifiers or authorization data, inspection happens entirely in the browser and nothing is uploaded.
A concrete input and expected output from the current implementation.
Input
eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiIxMjMifQ.
Expected output
Header: {"alg":"none","typ":"JWT"}
Payload: {"sub":"123"}
Signature: empty The first two segments decode from Base64url to the stated JSON objects. The final dot supplies an empty third segment, as required for an unsecured JWT using "alg":"none"; there is no timestamp to convert.
For a three-part compact token, the text before the first dot is decoded from Base64url as protected header JSON, and the middle section becomes the claims JSON. The final section is displayed as signature material rather than interpreted as claims. Base64url uses the URL-safe characters "-" and "_" and commonly omits trailing "=" padding.
After the payload is parsed, syntax highlighting distinguishes objects, arrays, strings, numbers, booleans, and null values. Registered NumericDate claims such as "exp", "nbf", and "iat" count seconds from 1970-01-01T00:00:00Z, so their readable dates are derived from seconds, not 13-digit JavaScript milliseconds. Other registered claims include "iss", "sub", "aud", and "jti"; public and private claim names can also appear.
No. Decoding requires no secret and establishes neither origin nor integrity. Validation normally includes checking the cryptographic signature with a trusted key, restricting acceptable algorithms, and evaluating claims such as issuer, audience, expiration, and not-before time according to the receiving application's policy. A displayed signature section is not evidence that those checks passed.
No. In a signed JWT, the encoded header and payload form the input covered by the signature. Changing either section changes that input, so the old signature no longer matches. Producing a valid replacement requires an authorized signer and the correct signing key. With "alg":"none", there is no signature protection to preserve.
The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.
Generate strong, random passwords with customizable length, character sets, and complexity requirements.
Analyze password strength with entropy scoring, crack-time estimates, and improvement suggestions.
Create cryptographically random strings for API keys, tokens, salts, and unique identifiers.
Create QR codes for URLs, text, Wi-Fi credentials, vCards, and more with customizable size and colors.
Scan and decode QR codes from uploaded images or your device camera to extract embedded data.
Compute MD5, SHA-1, SHA-256, and SHA-512 checksums to verify file integrity and detect tampering.