JWT Decoder

What Is a JWT Decoder?

A JWT Decoder is a browser-based tool that splits a JSON Web Token into its three component parts, header, payload, and signature, and renders each section as readable JSON. It lets you inspect the claims embedded inside a token instantly, without writing a single line of code.

JSON Web Token (JWT) is an open standard defined by RFC 7519, published by the Internet Engineering Task Force. A JWT is a compact, URL-safe string that encodes a set of claims, assertions about a user or system, in a format that can be cryptographically verified. Every JWT consists of three Base64URL-encoded segments separated by full stops. The first segment is the JOSE header, which declares the token type and the signing algorithm in use (for example, HS256 or RS256). The second segment is the claims set, the JSON payload containing fields such as the subject (sub), issuer (iss), expiry time (exp), and any custom application data. The third segment is the digital signature, which allows any party holding the correct secret or public key to verify that the header and payload have not been tampered with since the token was issued.

Because the header and payload are merely Base64URL-encoded rather than encrypted, they can be decoded by anyone who has the raw token string. This is by design. The security guarantee of a JWT lies in its signature, not in obscuring its contents. Platforms such as Auth0, Firebase Authentication, AWS Cognito, and Okta all issue JWTs as access tokens, identity tokens, or refresh tokens, and developers regularly need to inspect those tokens during integration work, debugging sessions, and security reviews. A JWT Decoder makes that inspection immediate and visual.

The tool on this page operates entirely in your browser. Your token is never transmitted to a server, which means production tokens containing user IDs, role claims, or email addresses remain private.

How to Use the JWT Decoder

1. Obtain your JWT. Copy the raw token string from wherever it appears: an HTTP response header (Authorization: Bearer ...), a browser's developer tools Network tab, an access_token field in a JSON response body, a cookie, or a local storage entry. A JWT always starts with the characters eyJ and contains exactly two full stops.
2. Paste the token into the input field on this tool. You can paste the entire token including the Bearer prefix if present; the tool strips that prefix automatically before parsing.
3. Click "Decode". The tool splits the string at each full stop, Base64URL-decodes each segment, and renders the header and payload as formatted, colour-coded JSON in separate panels.
4. Read the header panel to see the algorithm (alg) and token type (typ). If you see "alg": "none", treat that token as a potential security issue and investigate immediately, as this indicates no signature verification is in effect.
5. Read the payload panel to inspect the claims. Pay particular attention to exp (expiry, expressed as a Unix timestamp), iat (issued-at), sub (subject, typically a user ID), iss (issuer), and any custom role or scope claims your application defines.
6. Check the expiry timestamp. The tool converts the exp Unix timestamp into a human-readable date and time so you can see immediately whether the token has expired.
7. Note the signature segment. The tool displays the raw Base64URL-encoded signature string. It does not verify the signature, because that requires your server-side secret or public key. Verification must always happen server-side before trusting any claim.

Why Use This Tool

Any developer who integrates an authentication provider or builds an API that consumes JWTs will eventually need to decode a token manually. The alternative is to write a quick script in Node.js or Python to split and decode the string, which takes time and clutters your working environment. A browser-based decoder removes that friction entirely.

Front-end engineers use it to confirm that the access token stored in a React or Vue.js application carries the correct user roles before making an authorised API call. Back-end engineers use it to reproduce a reported bug by inspecting the exact claims present in the token a user submitted. Security engineers use it during penetration testing to review whether sensitive data, internal user IDs, email addresses, or system role names, is being exposed unnecessarily in token payloads. DevOps teams use it to check token expiry when debugging authentication failures in staging environments.

According to the JWT.io introduction, maintained by Auth0, JWTs are used in two primary scenarios: authorisation, where a token grants access to routes, services, and resources after a user signs in, and information exchange, where parties can verify that the sender is who they claim to be and that the content has not been altered. Both scenarios require developers to be able to inspect token contents quickly and reliably. This tool provides that capability without any setup, dependency installation, or configuration.

Beyond individual developers, QA engineers verifying that a login flow produces correctly scoped tokens, technical writers documenting an API's authentication scheme, and support engineers diagnosing a customer's access problem can all use this decoder without needing to write code.

Real-World Use Cases

Debugging an expired session in a React application

A front-end developer at a SaaS company notices that users are being logged out unexpectedly after 15 minutes, even though the product specification calls for a 24-hour session. She copies the access token from the browser's local storage, pastes it into the JWT Decoder, and immediately sees that the exp claim is set 900 seconds after the iat claim. She confirms the bug is in the token-generation code on the server, not in the client-side session management logic, and raises a precise bug report with the exact claim values included.

Verifying role claims during API integration

A back-end engineer integrating Stripe's Identity product with his company's internal access-control system needs to confirm that the JWT issued after verification carries the role: "verified_user" claim his middleware expects. Rather than adding temporary logging to the production codebase, he captures a sample token from the staging environment, decodes it in the browser, and sees the claims object in seconds. The integration goes live the same afternoon.

Security review of a third-party API token

A security consultant conducting a review of a fintech company's API discovers that the JWTs issued by the authentication service contain the user's full name, date of birth, and national insurance number in the payload claims. Because those fields are only Base64URL-encoded and not encrypted, any party who intercepts the token can read them without any key. She uses the JWT Decoder to demonstrate the exposure in her report, decoding a sample token from the test environment to show the client exactly which fields need to be removed or encrypted before the product launches.

Onboarding onto an unfamiliar authentication system

A new team member joining a fintech startup is asked to extend an existing Express.js API that uses AWS Cognito for authentication. The documentation is sparse. She captures a token from the staging environment using the browser Network tab, pastes it into the decoder, and sees the full claim structure including the Cognito user pool ID, the token use (access versus id), and the custom attribute fields the team has defined. Within ten minutes she understands the token structure well enough to write the middleware correctly.

Common Mistakes and Troubleshooting

Pasting only part of the token

A JWT must contain exactly two full stop characters, dividing it into three segments. If you copy the token from a log or a response body and accidentally truncate the string, the decoder will report a parse error. Ensure you have the complete token by checking that your pasted string contains two full stops and starts with eyJ. If the token is spread across a line break in your log viewer, remove the line break before pasting.

Including or excluding the Bearer prefix

Tokens in HTTP headers are typically formatted as Bearer eyJhbGci.... If your decoder does not strip the Bearer prefix automatically, remove it manually before pasting. This is one of the most common reasons a first paste fails to decode correctly.

Confusing decoding with verification

Decoding a JWT reads its contents. Verifying a JWT confirms that the signature is valid and the token has not been tampered with. A decoder cannot verify the signature because it does not have access to your signing secret or public key. Never make authorisation decisions based solely on the decoded payload of a token you received over the network. Always verify the signature server-side first.

Misreading the expiry timestamp

The exp and iat fields in a JWT payload are Unix timestamps, the number of seconds elapsed since 1 January 1970 UTC. A value of 1717200000 does not mean the token expires in the year 17 billion. Use the human-readable timestamp display provided by the decoder, or convert the value using a Unix timestamp converter if you need to check it manually.

Assuming the payload is encrypted

The payload of a standard JWT (JWS, JSON Web Signature) is encoded, not encrypted. Any party with the raw token string can decode and read the claims. If you need the payload to be confidential, you must use JWE (JSON Web Encryption), a different standard. Never store passwords, payment card numbers, or private keys in a standard JWT payload.

Using an alg: none token in production

If the decoded header shows "alg": "none", the token carries no signature and cannot be cryptographically verified. Some early JWT vulnerabilities involved tricking servers into accepting unsigned tokens. If you encounter this in production tokens from your own system, treat it as a critical security defect and investigate the token-issuance code immediately.