Air-Gapped JWT Decoder & Sandbox
Decode, format, and re-sign JSON Web Tokens entirely in your browser. Your sensitive payloads and API keys never leave your machine.
Related JSON Tools
100% Offline & Air-Gapped
This JWT Sandbox strictly operates inside your browser using the native Web Crypto API. Whether you are debugging authentication flows or testing payload tampering, your secret keys and token contents are never uploaded to any server. You can safely disconnect from the internet and continue using this tool.
How JWT Formatting & Parsing Works
A JSON Web Token (JWT) is composed of three parts separated by dots (.): the Header, the Payload, and the Signature.
- Header: Contains metadata about the type of token and the cryptographic algorithm used (e.g., HMAC SHA256 or RSA).
- Payload: Contains the claims or statements about an entity (typically, the user) and additional data. Note: The payload is merely Base64Url encoded, not encrypted, making it readable by anyone unless using JWE (JSON Web Encryption).
- Signature: Used to verify that the sender of the JWT is who it says it is and to ensure that the message wasn't changed along the way.
This tool acts as a powerful JWT parser that decodes the Base64Url parts to reveal the raw JSON formatting. By entering your server's secret key, you can cryptographically verify if the signature is valid. Developers also use this tool as a sandbox to debug authentication flows or test payload tampering by altering the payload data and letting the browser re-sign it automatically.
Standard JWT Claims Explained
When you decode a JWT, the payload often contains standard registered claims. Understanding these is crucial for securely debugging authentication flows:
The primary identifier for the user or entity the token represents (e.g., a user ID).
Identifies the principal that issued the JWT, often your auth server's URL.
A Unix timestamp indicating when the token expires and must be rejected.
A Unix timestamp indicating exactly when the token was created.
The token is not valid until this Unix timestamp has passed.
Identifies the recipients that the JWT is intended for (e.g., your API).
Frequently Asked Questions
Is it safe to paste my production JWTs here?
Yes. This application relies entirely on JavaScript executed locally in your browser. We have zero server-side components processing your tokens, ensuring your sensitive credentials never leave your machine.
Why does the payload say "Invalid Signature" when I change a value?
A JWT's signature is generated from the exact contents of the header and payload combined with the secret key. If you modify any character in the payload JSON, the resulting signature changes. Without the correct secret key, the new signature won't match, causing validation to fail. This is the primary security mechanism of JWTs preventing tampering.
Why You Must Never Store Passwords in a JWT
Premise: Because a JWT looks like scrambled gibberish, many junior developers mistakenly believe the payload is encrypted and safe to store sensitive data like passwords or social security numbers.
Evidence: A JWT is merely Base64Url encoded, not encrypted. As you can see by using our tool above, anyone who intercepts the token can instantly decode it and read the exact JSON payload. The signature only prevents the data from being altered, it does not hide it.
Conclusion: Never put sensitive information inside a JWT payload. Only include necessary, non-sensitive claims like User IDs or Role permissions.
Developer Snippet: How to Decode a JWT in Vanilla JavaScript
If you need to decode the payload of a JWT on the frontend without relying on heavy external libraries, you can use the browser's native atob() function:
function parseJwt(token) {
try {
const base64Url = token.split('.')[1];
const base64 = base64Url.replace(/-/g, '+').replace(/_/g, '/');
const jsonPayload = decodeURIComponent(atob(base64).split('').map(function(c) {
return '%' + ('00' + c.charCodeAt(0).toString(16)).slice(-2);
}).join(''));
return JSON.parse(jsonPayload);
} catch (error) {
return null;
}
}