JWTs in modern data and backend workflows
JSON Web Tokens show up in OAuth2 access tokens, service-to-service calls, mobile session bridges and increasingly in event streams that carry signed claims. They are attractive because the resource server can validate structure and expiry without a synchronous call to a central session store — at the cost of careful key rotation and revocation design. Analysts and engineers often need to read the claims payload during incident response: which tenant ID was embedded, which scopes were granted, whether exp lines up with the outage window. This page’s decoder helps you inspect those fields quickly while repeating the warning that decoding is not verifying and must never replace your framework’s signature checks in production code.
Security reminder
Never paste production access tokens into untrusted websites. This tool runs locally in your browser session; still minimise what you paste, rotate credentials if they may have leaked and prefer redacted samples when collaborating in chat.
Header, payload and signature at a glance
A compact JWT is three segments separated by dots. The header names the signing algorithm and token type. The payload carries standard claims such as iss, sub, aud, exp and iat plus vendor-specific JSON. The signature binds header and payload with a secret or private key. Our decoder shows header and payload as JSON for readability. The signature segment is shown as raw text because verifying it requires cryptographic material you should not paste into a generic web form.
Interpreting exp, nbf and clock skew
exp marks the instant after which the token should be rejected; nbf optionally marks the earliest valid time. Real systems must tolerate small clock skew between issuers and validators. When you are debugging “random” 401 responses, compare exp to wall-clock time in UTC, check whether your value is in seconds or milliseconds and confirm the issuer did not shorten token lifetime during an incident. The Unix Timestamp Converter pairs cleanly with this page for that investigation loop.
Encoding relationships: Base64url and URL encoding
JWT segments use Base64url, not standard Base64, so + and / and padding rules differ slightly from what you might expect from older stackoverflow snippets. If you are extracting a segment manually for other tools, use the Base64 Encoder & Decoder where appropriate, or keep the JWT intact and let this decoder split segments for you. When claims contain nested JSON strings that are themselves URL-encoded, return to the URL Encoder & Decoder and Query String ⇄ JSON pages to normalise each layer deliberately rather than guessing.
Operational tips for teams
Store example JWTs in runbooks as revoked or synthetic tokens only. When comparing two environments, diff decoded payloads side by side after formatting JSON in the JSON Formatter. For database-side expiry logic that mirrors JWT rules, prototype predicates in the SQLite Playground before you ship complex SQL to a shared warehouse.