JWT Decoder
Decode JSON Web Tokens to inspect headers and payloads.
What is a JSON Web Token (JWT) and Why Use a Decoder?
A JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.
A JWT typically consists of three parts separated by dots (.): the Header, the Payload, and the Signature. The Header defines the algorithm used for signing (like HS256 or RS256). The Payload contains the "claims" or the actual data being transmitted (such as user IDs or permissions). Finally, the Signature ensures that the token hasn't been tampered with. Because JWTs are Base64Url encoded, they are not encrypted by default; anyone who can see the token can see the data inside. This is why a JWT Decoder is essential during development: it allows engineers to quickly inspect the contents of a token to verify the correct user information, expiration dates, and authorization roles are being transmitted. ProUtil’s JWT Decoder provides a secure, client-side environment to perform this inspection without any risk of sensitive token data ever leaving your machine.
How to Inspect and Debug JSON Web Tokens
Secure Your Token: Copy the full JWT string from your Authorization header or browser storage.
Token Input: Paste the encoded string into the "Encoded Token" field. Our UI is optimized for long, encrypted-looking strings.
Instant Header Analysis: Look at the Header section to identify the signing algorithm (e.g., HS256 or RS256) and the token type.
Payload Inspection: Review the Decoded Payload. This is where you can verify user attributes, issuer (iss), audience (aud), and custom claims.
Check Expiration (exp): Locate the "exp" claim in the payload to determine if the token is still valid or has expired.
Signature Verification Logic: While this is a decoder, identifying the signature part (the third segment) helps you verify the token's integrity structure.
Format for Readability: Use the formatted JSON view to make complex nested claims easy to read and audit.
Sanitize Sensitive Data: Never place passwords or sensitive secrets in the JWT payload, as it is easily decoded by tools like this.
Identify Token Errors: If the token is truncated or malformed, our tool will provide immediate feedback in the error panel.
Privacy-First Debugging: Use the "Copy" buttons to move specific parts of the decoded data to your local documentation or debugging logs safely.
Advanced JWT Inspection Features for Engineers
JWT Decoding Example
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoyMDI2fQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
{
"sub": "1234567890",
"name": "John Doe",
"iat": 2026
}Understanding JWT Security & Implementation Errors
Malformed Token Format
A valid JWT must have exactly two dots (.) separating three parts. If it doesn't, it's not a standard JWT.
Base64Url Padding Errors
JWTs omit the "=" padding. If you add it manually or if the token is truncated, the decoding process will fail.
Sensitive Data Leakage
Placing PII (Personally Identifiable Information) or secrets in the payload is a major security risk, as payloads are only encoded, not encrypted.
Expiration Claims (exp)
Always check the expiration date. An expired token will lead to "401 Unauthorized" errors in your application.
Algorithm Confusion
Ensure the "alg" header matches your server's expected algorithm to prevent algorithm substitution attacks.
None Algorithm Vulnerability
Be wary of tokens where the algorithm is set to "none". Modern systems should reject these outright.
Expert Insights: Frequently Asked Questions About JWT
Q.Is it safe to decode my JWT online?
With ProUtil, yes. Our JWT Decoder works entirely within your browser using client-side JavaScript. Your token is never transmitted to our servers or any third party, ensuring your authentication secrets remain private.
Q.What is the difference between HS256 and RS256?
HS256 (HMAC with SHA-256) is a symmetric algorithm, meaning the same secret key is used to both sign and verify the token. RS256 (RSA Signature with SHA-256) is an asymmetric algorithm, using a private key for signing and a public key for verification, which is generally more secure for distributed systems.
Q.Can I change the data in a JWT and re-sign it?
You can decode and change the payload, but if you do, the Signature will become invalid. To re-sign it, you would need the original secret key or private key used by the issuer. This prevents unauthorized tampering.
Q.Are JWTs encrypted?
By default, no. Standard JWS (JSON Web Signature) tokens are only Base64Url encoded and signed. Anyone can decode the payload. If you need to hide the data, you must use JWE (JSON Web Encryption).
Q.Why is the JWT payload Base64Url encoded instead of just Base64?
Base64Url encoding replaces characters like `+` and `/` with `-` and `_` and removes padding (`=`). This makes the token safe to use in URLs and filenames without requiring additional encoding.
Q.What should never be stored in a JWT?
Never store sensitive information such as passwords, credit card numbers, or social security numbers in a JWT payload. Since the payload is only encoded, anyone with the token can read its contents.
Q.How do I handle JWT expiration?
The `exp` claim in the payload specifies the expiration time. Your application should check this claim and reject any token where the current time is greater than the expiration time. Using "Refresh Tokens" is the standard way to handle session renewal.
Q.What is a "claim" in a JWT?
A claim is a piece of information asserted about a subject. Standard claims include `sub` (subject), `iss` (issuer), `aud` (audience), and `exp` (expiration). You can also add custom claims specific to your application.
Q.Does a larger JWT payload affect performance?
Yes. Since JWTs are sent with every HTTP request (usually in the Authorization header), large payloads increase network overhead. Keep your tokens compact by only including essential data.
Q.Can a JWT be revoked?
JWTs are stateless, meaning they are valid until they expire. Revoking them before expiration requires a "blacklist" or "revocation list" on the server side, which slightly undermines the stateless benefit.
Q.Should I store JWTs in LocalStorage or Cookies?
LocalStorage is easier to use but vulnerable to XSS. HttpOnly, Secure cookies are more resistant to XSS but can be vulnerable to CSRF. The best choice depends on your specific security architecture.
Q.What happens if I forget to verify the JWT signature?
If you don't verify the signature, an attacker can create a fake token with malicious claims (like `admin: true`) and your system will trust it. Signature verification is the most critical step in JWT security.
Q.What is the "kid" header in a JWT?
The `kid` (Key ID) header is used to signal which key was used to sign the token. This is especially helpful during key rotation or when using a set of multiple public keys (JWKS).
Q.Is there a limit to JWT size?
While there is no technical limit in the spec, most servers and browsers have limits on header sizes (often around 8KB or 16KB). If your JWT exceeds this, requests will fail.
Q.Why is my signature showing as "Invalid"?
A signature can be invalid if the token was tampered with, if you are using the wrong secret/public key for verification, or if the token was malformed during transmission.
Q.Is ProUtil's JWT Decoder open source?
Yes! ProUtil is a collection of open-source developer utilities. You can inspect our code on GitHub to verify our privacy-first claims.