JWT Decoder
Decode and inspect JWT token claims instantly — no library needed
Warning: This tool only decodes JWTs. It does NOT verify signatures. Always verify JWT signatures on your server for security.
What is JWT Decoder?
JSON Web Tokens (JWTs) are the standard mechanism for transmitting authentication and authorization data in modern web applications. A JWT consists of three Base64url-encoded parts separated by dots: a header describing the algorithm, a payload containing claims (user data, expiry, roles), and a signature that verifies the token's integrity. When debugging authentication issues — an expired token, a missing claim, a wrong audience — developers need to inspect the payload quickly without writing decoding code. Our free JWT Decoder takes any JWT string, splits it into its three components, and displays the header and payload as formatted, readable JSON. You can immediately see who issued the token, when it expires, what permissions are encoded, and which user it belongs to. This is an inspection-only tool — it does not validate the signature against a secret key, which means it is safe to use in any browser without exposing your signing keys. It is indispensable when debugging OAuth 2.0 flows, troubleshooting API 401 errors, inspecting OpenID Connect id_tokens, or verifying that your auth server is encoding the correct claims.
How to Use JWT Decoder
- 1
Paste Your JWT
Copy the JWT string from your browser's localStorage, an Authorization header, an API response, or your auth server's debug output. Paste it into the input field — the tool accepts the full three-part token.
- 2
Instant Decode
The tool splits the token at the dots, Base64url-decodes the header and payload sections, and parses them as JSON — all instantly as you type or paste.
- 3
Inspect the Claims
Read the formatted header (algorithm, token type) and payload (sub, iss, exp, iat, roles, custom claims) side by side. Check expiry timestamps and identify missing or incorrect claims.
Use Cases
Debugging API Authentication Errors
When a backend returns a 401 Unauthorized or 403 Forbidden, the first step is inspecting the token the client sent. Paste the JWT here to instantly see whether the token is expired, whether the audience (aud) claim matches the API, or whether the required roles or permissions are missing from the payload — without writing a single line of decoding code.
Verifying Auth Server Configuration
When setting up OAuth 2.0, OpenID Connect, or a custom auth server, you need to confirm the server is encoding the correct claims in the right format. Decode the issued tokens here to verify the issuer (iss), subject (sub), scopes, and any custom claims your application depends on before writing the client-side validation logic.
Inspecting Third-Party Identity Provider Tokens
Identity providers like Auth0, Cognito, Firebase Auth, and Okta issue JWTs with provider-specific claim structures. When integrating these services, decode a sample token here to map out exactly which fields contain the user ID, email, roles, and tenant ID before writing the user profile parser in your application.
Features
Header & Payload Decoded Side by Side
Displays the algorithm header and claims payload as formatted JSON so you can inspect every field at a glance without mentally parsing Base64.
Expiry Time in Human-Readable Format
Converts the exp (expiry) and iat (issued-at) Unix timestamps into readable date-time strings so you can instantly see whether a token is still valid.
Inspection Only — No Secret Key Required
Decodes the header and payload without verifying the signature. You never need to enter your signing secret, keeping your keys safe.
Runs Entirely in Your Browser
Token decoding happens 100% client-side. Your tokens, user data, and claims are never sent to any server.
Frequently Asked Questions
A JSON Web Token (JWT) is a compact, URL-safe token format defined by RFC 7519. It has three Base64url-encoded parts separated by dots: (1) the Header, which specifies the signing algorithm (e.g., HS256 or RS256) and token type; (2) the Payload, which contains claims — statements about the user or session such as sub (subject), exp (expiry), iss (issuer), and custom fields; (3) the Signature, which is a cryptographic hash of the header and payload used to verify the token has not been tampered with.
No, this tool only decodes and displays the header and payload — it does not verify the signature against a secret key or public key. Signature verification requires the signing secret (for HMAC algorithms) or the public key (for RSA/EC algorithms), which you should never paste into a web tool. For production signature verification, use a server-side JWT library in your programming language.
This tool runs entirely in your browser — no data is sent to any server. However, as a general security practice, avoid pasting production access tokens containing sensitive user data into any online tool. For debugging production issues, use tokens from a test or staging environment, or redact the signature portion before pasting.
The exp (expiration time) claim is a Unix timestamp indicating when the token ceases to be valid. Servers must reject tokens with an exp value in the past. This is one of the most common causes of 401 errors — a token that was valid when issued but has since expired. This decoder converts the exp value to a human-readable date so you can instantly see if expiry is the problem.
HS256 (HMAC-SHA256) uses a single shared secret key for both signing and verification — simpler but requires both the issuer and verifier to share the secret securely. RS256 (RSA-SHA256) uses a private key to sign and a public key to verify — the public key can be shared openly, making RS256 better suited for multi-service architectures where many services verify tokens but only one issues them. Auth0, Cognito, and most enterprise identity providers default to RS256.
Need a Professional Website?
JAIDOO EMPIRE builds fast, SEO-optimised websites for businesses worldwide. All free tools are built and maintained by our team.
Start Your Project
