JWT Decoder

Decode and inspect the Header, Payload, and Signature of any JSON Web Token instantly.

JWT Token

Paste a JWT token above to inspect its contents.

What Is a JSON Web Token (JWT), and Why Do You Need a Decoder?

A JSON Web Token (JWT) is a compact, self-contained, open standard (RFC 7519) for securely transmitting claims between two parties. JWTs represent information using JSON objects, and their integrity is guaranteed through a digital signature or encryption (JWS/JWE).

A JWT is typically made up of three parts separated by periods (Header.Payload.Signature). The Header defines the token's type and the signing algorithm used (HS256, RS256, etc.). The Payload carries the actual data (claims) being transmitted, such as a user ID or permissions. Finally, the Signature proves the token hasn't been tampered with during transmission. Critically, a JWT is not encrypted — it's Base64Url-encoded. That means anyone holding the token can read the data inside it. DevTora's JWT Decoder is built to let developers quickly and easily inspect the user info, expiration time, and permissions embedded in a token. Because all processing happens entirely within your browser, you can debug sensitive authentication tokens safely, without any risk of them leaking to an external server.

How to Inspect and Debug a JSON Web Token

1
Get your token: Copy the full JWT string from an HTTP Authorization header or your browser's local storage.
2
Paste your token: Paste the copied string into the "Encoded Token" field. DevTora handles even very long token strings without issue.
3
Analyze the header: Check the signing algorithm (alg) and token type (typ) in the separated Header section.
4
Review the payload data: Use the Decoded Payload to review user attributes, the issuer (iss), the audience (aud), and any custom claims.
5
Check the expiration (exp): Locate the exp claim in the payload to determine whether the token is currently valid or has already expired.
6
Identify the signature structure: Confirm the presence of the signature (the third segment) to verify the token's integrity structure is correct.
7
Format for readability: Grasp complex, deeply nested data structures at a glance with a cleanly indented JSON view.
8
Manage sensitive information: Since anyone can decode a JWT payload, verify that no passwords or sensitive personal information are embedded in the token.
9
Get error message feedback: If a token's format is invalid or truncated, quickly identify the cause through the error panel.
10
Debug with security in mind: Use the individual copy buttons to safely transfer only the information you need into a local debugging log or documentation.

Advanced JWT Inspection Features for Engineers

Real-time token decomposition: Instantly and logically splits a token into its three parts — header, payload, and signature — as soon as you type.
High-quality JSON formatting: Transforms raw JSON data into an indented, structured layout for maximum readability.
100% client-side processing: Token data is never sent to a server — everything is processed locally in your browser, guaranteeing complete privacy.
Precise Base64Url decoding: Fully handles the JWT standard's special characters (-, _) and padding-removal rules.
Standard claim identification: Clearly labels key standard claims like sub, iss, iat, and exp for rapid auditing.
Real-time error feedback: Provides clear warning messages for malformed tokens or invalid Base64 sequences.
Responsive design: A mobile-optimized layout lets you debug authentication issues instantly on a smartphone or tablet.
One-click partial copy: Convenient dedicated buttons let you copy the decoded header and payload individually.
Dark mode support: Fully supports a premium dark mode interface for developers working long hours.
Zero-dependency security: Leverages native browser capabilities with no reliance on external libraries, delivering both speed and security.
Stateless operation: No data is ever stored on a server or logged — everything resets when you refresh the page.
RFC 7519 compliance: Strictly follows the official JSON Web Token specification to guarantee universal compatibility.

Security and Implementation Mistakes to Watch Out For with JWTs

Malformed Token Structure

A valid JWT must consist of exactly three parts separated by periods. Standard decoding isn't possible if this structure isn't followed.

Base64Url Padding Errors

JWTs omit the "=" padding used in standard Base64. Manually adding padding, or a token being truncated, can cause decoding to fail.

Exposing Sensitive Information

Since the payload isn't encrypted, embedding passwords or personally identifiable information (PII) is extremely risky from a security standpoint.

Expired Tokens (exp)

If a token's exp claim is earlier than the current time, the token has expired, and the server will return a 401 error.

Algorithm Tampering Attacks

If the "alg" value in the header doesn't match what the server expects, it can become a security threat. Always guard against algorithm substitution attacks.

Beware the "None" Algorithm

A token with its algorithm set to "none" can bypass signature verification entirely, so modern systems must reject it immediately.

In-Depth Questions and Answers About JWTs

1
Is it safe to decode my JWT online?
DevTora runs all decoding logic locally in your browser. Since the token you enter is never transmitted to a server, you can use it with confidence and no risk of a data leak.
2
What's the difference between HS256 and RS256?
HS256 is a symmetric algorithm that uses a single secret key for both signing and verification. RS256 is an asymmetric algorithm that signs with a private key and verifies with a public key. RS256 is generally more secure for distributed systems.
3
Can I modify the data inside a JWT and re-sign it?
Modifying the data is easy, but re-signing it afterward requires the same secret key used to issue the original token. Without that key, the modified token will be treated as invalid.
4
Is a JWT encrypted?
No — by default, a JWT (JWS) is only signed, not encrypted. The internal data is Base64Url-encoded and readable by anyone, so it should never contain sensitive information.
5
Why does JWT use Base64Url instead of standard Base64?
Base64Url replaces the + and / characters with - and _ so it can be used safely in URLs. It also omits the padding character (=) to reduce token length.
6
What information should never be put in a JWT?
Sensitive data like a user's password, national ID number, or credit card number must never be included. A JWT guarantees data integrity, not confidentiality.
7
How is JWT expiration handled?
Expiration is set via the exp claim in the payload. The server checks this timestamp and rejects invalid tokens, typically using a refresh token alongside it to renew the session.
8
What is a JWT "claim"?
A claim is a single piece of information carried in the token. There are standard claims like the issuer (iss), expiration (exp), and audience (aud), as well as custom claims defined by the user.
9
Does a larger payload affect performance?
Yes. Since a JWT is sent in the header with every single request, a larger payload increases network overhead. Keeping only the minimum necessary data is key to performance optimization.
10
Can a JWT be revoked immediately?
By design, a JWT is stateless and remains valid until it expires. If immediate revocation is required, the server needs to maintain a blacklist or use a separate storage mechanism.
11
Should I store a JWT in local storage or a cookie?
Local storage is convenient but vulnerable to XSS attacks. A cookie with the HttpOnly attribute is safe from XSS but requires additional CSRF protection.
12
What goes wrong if signature verification is skipped?
Without signature verification, an attacker could freely tamper with user permissions inside the payload (e.g., admin: true), leading to a serious security breach.
13
What does "kid" in the header mean?
It stands for Key ID, used to identify which key was used to sign a token in an environment with multiple keys. It's especially useful during key rotation.
14
Is there a size limit for a JWT?
The technical specification doesn't impose a limit, but in practice, you may hit browser or server HTTP header size limits (typically 8KB–16KB). Exceeding this range can cause requests to be rejected.
15
Why does the signature show as "Invalid"?
This happens when the token's content was tampered with during transmission, or when the wrong secret key was used for verification. A broken token format will also cause signature verification to fail.
16
Can I send feedback about this tool?
Yes! DevTora is a continuously evolving platform. If you have a bug report or a feature suggestion, please reach out anytime at support@devtora.org.