JWT Decoder

About a JWT (JSON Web Token)

JWT is an open standard (RFC 7519) for securely transmitting JSON-formatted data between parties. It is widely used for authentication, authorization, and information exchange in web applications. A JWT consists of three parts separated by dots: Header (algorithm info), Payload (actual data/claims), and Signature (integrity check). The server verifies the signature with a secret key to confirm the token has not been tampered with. During API development and debugging, you frequently need to inspect token contents to diagnose authentication issues. This tool lets you instantly view the Header and Payload without manually performing Base64 decoding. It also automatically checks expiration status, significantly reducing the time spent troubleshooting token-related problems.

How It Works

The JWT Decoder splits the input token string into three parts using the dot (.) delimiter. The Header and Payload are each Base64URL-encoded, so the tool converts them to standard Base64, decodes them with atob(), and parses the result with JSON.parse(). Base64URL differs from standard Base64 by replacing + with -, / with _, and omitting padding characters (=). The third part, the Signature, is a hash generated using the algorithm specified in the Header and the secret key. During signature verification, the tool uses the Web Crypto API to recompute the signature with HMAC-SHA256/384/512 and compares it byte-by-byte against the original. Time-related claims like exp, iat, and nbf are automatically converted from Unix timestamps to human-readable date formats and compared against the current time to determine the token's validity status.

User Guide

1. Paste your JWT token string into the input field. It will auto-decode when pasted from the clipboard.
2. Click the "Decode" button to see the Header, Payload, and Signature displayed as formatted JSON.
3. Check the token status indicator to see whether the token is currently valid or expired.
4. Review the claims detail section for each claim's key, value, and meaning.
5. To verify the signature, enter the secret key and click the "Verify" button.

Core Features

• Splits JWT tokens into Header, Payload, and Signature with formatted JSON display
• Automatically detects token status: valid, expired, or not yet valid
• Shows remaining validity time or how long ago the token expired
• Explains registered claims (sub, iss, aud, exp, iat, nbf, jti) with descriptions
• Verifies HMAC-based signatures (HS256, HS384, HS512)
• Auto-decodes on paste for a fast workflow

When This Comes in Handy

• Quickly inspecting the payload of an authentication token during API development
• Debugging token expiration times or checking validity periods
• Analyzing the claim structure of JWTs received from third-party services
• Examining access tokens issued during OAuth 2.0 flows
• Verifying the signing algorithm is correct and validating with a secret key

Common Questions

Decoding Is Not Verification

It is worth being precise about what this tool does. Decoding simply reverses the Base64URL encoding so you can read the Header and Payload -- anyone can do it, no secrets required. Verification is a separate cryptographic step: the signature is recomputed from the Header and Payload using the secret key and compared with the signature attached to the token. Only a successful verification tells you the token is authentic and untampered. A decoded payload that "looks right" proves nothing by itself, because an attacker can craft a token with any claims they like; what they cannot do without the key is produce a valid signature. So treat the decode view as a reading aid for debugging, and treat the Verify button (or your server's middleware) as the actual security check. And a firm rule: never paste a production signing secret into any online tool. Everything here runs locally in your browser, but building the habit of using test keys for experimentation costs nothing and protects you everywhere else.

Real-World Debugging Scenarios

The sudden 401: A request that worked ten minutes ago now returns 401 Unauthorized. Paste the bearer token from the request header into the decoder and look at the status banner first -- an expired exp claim is by far the most common culprit, and the tool shows exactly how long ago it lapsed. If the token is still valid, compare iss and aud against what the server expects; a token minted by the staging identity provider being sent to production fails in exactly this quiet way.

Missing permissions after login: When a user authenticates successfully but gets 403 errors on specific endpoints, decode their access token and inspect the custom claims -- roles, scopes, or tenant IDs. Nine times out of ten the claim your authorization middleware checks is either absent, misspelled, or nested differently than the code assumes. Seeing the actual JSON removes all guesswork.

Sanity-checking token lifetimes: After changing token issuance code, decode a freshly issued token and subtract iat from exp. If you configured a 15-minute lifetime but the difference comes out to 900,000 instead of 900, someone wrote milliseconds where the spec expects seconds — and you have caught it before your users did. The same check catches millisecond timestamps accidentally written where seconds belong, which show up here as dates thousands of years in the future.

Handling Tokens and Secrets Safely

A JWT is a credential. Whoever holds a valid access token can act as its subject until it expires, so tokens deserve the same care as passwords even though their contents are readable. A few practices worth adopting: keep access token lifetimes short and rely on refresh tokens for longevity; avoid logging full tokens in application logs (log the jti or a truncated prefix instead); and never commit tokens captured during debugging into version control or paste them into shared chat channels. On the payload side, remember that everything you put in a claim is visible to the client and to anyone who intercepts the token over a misconfigured connection -- user IDs and roles are fine, but email addresses are borderline and anything more sensitive belongs server-side. Finally, be suspicious of any token whose Header reports "alg": "none" or an algorithm your server does not explicitly allow; accepting attacker-chosen algorithms is one of the oldest and most damaging JWT implementation mistakes.

Tools That Pair Well

• CSS Minifier - Minify CSS code
• JSON to CSV Converter - Convert between JSON and CSV
• Color Contrast Checker - Check WCAG color contrast
• QR Code Scanner - Scan and read QR codes
• ASCII/Unicode Converter - Convert characters and codes

Related Guides

• JWT 토큰 이해하기