ManyAITool
All Tools
Developer Tools

JWT Decoder - Decode JSON Web Tokens Free

Free online JWT decoder. Paste a JSON Web Token to instantly decode the header and payload, check expiration, and verify claims. No data sent to any server.

What is JWT Decoder?

A JWT (JSON Web Token) Decoder is a tool that takes an encoded JWT string — the long Base64-encoded text that looks like 'eyJhbGciOiJIUzI1NiIs...' — and splits it into its three readable parts: the header, the payload, and the signature. JWTs are the dominant authentication token format on the web, used by an estimated 80% of modern web APIs for stateless authentication, single sign-on (SSO), and API authorization.

The header contains the signing algorithm (typically HS256 or RS256) and token type. The payload carries the actual claims — user ID (sub), expiration time (exp), issued-at time (iat), issuer (iss), and any custom data like roles or permissions. The signature is a cryptographic hash that verifies the token has not been tampered with. When debugging login failures, 401 errors, or token refresh issues, the first step is always to decode the JWT and check its claims.

This tool decodes instantly in your browser, highlights expiration status with color-coded badges (green for valid, red for expired), converts Unix timestamps to human-readable dates with relative time ('expires in 2 hours'), and lets you copy individual sections. Your token never leaves your device — there are no server calls, no logging, and no analytics on your input.

How JWT Decoder Works

JWT (JSON Web Token) is defined in RFC 7519 as a compact, URL-safe means of representing claims between two parties. The token consists of three Base64url-encoded sections separated by dots: header.payload.signature. The header is a JSON object specifying the signing algorithm ('alg') and token type ('typ'). The payload is a JSON object containing claims — registered claims like 'sub' (subject), 'exp' (expiration), 'iat' (issued at), 'iss' (issuer), and 'aud' (audience), plus any custom claims your application needs.

Two signing algorithms dominate JWT usage. HS256 (HMAC-SHA256) uses a single shared secret key for both signing and verification — fast and simple, but every service that verifies tokens needs the same secret, creating a security risk if any one service is compromised. RS256 (RSA-SHA256) uses asymmetric cryptography: the auth server signs with a private key, and any service can verify with the corresponding public key (often published at a JWKS endpoint). RS256 is the standard for production systems, especially with multiple microservices or third-party integrations.

The signature is computed over the encoded header and payload: HMACSHA256(base64url(header) + '.' + base64url(payload), secret) for HS256. This means changing even one character in the payload invalidates the signature. However, the header and payload are only Base64url-encoded, not encrypted — anyone can decode and read them. JWTs should never contain sensitive data like passwords or credit card numbers unless the entire token is additionally encrypted (JWE).

Common Use Cases

  • Debugging authentication failures by decoding a JWT from the Authorization header to check if it is expired (exp claim), issued to the wrong audience (aud), or missing required claims.
  • Testing API endpoints in tools like Postman or curl by inspecting the JWT payload to verify the correct user ID, roles, and permissions are included before making requests.
  • Performing security audits by reviewing JWT claims to ensure tokens do not contain sensitive data, use appropriate signing algorithms (RS256 over HS256 for public clients), and have reasonable expiration times.
  • Debugging token refresh logic by comparing the 'iat' (issued at) and 'exp' (expiration) timestamps of access tokens and refresh tokens to verify the rotation cycle works correctly.
  • Troubleshooting SSO (Single Sign-On) integrations with providers like Auth0, Okta, or Firebase Auth by inspecting the ID token to verify issuer, audience, and custom claims match your configuration.
  • Verifying webhook payloads from services like Stripe, Twilio, or GitHub that include JWT-signed verification tokens to prove the request is authentic.

How to Use

  1. 1Paste your JWT token into the input field.
  2. 2The header, payload, and signature are decoded instantly.
  3. 3Check the expiration status (green = valid, red = expired).
  4. 4Click 'Copy' to copy any decoded section.

Features

  • Instant JWT decoding with header, payload, and signature display
  • Expiration status indicator (valid/expired) with countdown timer
  • Issued-at and expiry timestamps with relative time display
  • Algorithm and token type badges
  • Copy individual sections (header, payload) with one click
  • 100% client-side — your token never leaves your browser

Tips & Best Practices

  • 💡Never store sensitive data in JWT payloads — they are Base64-encoded, not encrypted. Anyone who intercepts a token can read the claims. Passwords, credit card numbers, and personal secrets should never appear in a JWT.
  • 💡Always check the 'exp' (expiration) claim before trusting a JWT. A common security mistake is decoding the token and using its claims without verifying that it has not expired. Short-lived access tokens (15-60 minutes) limit the damage window if a token is stolen.
  • 💡Use RS256 (asymmetric signing) instead of HS256 (symmetric) for any system where multiple services verify tokens. With HS256, every verifying service needs the shared secret, and a compromise of any one service exposes the signing key.
  • 💡Implement refresh token rotation: each time a refresh token is used, issue a new one and invalidate the old one. If a stolen refresh token is reused, the rotation detects the anomaly and can revoke the entire token family.
  • 💡Store JWTs in httpOnly, secure, SameSite=Strict cookies rather than localStorage. LocalStorage is vulnerable to XSS attacks — any JavaScript running on your page can steal the token. HttpOnly cookies are inaccessible to JavaScript.

Frequently Asked Questions

What is a JWT (JSON Web Token)?
A JWT is a compact, URL-safe token format used for securely transmitting information between parties. It consists of three base64-encoded parts separated by dots: a header (specifying the algorithm), a payload (containing claims/data), and a signature (for verification).
Is it safe to decode JWTs in a browser?
Yes, decoding a JWT does not require a secret key. The header and payload are simply base64-encoded (not encrypted), so anyone can read them. The signature part requires the secret key to verify, but decoding does not expose secrets. This tool processes everything in your browser.
What does 'exp' mean in a JWT payload?
The 'exp' (expiration time) claim identifies the time after which the JWT must not be accepted. It is a Unix timestamp (seconds since January 1, 1970). This tool automatically converts it to a readable date and shows whether the token has expired.
Can this tool verify JWT signatures?
This tool decodes and displays JWT contents but does not verify signatures. Signature verification requires the secret key or public key used to sign the token, which should never be shared in a browser tool.

Related Tools