JWT Decoder

Paste any JWT token and instantly see its decoded header and payload as formatted JSON.

Our decoder:

• identifies the signing algorithm
• displays all standard and custom claims
• converts Unix timestamps to human-readable dates

Color-coded display makes it easy to distinguish the three JWT parts.

Debug JWT issues by checking expiration times, issued-at timestamps, and claim values.

Our tool shows whether tokens are expired, how long until expiration, and highlights potential issues.

Essential for:

• API development
• authentication debugging
• security auditing

A JSON Web Token (JWT) is a compact, URL-safe way to represent claims transferred between two parties, defined by RFC 7519 from the IETF.

A JWT has three parts separated by dots, each Base64URL-encoded per RFC 4648:

• a header that declares the signing algorithm and token type using JSON (RFC 8259)
• a payload that carries claims — statements about an entity such as a user, plus metadata like expiration
• a signature that binds the header and payload together so tampering is detectable

This structure lets services verify identity without a database lookup, which is why JWTs are common in stateless authentication and OpenID Connect flows.

To decode a JWT, split the token at its two dots into three segments, then Base64URL-decode the first two.

The first segment yields the header JSON, and the second yields the payload JSON, both readable as plain text per RFC 8259.

Base64URL (RFC 4648, section 5) replaces '+' with '-' and '/' with '_' and omits padding, so a standard Base64 decoder may fail without adjustment. Our tool handles this automatically and pretty-prints the result.

The third segment, the signature, is not decoded to text because it is a raw cryptographic value.

As MDN Web Docs notes, decoding is not verification — reading a payload never confirms the token is authentic.

No — a standard signed JWT (a JWS) is encoded, not encrypted, so anyone holding the token can read its payload.

Base64URL encoding (RFC 4648) is reversible and provides zero confidentiality; it only makes binary-safe transport possible. The signature described in RFC 7515 (JSON Web Signature) protects integrity and authenticity, not secrecy.

If you need the contents hidden, use JWE (JSON Web Encryption, RFC 7516) instead.

OWASP and the IETF both stress this distinction: never place passwords, API secrets, or personally identifiable data in a signed JWT payload, because a decoder like this one reveals every claim in plain text without any key.

Registered JWT claims are standardized by RFC 7519 so different systems interpret them consistently.

The core set includes:

• 'iss' (issuer)
• 'sub' (subject, the token's principal)
• 'aud' (audience, the intended recipient)
• 'exp' (expiration time)
• 'nbf' (not before)
• 'iat' (issued at)
• 'jti' (a unique token ID)

The exp, nbf, and iat values are NumericDate values — seconds since the Unix epoch — which our decoder converts to human-readable dates. Applications add custom (private) claims for roles, scopes, or tenant IDs.

Per the specification, verifiers must reject a token whose 'exp' has passed or whose 'aud' does not match the expected audience, preventing misuse across services.

JWT signing algorithms are defined in RFC 7518 (JSON Web Algorithms) and identified by the header's 'alg' value.

• HMAC algorithms (HS256, HS384, HS512) use a single shared secret for both signing and verification, which is simple but requires every verifier to hold that secret.
• RSA algorithms (RS256, RS384, RS512) and RSASSA-PSS (PS256) use a private key to sign and a public key to verify, ideal for distributed systems and OpenID Connect.
• ECDSA algorithms (ES256, ES384, ES512) offer equivalent security with smaller keys and signatures.

NIST publishes the underlying SHA-2 and ECDSA standards. Our decoder reads the 'alg' field so you can confirm which scheme a token uses.

JWTs are widely used for stateless authentication, authorization, and secure information exchange in modern APIs.

After a user logs in, a server issues a signed JWT that the client returns in the HTTP Authorization header as a Bearer token, per RFC 6750. Because the signature is self-contained, backend services can verify the token without querying a session store, improving scalability.

JWTs also power OpenID Connect ID tokens and OAuth 2.0 access-token patterns.

Developers use decoders during debugging to inspect claims, confirm audience and issuer values, and check expiration when an API returns 401 errors. As MDN Web Docs describes, this token-based flow underpins many single-sign-on and microservice architectures.

Secure JWT usage centers on validating the algorithm, verifying the signature, and enforcing expiration.

OWASP warns against the classic 'alg: none' attack and algorithm-confusion attacks, where a server tricked into treating an RS256 public key as an HMAC secret can be forged; always pin the expected algorithm rather than trusting the header.

Key practices:

• Use short 'exp' lifetimes with refresh tokens, and validate 'iss' and 'aud' on every request.
• Never store secrets in the payload, since it is only Base64-encoded.
• Transmit tokens exclusively over HTTPS, and consider revocation strategies because standard JWTs cannot be individually invalidated before expiry.

Following these IETF and OWASP recommendations closes the most exploited JWT vulnerabilities.

The most common mistakes when working with JWTs include:

• Confusing decoding with verification: reading a payload with a decoder proves nothing about authenticity, since anyone can craft an unsigned or forged token.
• Trusting the header's 'alg' value blindly, which enables algorithm-confusion attacks flagged by OWASP.
• Misreading expiration by comparing the epoch-seconds 'exp' against milliseconds, causing valid tokens to appear expired.
• Using a standard Base64 decoder instead of Base64URL (RFC 4648), which can corrupt output because of the different alphabet and missing padding.
• Placing sensitive data in the payload, which leaks it, because the token is encoded, not encrypted.

Verifying signatures server-side with the expected key and algorithm avoids these pitfalls.

This JWT decoder processes tokens entirely client-side, so your token never leaves your device or reaches any server.

Because a signed JWT is only Base64URL-encoded (RFC 4648), decoding requires no network call — the header and payload are simply reversed from their encoded form using JavaScript in your browser.

Keeping the operation local matters for security: tokens often contain live session credentials, and pasting them into a server-side tool could expose them in logs or transit. OWASP recommends minimizing where sensitive credentials travel.

A browser-only decoder lets developers safely inspect production tokens during debugging while honoring least-exposure principles, without transmitting authorization data to a third party.