Free Online JWT Decoder
Paste a JWT and see its header, payload, and expiration decoded
Paste a JWT token above to decode it.
All decoding happens in your browser. Your token is never sent to any server. This tool does not verify signatures — it only decodes the header and payload.
Try these next
Why use JWT Decoder
- Converts timestamp claims (iat, exp, nbf) to readable dates automatically -- no manual epoch conversion.
- Flags expired tokens immediately, so you diagnose 401 errors in seconds.
- Labels registered claim names (iss, sub, aud, exp, etc.) so you don't have to memorize RFC 7519 abbreviations.
How it works
A JWT is three Base64URL-encoded segments separated by dots. The decoder splits the input on the dot character, then decodes each segment by replacing URL-safe characters (- with + and _ with /) and padding with = signs to standard Base64, which is then decoded with atob(). The header and payload segments are parsed as JSON and pretty-printed with syntax highlighting. Timestamp claims (exp, iat, nbf) are detected by matching known claim names and checking that the value is a plausible Unix epoch (a number greater than roughly 1 billion). These are converted to human-readable dates by multiplying by 1000 and passing the result to the Date constructor. Expiration status is determined by comparing the exp value against the current time via Date.now(). The signature segment is displayed as a raw Base64 string because verifying it would require the signing secret or public key, which should never be entered into a browser tool.
About this tool
Need to figure out why a 401 keeps firing? Paste the JWT from the Authorization header here. You'll see the header, payload, and signature broken out as formatted JSON in under a second. Timestamp claims (iat, exp, nbf) are automatically converted to human-readable dates, and the tool flags whether the token is currently expired with a color-coded indicator. Registered claim names from RFC 7519 -- iss, sub, aud, exp, nbf, iat, jti -- are labeled automatically so you don't have to memorize abbreviations. This is a decoder, not a verifier. It doesn't check signatures (that would require your signing key, which should never go into a browser tool). It decodes the Base64URL segments and presents what's inside. Useful for debugging OAuth 2.0 flows, checking whether an identity provider includes the expected scopes and audience, and verifying that short-lived CI/CD tokens rotate correctly.
How to use JWT Decoder
- Paste the JWT. Copy the token from an Authorization header, a cookie, or localStorage and paste it in.
- Read the decoded parts. Header, payload, and signature appear as formatted JSON. Timestamp claims show human-readable dates.
- Check expiration. A color-coded indicator tells you whether the token is expired or still valid.
Use cases
- A 401 Unauthorized keeps firing. Paste the JWT to check whether exp has passed or aud doesn't match the expected audience.
- You're integrating an OAuth 2.0 provider and need to confirm which custom claims (roles, user ID, org) the access token actually contains.
- During a security review, you paste a sample token to verify the algorithm is RS256, not the insecure 'none' algorithm.
Frequently Asked Questions
A JSON Web Token (JWT) is a compact, URL-safe token format used to securely transmit information between parties as a JSON object. JWTs are commonly used for authentication and authorization in web applications, APIs, and single sign-on systems. They consist of three parts: a header, a payload, and a signature.
A JWT consists of three Base64URL-encoded parts separated by dots. The header specifies the token type and signing algorithm (e.g., HS256, RS256). The payload contains claims -key-value pairs with data like user ID, roles, and expiration time. The signature is created by signing the header and payload with a secret or private key.
Yes. The header and payload of a JWT are only Base64URL-encoded, not encrypted, so anyone with the token can read them. Decoding does not require a secret key. This tool processes everything in your browser and never sends your token to a server, so your token data remains private.
The 'exp' (expiration time) claim identifies the time after which the JWT must not be accepted. It is expressed as a Unix timestamp (seconds since January 1, 1970 UTC). This tool automatically converts exp timestamps to human-readable dates and indicates whether the token has expired.
This tool focuses on decoding and inspecting JWT contents. Signature verification requires the secret key (for HMAC algorithms) or the public key (for RSA/ECDSA algorithms), which should never be shared in a browser tool. For signature verification, use server-side libraries in your application code.
HS256 (HMAC-SHA256) uses a single shared secret for both signing and verification, making it simpler but requiring the secret to be shared. RS256 (RSA-SHA256) uses an asymmetric key pair -a private key signs the token and a public key verifies it. RS256 is preferred in distributed systems where multiple services need to verify tokens.
A JWT is expired when the current time exceeds the 'exp' claim value. This is normal behavior -tokens are designed to expire for security. Check if your application is refreshing tokens properly, if the token issuer is setting appropriate expiration times, or if there is a clock skew between your server and the token issuer.
Standard claims include 'iss' (issuer), 'sub' (subject/user ID), 'aud' (audience), 'exp' (expiration time), 'nbf' (not before), 'iat' (issued at), and 'jti' (JWT ID). Applications often add custom claims like 'role', 'email', 'name', or 'permissions' to carry application-specific data.
Related Tools
Discover more free utilities to enhance your productivity.
Base64 Encoder / Decoder
Encode text to Base64 or decode Base64 back to readable text
JSON Formatter & Validator
Paste messy JSON, get clean indented output
Hash Generator
Compute SHA-1, SHA-256, and SHA-512 hashes from text or files
Password Generator
Create cryptographically random passwords with adjustable length and character types