JWT Decoder

Decode JWT tokens to inspect their header, payload, and signature. View claims, check expiration status, and understand the signing algorithm — all client-side.

What is JWT Decoder?

A JWT Decoder splits a JSON Web Token into its three Base64URL-encoded components—header, payload, and signature—and displays them in a human-readable JSON format. JSON Web Tokens (JWTs, defined in RFC 7519) are the dominant standard for stateless authentication and authorization in modern web APIs, microservices, single-page applications, and mobile apps. A JWT is a compact, URL-safe string divided by two periods into three parts: the header (specifying the token type and signing algorithm), the payload (containing claims—statements about the user or session like user ID, roles, permissions, and expiration time), and the signature (a cryptographic hash that verifies the token has not been tampered with). Because JWTs are used for authentication, they appear in HTTP Authorization headers, OAuth flows, SSO systems, and API gateway responses constantly during development. When a login fails with a 401 Unauthorized error, when a session unexpectedly expires, when you need to verify which user roles a token grants, or when debugging a multi-service authentication flow, reading the JWT payload is the first debugging step. This tool decodes that payload instantly without requiring a backend.

How to Use JWT Decoder

Paste the complete JWT string into the input field—it will look like three Base64URL strings separated by periods (xxxxx.yyyyy.zzzzz). The tool immediately splits and decodes all three sections. The Header panel shows the signing algorithm (alg, typically HS256, RS256, or ES256) and token type (typ: JWT). The Payload panel shows all claims including standard registered claims (iss, sub, aud, exp, nbf, iat, jti) and any custom claims your application adds (user ID, roles, email, tenant ID). Timestamps in the payload (exp, iat, nbf) are automatically converted to human-readable dates so you can instantly see when the token was issued and when it expires. A visual expiration indicator shows whether the token is currently valid, already expired, or not yet active. The Signature section shows the encoded signature for reference, along with the algorithm used. Copy any decoded section using the copy button. All decoding happens in your browser—nothing is transmitted anywhere.

FAQ

Is it safe to paste my real JWT here?

Yes. All decoding is performed entirely in your browser using local JavaScript. No data is transmitted to any server. However, remember that JWTs are access credentials—treat them like passwords. Do not paste production tokens into any web tool when working on shared computers, and avoid posting JWTs in public spaces like forums, GitHub issues, or chat messages, as anyone with a valid JWT can use it to authenticate until it expires.

Can this tool verify whether a JWT signature is valid?

No. Verifying a JWT signature requires the secret key (for HMAC algorithms like HS256) or the public key (for asymmetric algorithms like RS256 or ES256). A client-side tool cannot safely access these secrets. This decoder only reads the header and payload, which are Base64URL-encoded and publicly readable—they contain no secret information. For production signature verification, use a server-side JWT library appropriate for your language (jsonwebtoken for Node.js, PyJWT for Python, java-jwt for Java, etc.).

What do the standard JWT claims mean?

The registered claims defined in RFC 7519 are: iss (Issuer—who issued the token, e.g., your auth server URL), sub (Subject—who the token represents, usually a user ID), aud (Audience—who the token is intended for, e.g., your API's identifier), exp (Expiration Time—Unix timestamp after which the token must be rejected), nbf (Not Before—Unix timestamp before which the token is not yet valid), iat (Issued At—Unix timestamp when the token was created), and jti (JWT ID—a unique token identifier for preventing replay attacks). Custom claims beyond these are application-specific.

What is the difference between JWT, JWS, and JWE?

JWT (JSON Web Token) is the general term for the token concept. JWS (JSON Web Signature) is a signed JWT—the most common type you encounter, where the payload is readable but the signature ensures it hasn't been tampered with. JWE (JSON Web Encryption) is an encrypted JWT where the payload itself is encrypted and only readable by the intended recipient. This decoder handles JWS tokens (the standard signed form). Encrypted JWE tokens look different and require the decryption key to read the payload.

How do I get a JWT token to decode?

In a browser, JWT tokens are commonly stored in: localStorage or sessionStorage (inspect with F12 DevTools > Application > Storage), Cookies (inspect with F12 DevTools > Application > Cookies, look for tokens named access_token, auth_token, or jwt), or the Authorization header of network requests (F12 DevTools > Network tab > click a request > Headers > find 'Authorization: Bearer xxxxx'). In code, your authentication library (Firebase, Auth0, Supabase, NextAuth) exposes methods to retrieve the current session's access token.