JWT Decoder

Decode Any JWT Instantly

Paste a JSON Web Token above and this JWT decoder splits it into its three Base64url-encoded components - header, payload, and signature - and displays each one as formatted, human-readable JSON. Timestamp claims (exp, iat, nbf) are converted to local dates so you can immediately see when the token was issued, when it expires, and whether it is currently valid. The tool runs entirely in your browser; no token data is transmitted to any server, which matters when you are inspecting production tokens that contain user identities, session metadata, or access scopes.

What a JWT Contains

A JWT looks like a single opaque string, but it is actually three JSON objects joined by dots. The header declares the signing algorithm (typically HS256 for symmetric HMAC or RS256 for asymmetric RSA) and the token type. The payload carries claims - key-value pairs that communicate identity (sub, email), authorization (role, scope, permissions), token lifecycle (iss, aud, exp, iat, nbf), and any custom data the issuing server chose to include. The signature is a cryptographic seal computed over the header and payload that lets the receiving server verify the token was not tampered with after issuance. This tool lets you decode a JWT token to inspect all three sections without writing code or installing a CLI utility.

JWTs Are Signed, Not Encrypted

The most dangerous misconception about JWTs is that they hide their contents. They do not. Anyone who possesses or intercepts a token can decode JWT payloads instantly - the header and payload are merely Base64url-encoded, not encrypted. The signature proves integrity (the payload has not been modified) but provides zero confidentiality (anyone can read the payload). Never place passwords, credit card numbers, social security numbers, API secrets, or sensitive PII inside a JWT. If you need both tamper detection and content hiding, use JWE (JSON Web Encryption, RFC 7516) or encrypt the payload separately before placing it in the token.

Expiration, Timestamps, and Debugging Auth Failures

The exp claim is a Unix timestamp marking when the token becomes invalid. The iat claim records creation time. The nbf (not before) claim prevents early use. When debugging authentication failures, check exp first: if the current time exceeds exp, the token is expired and the server will reject it regardless of the signature's validity. The second most common issue is clock skew - if the issuing server and the validating server have system clocks that differ by more than the configured tolerance (typically 30-60 seconds), valid tokens appear expired. This JWT decode tool shows all timestamp claims in both Unix and human-readable local time so you can spot expiration and timing issues at a glance.

Common JWT Security Vulnerabilities

The "alg: none" attack: if a server accepts tokens with the algorithm set to "none," an attacker can forge any payload without a signature. Numerous JWT libraries have shipped with this vulnerability. The algorithm confusion attack: changing the header from RS256 (asymmetric) to HS256 (symmetric) and signing with the server's RSA public key (often publicly available) can fool misconfigured validators into accepting a forged token. Weak HMAC secrets: short or guessable strings as the HS256 key allow offline brute-force via tools like hashcat, which tests billions of candidate secrets per second. Token replay: a stolen JWT remains usable until it expires, and JWTs cannot be individually revoked without maintaining a server-side blacklist (which reintroduces the statefulness that JWTs were designed to eliminate). Mitigation: always validate the algorithm against an explicit server-side allowlist, use secrets with at least 256 bits of randomness, verify signatures before trusting any claim, and keep token lifetimes short (5-15 minutes) with a refresh-token rotation mechanism.

JWT vs Session Cookies

Session-based authentication stores state on the server (in memory, a database, or Redis) and sends only a 32-byte session ID in a cookie. The server looks up session data on every request. JWT authentication stores identity and permissions inside the token itself, eliminating server-side session storage. JWTs scale horizontally without shared state, work across domains and microservices, and are a natural fit for API authentication. The tradeoffs: JWTs cannot be instantly revoked (sessions can be deleted server-side at any time), they increase request size (a JWT can be 1-2 KB versus a 32-byte session ID), and an XSS vulnerability that steals a JWT is more dangerous because the token can be used from any machine. Neither approach is universally superior - the choice depends on architecture, scaling requirements, and the security model your application enforces.

Online JWT Decoder and Developer Workflow

During development and incident response, the typical workflow is: intercept or extract the token from a request header, cookie, or log entry; paste it into this online JWT decoder; verify the claims match expectations (correct user, correct scopes, unexpired); check the algorithm header for anything unexpected. For automated validation in code, use well-maintained libraries - jose (JavaScript), PyJWT (Python), java-jwt (Java), or golang-jwt (Go) - rather than hand-parsing the token, because these libraries handle signature verification, algorithm validation, and clock-skew tolerance correctly out of the box.

Frequently asked questions