Treating decoded output as verified
The header and payload are attacker-controlled until a trusted library verifies the signature and enforces an algorithm policy, issuer, audience, and time rules. Readable output is not proof of authenticity.
Decode compact JSON Web Tokens locally to inspect the protected header, payload claims, signature bytes, and exp, nbf, and iat timestamps. Strict Base64URL and JSON checks expose malformed tokens, but no signature or claim is verified.
Continue with a related workflow or open the next tool that usually follows this task.
Use this repeatable workflow for encoded JSON fields, webhook metadata, headers, cookies, and logs. It validates the alphabet and padding before decoding, preserves binary bytes for download, and keeps Base64 separate from encryption or signature verification.
OpenRelated toolStrictly encode UTF-8 and decode Base64, Base64URL, data URIs, and binary byte output locally.
OpenRelated toolHash UTF-8 text or exact file bytes and compare a full checksum locally.
OpenRelated toolParse bounded HTTP header blocks locally with default secret masking and protocol diagnostics.
OpenPaste a synthetic or redacted three-part JWT, with or without the Bearer prefix.
Decode it and review structural errors before reading any claim values.
Inspect the declared alg and kid, payload claims, signature byte count, and exp, nbf, and iat UTC details.
Read every warning, especially signature not verified, alg none, expired, not-yet-valid, future iat, critical headers, or imprecise numbers.
Copy or download the inspection for debugging, then verify the original token with a trusted server-side JWT library before making any decision.
Compare issuer, audience, subject, scope, role, and time claims while investigating a 401 or 403 response.
Inspect access-token or ID-token claim shape before checking the identity provider and backend verification configuration.
Spot alg none, unexpected key identifiers, critical headers, sensitive payload data, and inconsistent NumericDate ordering during review.
Produce a readable, explicitly unverified JSON inspection from a synthetic token for tests, tickets, or documentation.
The header and payload are attacker-controlled until a trusted library verifies the signature and enforces an algorithm policy, issuer, audience, and time rules. Readable output is not proof of authenticity.
JWT payloads are commonly signed and encoded, not encrypted. Passwords, API keys, session secrets, and unnecessary personal data remain readable to anyone holding the token.
A future exp value does not make a token acceptable. nbf, iat, iss, aud, key selection, revocation, and application-specific claims can still cause rejection.
Do not let an unverified alg header choose a permissive verification path. Configure the allowed algorithms and trusted keys in the verifier independently of token input.
A five-part JWE is encrypted and needs the intended decryption key and algorithm handling. It cannot be inspected as a three-part signed JWS payload.
This synthetic RS256 token includes Korean UTF-8 text and future time claims. The signature text is deliberately a demo value, so the output remains untrusted.
eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6ImRlbW8tMjAyNi0wNyJ9.eyJzdWIiOiJkZW1vX3VzZXJfNDIiLCJuYW1lIjoi6rCA656MIiwic2NvcGUiOiJyZXBvcnRzOnJlYWQiLCJpc3MiOiJodHRwczovL2F1dGguZXhhbXBsZS50ZXN0IiwiYXVkIjoicmVwb3J0cy1hcGkiLCJpYXQiOjE3ODQwNzM2MDAsIm5iZiI6MTc4NDA3MzYwMCwiZXhwIjoxODkzNDU2MDAwfQ.ZGVtby1zaWduYXR1cmUtbm90LXZlcmlmaWVk{
"header": { "alg": "RS256", "typ": "JWT", "kid": "demo-2026-07" },
"payload": { "sub": "demo_user_42", "name": "가람", "exp": 1893456000 },
"inspection": { "signatureVerified": false }
}An unsecured token declares alg none and must have an empty third segment. The decoder displays an explicit integrity warning rather than calling it valid.
eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJkZW1vIiwiZXhwIjoxNzAwMDAwMDAwfQ.{
"algorithm": "none",
"signature": { "present": false, "verified": false },
"expirationStatus": "expired"
}A compact signed JWT uses three dot-separated segments: protected header, payload, and signature. The first two segments are unpadded Base64URL-encoded UTF-8 JSON objects; their contents are readable without any key.
The decoder requires canonical Base64URL characters, valid UTF-8, one JSON object per header and payload, a non-empty alg string, and an appropriate empty or non-empty signature segment. Duplicate keys are rejected because different parsers can otherwise interpret the same token differently.
exp, nbf, and iat are inspected as finite NumericDate seconds. UTC timestamps and relative seconds are added, while expired, not-yet-valid, future-issued, malformed, and impossible ordering conditions remain separate warnings instead of one replacing another.
The signature segment is decoded only to report its byte count. No secret, public key, JWKS lookup, MAC comparison, issuer check, audience check, revocation check, or application authorization rule runs in this browser tool.
Input is limited to 100KB, JSON nesting to 64 levels, node count to 50,000, and formatted output to 512KB. Five-part JWE input is identified separately because encrypted tokens require decryption rather than payload decoding.
No. The tool only decodes and inspects compact token data. Verify the signature with trusted keys and enforce allowed algorithms, issuer, audience, time claims, and application policy on a trusted server.
It reports whether exp is absent, malformed, already passed, or still in the future relative to the browser clock. That is only an observation; it does not prove the signature, issuer, audience, clock skew policy, or token acceptability.
exp, nbf, and iat are NumericDate values measured in seconds since the Unix epoch. The output adds UTC timestamps and relative seconds while retaining the original claim value.
A three-part compact JWS can be decoded. A five-part compact JWE is encrypted and is rejected with a specific message because decryption requires keys and algorithm policy.
Decoding runs in the browser and the tool does not upload the token. A real access token can still grant permissions or expose personal data, so use a redacted or synthetic token whenever possible.
Strict unpadded Base64URL accepts letters, digits, hyphen, and underscore. Standard Base64 characters such as plus, slash, padding equals signs, internal whitespace, invalid UTF-8, malformed JSON, and duplicate keys are rejected.
The decoder permits up to 100KB of input and bounds JSON depth, node count, and output size. These limits keep malformed or unexpectedly large tokens from consuming excessive browser resources.
Maintained and tested by SimpleWebUtilsReviewed
Method: The review loaded the unmodified “JWT payload with expired access” sample into JWT Decoder: Inspect Claims and Expiration. We exercised the path from “Redact sensitive values first” to “Verify elsewhere before trusting it”, checked the displayed or downloaded result against the example, and separately examined “Assuming decoded means verified” and “Pasting the whole Authorization header”.
Expected result: The payload exposed sub, scope, aud, and exp exactly as encoded, while the result continued to label the claims unverified and the sample expiration as past.
Sources and standards
Use these focused guides when you need a practical workflow before opening the tool.
Use this repeatable workflow for encoded JSON fields, webhook metadata, headers, cookies, and logs. It validates the alphabet and padding before decoding, preserves binary bytes for download, and keeps Base64 separate from encryption or signature verification.
Workflow guideUse the local file mode and explicit checksum comparison to confirm byte equality before trusting a release archive, backup, or installer. A match does not certify the publisher or prove that the file is malware-free.
Workflow guideUse this workflow when a login, API request, or permission check fails and you need to inspect token claims before changing auth code.
Workflow guideUse this workflow after you have identified the timestamp fields and need to order cross-system events, separate event time from ingest time, account for clock skew, and explain the result without overstating causality.
Workflow guideUse this workflow to determine whether a request occurred before nbf, at or after exp, or inside the stated token window, while documenting clock-skew policy and removing the raw token from shared evidence.
Workflow guideUse this workflow when a callback, webhook, proxy, SDK, or copied link contains `%252F`, `%2520`, `%253A`, or another sign that a percent sign was encoded again.
Continue with another maintained workflow
Strictly encode UTF-8 and decode Base64, Base64URL, data URIs, and binary byte output locally.
Hash UTF-8 text or exact file bytes and compare a full checksum locally.
Parse bounded HTTP header blocks locally with default secret masking and protocol diagnostics.
Beautify or minify strict JSON locally while preserving duplicate keys and number text.
Encode or decode exact URL components, full URLs, and form values locally.