JWT Decoder
Decode and inspect JSON Web Tokens instantly in your browser. Paste any JWT to extract and read the header, payload, and signature — no libraries, no installs, your token never leaves your machine.
Decode and inspect JSON Web Tokens instantly in your browser. Paste any JWT to extract and read the header, payload, and signature — no libraries, no installs, your token never leaves your machine.
This developer tool is built with a privacy-first mindset. All transformations, formatting, and operations execute entirely in your local browser sandbox without transmitting sensitive tokens, keys, or code to external servers.
JWT — JSON Web Token — is an open standard (RFC 7519) for securely transmitting information between systems as a compact, URL-safe string. A JWT consists of three base64url-encoded sections separated by dots: the header, the payload, and the signature. The header identifies the signing algorithm. The payload carries the claims — data about the user or session. The signature proves the token hasn't been tampered with.
JWTs are stateless by design. Unlike session cookies that require the server to look up session data on every request, a JWT carries everything the server needs to verify the request right inside the token. This makes them ideal for distributed systems, microservices, and APIs where you cannot rely on shared session storage across multiple servers.
In my experience building authentication systems, JWTs are everywhere — OAuth 2.0 access tokens, OpenID Connect ID tokens, API gateway authorization, machine-to-machine service calls. The standard is solid, but the implementation details matter enormously. A JWT with a weak secret, an overly long expiry, or missing claim validation is a serious security vulnerability. Understanding what's actually inside your tokens is the first step to getting that right.
This JWT Decoder takes any JWT string and splits it into its three components — header, payload, and signature — then base64url-decodes and displays each part as formatted, human-readable JSON. You can immediately see the algorithm being used, all the claims in the payload, the token's expiry timestamp converted to a readable date, and the raw signature string.
It handles all standard JWT algorithms: HS256, HS384, HS512 (HMAC-SHA), RS256, RS384, RS512 (RSA), ES256, ES384, ES512 (ECDSA), and PS256, PS384, PS512 (RSA-PSS). Whatever your identity provider or auth library is producing, this tool will decode it correctly.
One important distinction: this tool decodes the token — it does not verify the signature. Signature verification requires the secret key or the public key used to sign the token, which you should never paste into any online tool. Decoding without verification is the right approach for debugging and inspection — it shows you exactly what claims are present and whether the token structure is valid, without any risk of exposing your signing keys.
Step 1
Paste your JWT string into the input field — a JWT looks like three base64url-encoded strings joined by dots, for example eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.abc123. If you don't have one handy, click Load Example to see a real decoded token immediately.
Step 2
Click Decode JWT Token — the tool instantly splits the token at each dot, base64url-decodes each section, and displays the header and payload as formatted JSON. The entire process happens in your browser in milliseconds.
Step 3
Read the Header section — this tells you the token type (always JWT) and the algorithm used to sign it, such as HS256 for HMAC-SHA256 or RS256 for RSA. If the algorithm shows "none", treat that token as a serious security red flag.
Step 4
Read the Payload section — this contains the claims: sub (the subject, usually a user ID), iat (issued at timestamp), exp (expiry timestamp), iss (issuer), aud (audience), and any custom claims your application adds like roles, permissions, or tenant IDs. Check the exp claim first if you're debugging a 401 error.
Step 5
Check the Signature section — the raw signature string is displayed but not verified. To verify the signature you need the secret key or public key used to sign the token. Never paste signing keys into any online tool — signature verification should happen in your application code using a trusted JWT library.
The most common authentication bugs I've debugged over 15 years come down to one thing: nobody actually looked inside the token. The user is getting a 401, the token looks fine as a string, but when you decode it you immediately see the problem — the exp claim expired 3 hours ago, the sub is the wrong user ID, the aud doesn't match the API it's being sent to, or the iss is pointing to the staging environment in production. These bugs are invisible until you open the token.
JWT.io is the well-known tool for this, but it processes your tokens on an external server and stores nothing only because you trust their privacy policy. When you're debugging authentication in a production system, the tokens you're inspecting often contain real user identifiers, session data, and authorization claims. Pasting those into a third-party tool is a risk. This decoder runs entirely in your browser — the token string is decoded using JavaScript locally and never transmitted anywhere.
Beyond debugging, this tool is useful during API integration. When you're consuming a third-party API that uses JWT authentication, decoding the token tells you exactly which claims are available to use in your application logic — which roles, permissions, tenant IDs, or custom claims the identity provider is including. That's information you can't always find clearly documented.
100% browser-based — your JWT tokens are decoded locally using JavaScript and are never transmitted to any server
Supports all standard algorithms — HS256 HS384 HS512 RS256 RS384 RS512 ES256 ES384 ES512 PS256 PS384 PS512
Human-readable timestamps — iat and exp Unix timestamps are automatically converted to readable dates so you can immediately see if a token has expired
Instant decoding — results appear immediately with no server round-trip delay
Privacy-safe — ideal for inspecting tokens that contain real user data authorization claims or session information without third-party risk
Full claim visibility — every standard and custom claim in the payload is displayed clearly so you know exactly what your identity provider is issuing
No installation required — works in any modern browser with no account setup or configuration
Algorithm visibility — the header section shows exactly which signing algorithm was used so you can catch weak or unexpected algorithm choices immediately
Debugging 401 Unauthorized errors by inspecting token claims and expiry
Verifying which user ID and roles are encoded in an authentication token
Checking token expiry timestamps when sessions are expiring unexpectedly
Inspecting custom claims added by your identity provider or auth library
Understanding the structure of third-party API tokens during integration
Auditing tokens in security reviews to verify claim contents and algorithm usage
Comparing tokens from different environments to catch staging vs production misconfigurations
Learning JWT structure and claims without writing any code
Example Input
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyXzEyMzQ1IiwibmFtZSI6IlByaXlhIFNpbmdoIiwicm9sZSI6InByaW5jaXBhbC1lbmdpbmVlciIsImlhdCI6MTcxNjEyOTYwMCwiZXhwIjoxNzE2MjE2MDAwfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
Example Output
Header:
{
"alg": "HS256",
"typ": "JWT"
}
Payload:
{
"sub": "user_12345",
"name": "Priya Singh",
"role": "principal-engineer",
"iat": 1716129600,
"exp": 1716216000
}
Expiry: May 20, 2026, 12:00:00 PM UTC
Issued At: May 19, 2026, 12:00:00 PM UTC
Algorithm: HS256
Signature: SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c (not verified)Invalid Token: The tool requires a valid JWT string with exactly three dot-separated sections. If your string has fewer or more than two dots it is not a valid JWT.
Malformed Header: The header section must be a valid base64url-encoded JSON object containing at least the alg field. Corrupted or truncated tokens will fail here first.
Malformed Payload: The payload section must also be valid base64url-encoded JSON. If the token was manually edited or partially copied the payload decode will fail.
Expired Token: The tool will decode an expired token successfully but the exp timestamp will show a date in the past. Expiry is a validation concern for your server not a decoding concern.
Algorithm None: If the decoded header shows alg set to none this is a critical security issue in your system. Tokens with no algorithm bypass signature verification entirely and should be rejected by your server.
⚠Pasting the full Authorization header instead of just the token
Best Practice: The JWT string starts after the word Bearer and a space. If your Authorization header is Bearer eyJhbG... then paste only the eyJhbG... part. Pasting the full header string including Bearer will cause an invalid token error because the decoder expects exactly three dot-separated base64url sections.
⚠Confusing decoding with verification
Best Practice: Decoding a JWT reads the contents of the token without checking whether the signature is valid. A decoded token can still be a forged or tampered token. Signature verification — which requires the secret key or public key — must happen in your server-side code using a trusted JWT library like jsonwebtoken for Node.js, PyJWT for Python, or jjwt for Java. Never rely on client-side decoding alone for security decisions.
⚠Copying a truncated token from logs
Best Practice: Log aggregation tools like Datadog, Splunk, and CloudWatch often truncate long strings at 1024 or 2048 characters. JWTs — especially those with many claims or RSA signatures — can exceed this length. If your pasted token ends with ... or is missing its third section, go back to the original request headers to get the complete token string.
⚠Expecting the decoder to tell you if the token is valid
Best Practice: A successfully decoded token only means the token is structurally valid base64url-encoded JSON. It does not mean the token is authentic, unexpired, or intended for your application. Always check the exp claim manually in the decoded output to see if the token has expired, and verify the iss and aud claims match what your application expects.
⚠Pasting tokens with sensitive production credentials into public tools
Best Practice: This decoder runs entirely in your browser — your token is never sent anywhere. But if you use other online JWT tools, your token is transmitted to their servers. For tokens that contain real user data, internal system identifiers, or authorization claims from a live production environment, always use a local or browser-based tool. A JWT payload is only base64url encoded, not encrypted, so anyone who receives it can read its contents.
JWT
Syntaxes and patterns for JSON Web Tokens: structure (Header.Payload.Signature), signing keys, validation, claims (sub, exp, iat), and storage.
Regex Cheatsheet
Interactive guide to Regex anchors, character classes, quantifiers, lookarounds, capturing groups, and search flags.
HTTP Headers Cheatsheet
Complete guide to standard and security HTTP headers including Authorization, CORS control, caching policies, and CSP directives.
Git Cheatsheet
Quick reference guide for essential Git commands, branching workflows, remote repositories, stashing, and rollbacks.
Does this tool verify the JWT signature?
No, and that is intentional. Signature verification requires the secret key or public key used to sign the token. You should never paste signing keys into any online tool. This decoder reads the header and payload — which are only base64url encoded, not encrypted — and displays them clearly. Signature verification belongs in your server-side application code using a trusted JWT library.
Is it safe to paste my JWT tokens into this tool?
Yes. This tool runs entirely in your browser using JavaScript. Your token string is decoded locally and is never transmitted to any server, never logged, and never stored. That said, remember that JWT payloads are not encrypted — they are only base64url encoded. Anyone who can see your token string can read its contents, so treat JWTs like passwords and avoid sharing them in public channels.
Can I decode multiple tokens at once?
Currently the tool decodes one token at a time. Paste your token, decode it, inspect the output, then clear and paste the next one. If you need to batch-decode multiple tokens, that is a feature you can request — but for most debugging workflows, one at a time is sufficient since you are usually investigating a specific token from a specific request.
What is the difference between iat, exp, and nbf claims?
iat is the issued-at timestamp — when the token was created. exp is the expiry timestamp — after this time the token should be rejected by any server that validates it correctly. nbf is not-before — the token should not be accepted before this timestamp. All three are Unix timestamps (seconds since January 1, 1970). This tool converts them to human-readable dates automatically so you can immediately see if a token has expired or is not yet valid.
What JWT signing algorithms does this decoder support?
The decoder supports all standard JWT algorithms: HS256, HS384, and HS512 (HMAC with SHA-2), RS256, RS384, and RS512 (RSA with SHA-2), ES256, ES384, and ES512 (ECDSA with SHA-2), and PS256, PS384, and PS512 (RSA-PSS with SHA-2). The algorithm is read from the alg field in the JWT header. If you see alg set to none in a token your application is accepting, that is a critical security vulnerability.
Why does my token say it is expired even though I just generated it?
The most common cause is a clock skew issue — your server that generated the token and the system you are testing on have slightly different system clocks. JWTs use Unix timestamps in UTC, so even a 1-minute difference can make a token appear expired. Check the exp value in the decoded payload against your current UTC time. If the difference is small, add a clock skew tolerance of 30–60 seconds in your token validation logic.
What is the sub claim and why is it important?
sub stands for subject and identifies who the token is about — typically a user ID, service account ID, or device identifier. It is one of the most important claims because your application logic usually depends on it to identify the requesting user or system. If you are seeing authorization bugs where the wrong user's data is returned, the sub claim is the first thing to check in the decoded payload.
Can I use this tool to debug tokens from Auth0, Firebase, Okta or Cognito?
Yes. All major identity providers issue standard JWTs that follow RFC 7519. Tokens from Auth0, Firebase Authentication, Okta, AWS Cognito, Azure AD, Google OAuth, and Keycloak all decode correctly with this tool. Each provider adds their own custom claims on top of the standard ones — Auth0 adds namespace-prefixed custom claims, Firebase adds firebase-specific fields, Cognito adds cognito:username and cognito:groups. This tool will display all of them clearly in the payload section.
JWT vs Session Cookies: Which is Better for Scalable Microservices in 2026?
JWT vs Session Cookies 2026: Which authentication method is better for scalable microservices? In-depth comparison covering scalability, security, performance, revocation, refresh tokens, and expert architectural advice.
How to Secure a Spring Boot Application in 10 Minutes: The 2026 Developer Security Checklist
A Spring Boot app can look production-ready and still expose dangerous defaults — from open actuator endpoints and weak JWT filters to hardcoded secrets, vulnerable dependencies, and unsafe SQL queries. This practical developer checklist walks through the exact 10-minute security checks you should run before deployment.
SQL Injection in Spring Boot (2026): Real Vulnerabilities, Prevention & Testing
Learn how SQL injection still breaks Spring Boot apps in 2026 with real Java vulnerabilities, blind SQLi examples, prevention checklists, and practical testing payloads.
Related Developer Tools
Discover more fast, browser-based utilities in the Crypto Tools suite.
AES Encryption & Decryption
Perform ultra-secure AES encryption and decryption with custom modes (GCM, CBC, CTR, CFB, OFB, ECB), variable bit depths (128, 192, 256), PBKDF2 key derivation, 7-language code generators, and visual block inspectors.
SHA Hash Generator & Audit Workspace
Generate, verify, and analyze SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, and SHA-3 family hashes. Features HMAC signature generation, file checksum auditing, input entropy analysis, and instant comparison.
Recently Visited Tools
No recent tools visited yet. Explore tools above to build your quick-access history.