¿Qué es Decodificador JWT?
JSON Web Tokens (JWTs) are a compact, URL-safe way of transmitting claims between parties as a JSON object. A JWT consists of three Base64URL-encoded sections separated by dots: the header (algorithm and token type), the payload (the claims — user ID, roles, expiration time), and the signature (verifying authenticity). Our JWT Decoder instantly decodes the header and payload sections so you can read the token's contents without writing any code.
JWTs are the most common authentication token format in modern web applications. OAuth 2.0 access tokens, OpenID Connect ID tokens, JSON API auth tokens, and custom session tokens are all typically JWTs. When debugging authentication issues, a developer needs to quickly inspect a token's claims: what user does it represent? When does it expire? What permissions does it grant? Our decoder makes this inspection instant.
Decoding a JWT does not verify its signature. The header and payload of any JWT can be decoded by anyone who has the token — they are Base64-encoded, not encrypted. The signature verification requires the secret key and proves the token was not tampered with. Our decoder shows the decoded content; your server must verify the signature separately.
Casos de uso
Aquí tienes las formas más comunes en que la gente usa Decodificador JWT todos los días.
Authentication Debugging
When a user cannot access a resource they should have access to, paste their JWT into the decoder to check: does the "sub" claim contain the correct user ID? Has the "exp" (expiration) timestamp passed? Does the token include the required role or scope? Does "aud" match your service? These questions are answered in seconds with the decoder rather than adding debug logging to your authentication middleware.
API Integration Development
When integrating with a third-party OAuth API, decode the access token to discover what claims it contains, verify the algorithm in the header, confirm the token is not expired, and extract user information directly from the payload without making an additional userinfo endpoint request.
Security Review
During a security audit, decode tokens to verify: the algorithm is not "none" (a critical vulnerability), the token contains only necessary claims (minimal data exposure), expiration times are reasonable, and sensitive data is not stored in the payload which is visible to anyone with the token.
Learning JWT Structure
The decoder makes JWT concepts concrete — paste a real token and see the three parts separated, the Base64URL decoding explained, the JSON payload readable, and Unix timestamps converted to human-readable dates. This hands-on inspection is far more effective than reading documentation.
Verifying Token Claims in Tests
When writing integration tests for authentication flows, decode generated tokens to assert they contain the expected claims: correct subject, appropriate expiration duration, required scopes, and correct issuer. This verifies your token generation logic produces tokens with the intended content rather than just checking they are non-empty strings.
Ejemplos
Inspect an Access Token
Decode a JWT to check user ID, expiration, and scopes.
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0IiwibmFtZSI6IkpvaG4ifQ.hash Header: {"alg":"HS256","typ":"JWT"} | Payload: {"sub":"1234","name":"John"} Decode an OpenID Connect ID Token
Inspect user profile claims in an OIDC ID token returned by Google, Auth0, or Okta to verify user data without a server call.
eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyMTIzIiwiZW1haWwiOiJ1c2VyQGV4YW1wbGUuY29tIiwibmFtZSI6IkpvaG4gRG9lIiwiZW1haWxfdmVyaWZpZWQiOnRydWV9.signature Payload: {"sub":"user123","email":"user@example.com","name":"John Doe","email_verified":true} Check Token Expiration and Timing Claims
Verify whether a token is still valid by inspecting its exp, iat, and nbf Unix timestamps converted to human-readable dates.
JWT payload {"sub":"42","iat":1700000000,"exp":1700003600,"nbf":1700000000} Issued: Nov 14 2023 22:13 UTC | Valid from: Nov 14 2023 22:13 UTC | Expires: Nov 14 2023 23:13 UTC | Status: EXPIRED Decodificador JWT frente a jwt.io
Our JWT decoder versus jwt.io — the most well-known JWT inspector.
| Característica | Toolorah | jwt.io |
|---|---|---|
| Decode header and payload | Yes | Yes |
| Signature verification | No — client-side only | Yes — with secret |
| Token sent to server | Never — fully client-side | Processed client-side but runs on jwt.io domain |
| Expiration badge | Yes — automatic | Manual timestamp reading |
| Unix timestamp to date conversion | Yes | Raw number shown |
| No external dependencies | Yes | Requires jwt.io to be available |
| Part of a broader toolkit | Yes — with Base64, Hash, URL tools | JWT-only |
Consejos para usar Decodificador JWT
- The "exp" claim is a Unix timestamp (seconds since 1970). The decoder converts it to a human-readable date automatically.
- "iat" (issued at) and "nbf" (not before) are also Unix timestamps — useful for understanding token timing.
- Never include passwords, SSNs, or credit card numbers in JWT payloads — the payload is visible to anyone with the token.
- Check the "alg" header claim — "none" algorithm JWTs have no signature and must always be rejected by your server.
- JWT uses Base64URL encoding (not standard Base64) — it replaces + with - and / with _ for URL safety.
Preguntas frecuentes
Is it safe to paste my JWT into an online tool?
Our decoder processes tokens entirely in your browser — the token is never sent to any server. However, for production tokens containing sensitive user data or administrative privileges, consider your organization's security policies. If a token grants access to sensitive operations, treat it like a password. For development and staging tokens used in debugging, a client-side decoder is perfectly appropriate. The key security property is that our tool never transmits your token anywhere.
Why can I read the JWT payload without the secret key?
JWT payload is Base64URL-encoded, not encrypted. Base64 is an encoding scheme that any software can reverse — it provides zero confidentiality. The secret key is only required to generate and verify the signature. This design is intentional: JWTs are readable by the token's recipient (so your frontend can extract user information like name and email) but not forgeable (the signature prevents creating fake tokens without the secret). Never put truly sensitive data — SSNs, payment data, API keys — in a JWT payload unless the token is encrypted (JWE format).
What do the standard JWT claims mean?
"sub" (subject): the entity the token represents, typically a user ID. "iss" (issuer): the service that created the token. "aud" (audience): the intended recipient service. "exp" (expiration): Unix timestamp after which the token should be rejected. "iat" (issued at): Unix timestamp when the token was created. "nbf" (not before): Unix timestamp before which the token should be rejected. "jti" (JWT ID): a unique token identifier used to prevent replay attacks and enable token revocation.
What is the difference between JWT, JWS, and JWE?
JWT (JSON Web Token) is the general three-part structure. JWS (JSON Web Signature) is the specific standard for signed JWTs — the most common type, where the payload is readable but the signature prevents tampering. JWE (JSON Web Encryption) is for encrypted JWTs — the payload is encrypted and unreadable without the key. In everyday usage, "JWT" almost always refers to JWS tokens. Our decoder works with JWS tokens and cannot decrypt JWE tokens.
How do I check if a JWT is expired?
Look at the "exp" claim in the payload — our decoder automatically converts the Unix timestamp to a human-readable date and shows a "Token expired" or "Token valid" badge based on the current time. Manually: the "exp" value is a Unix timestamp in seconds. Compare it to the current time (Date.now() / 1000 in JavaScript). If exp < current time, the token is expired. Note: always verify expiration on the server side, never rely solely on client-side checks.
Why does a JWT have three parts separated by dots?
The three-part structure serves specific purposes: the header provides the algorithm information needed to verify the signature; the payload carries the claims (the actual data); the signature ties the first two parts together cryptographically. The dots are delimiters separating the three Base64URL-encoded sections. This structure allows the header and payload to be read without the secret key, while the signature ensures the token has not been modified after creation.
Can I modify a JWT payload and use the modified token?
No. If you modify the payload, the signature will no longer match the modified header+payload combination. Any server that properly validates the JWT will reject it with a signature verification failure. This is the entire point of the signature — it cryptographically binds the payload to the secret key. An attacker cannot change "admin: false" to "admin: true" in a JWT payload without the secret key.