What is a JWT Token?
A JSON Web Token (JWT) is a compact, URL-safe way to represent claims between two parties. It is defined in RFC 7519 and is the most widely used format for authentication tokens in modern web applications and APIs.
When you log into an application, the server typically generates a JWT and sends it back to your client. Your client then includes this token in the header of every subsequent request to prove its identity. The server can verify the token without needing to query a database on every request, which is what makes JWTs efficient at scale.
JWTs are widely used in single sign-on (SSO) systems, OAuth 2.0 flows, and REST API authentication. Frameworks like Auth0, Firebase Auth, AWS Cognito, and Supabase all issue JWTs by default.
How a JWT is Structured
Every JWT consists of three parts separated by dots, each encoded in Base64URL format.
.
Payload
Claims about the user or session. Includes standard claims like sub, exp, iat.
.
Signature
HMAC or RSA signature. Proves the token has not been tampered with.
The header and payload are not encrypted — they are only Base64URL encoded. Anyone can decode and read them, which is why you should never put sensitive data like passwords or credit card numbers in a JWT payload. The signature prevents tampering but does not provide confidentiality.
If you need an encrypted JWT, you are looking for JWE (JSON Web Encryption), which is a different format where the payload is actually encrypted.
Standard JWT Claims Reference
| Claim | Full name | Description |
|---|
| sub | Subject | The principal about whom the token makes claims. Usually a user ID. |
| iss | Issuer | The service or authority that issued the token (e.g., your auth server URL). |
| aud | Audience | The intended recipients of the token. Servers should reject tokens not addressed to them. |
| exp | Expiration time | Unix timestamp after which the token must be rejected. Critical for security. |
| iat | Issued at | Unix timestamp of when the token was created. Used to determine token age. |
| nbf | Not before | Unix timestamp before which the token must not be accepted. |
| jti | JWT ID | Unique identifier for the token. Useful for preventing replay attacks. |
| name | Full name | OIDC claim for the user's full name. |
| email | Email address | OIDC claim for the user's email address. |
| roles | Roles | Custom claim for authorization roles. Not standardized but widely used. |
How to Use This Tool
Step 1 — Paste your token. Copy a JWT from your browser's local storage, an API response, or your application logs and paste it into the input box. The decoder updates in real time as you type.
Step 2 — Read the decoded parts. The header column shows the algorithm and token type. The payload column shows all claims. The signature column shows the raw signature bytes — note that this tool cannot verify the signature because verification requires your secret key.
Step 3 — Check the status bar. At a glance you can see whether the token is structurally valid, whether it is expired, and when it was issued.
Step 4 — Inspect standard claims. The claims panel below the decoder highlights recognized standard claims with human-readable timestamps and explanations.
Step 5 — Copy what you need. Copy the header or payload as formatted JSON for debugging, or copy the full token string to use elsewhere.
Security Warning
This decoder runs entirely in your browser. Your token is never sent to any server. However, you should still avoid pasting real production tokens from live systems into any online tool, including this one. The risk is not this site — it is browser extensions, clipboard managers, or other software running on your machine that may capture what you paste.
Best practice when debugging JWT issues is to either use a token from a development or staging environment, or to invalidate the token immediately after inspection if you must use a production token.
Frequently Asked Questions
What is a JWT decoder?
A JWT decoder parses a JSON Web Token and displays its three parts in human-readable format: the header (algorithm and type), the payload (claims and data), and the signature. It lets developers inspect token contents for debugging without needing server-side tooling.
Is it safe to paste my JWT into an online decoder?
This decoder processes your token entirely in JavaScript in your browser. Nothing is sent to a server. That said, for production tokens containing real user sessions, best practice is to use test tokens or invalidate the token immediately after inspection. Browser extensions on your machine could theoretically read clipboard data.
What is the difference between decoding and verifying a JWT?
Decoding means reading the header and payload. Anyone can do this because the data is Base64URL encoded, not encrypted. Verification means confirming the signature is valid using the signing key, which proves the token was not tampered with and was issued by a trusted party. This tool can decode but not verify — verification requires your secret or public key.
Why is my token showing as expired?
JWTs contain an exp claim (expiration time) which is a Unix timestamp. When the current time exceeds that timestamp, the token is expired. Your application should be requesting a new token via a refresh token flow or re-authentication. Expired tokens should always be rejected by your server.
What does HS256 vs RS256 mean in the header?
These are signing algorithms. HS256 (HMAC-SHA256) uses a shared secret key — both the issuer and verifier know the same key. RS256 (RSA-SHA256) uses a private/public key pair — the issuer signs with the private key and verifiers use the public key. RS256 is preferred in multi-service architectures because it does not require sharing a secret.
Can I use this to decode JWTs in C# or .NET?
This tool is for visual inspection in the browser. In .NET, use the System.IdentityModel.Tokens.Jwt package (JwtSecurityTokenHandler) or Microsoft.AspNetCore.Authentication.JwtBearer for validation. For just decoding without verification, you can Base64URL decode the header and payload segments manually.