Step-by-Step Instructions
Copy the JWT string
A JWT is three base64url parts separated by dots. Copy that string from the Authorization header, storage, or the callback URL.
Paste it into the decoder
The header and payload are decoded in the page. The token is not uploaded. The site still loads ordinary assets.
Read the header and claims
The header shows alg. The payload shows claims such as sub, iss, and exp. The payload is encoded, not encrypted.
Check exp and, for HS256, a secret
exp is compared with the current time and labelled Expired or Valid. A typed secret can check an HS256 signature. RS256 is not checked.
Anatomy of a JSON Web Token (RFC 7519 Specification)
A JSON Web Token (JWT) is an open standard (RFC 7519) for securely transmitting information between client and server as a JSON object. A valid JWT string consists of three distinct parts separated by dots (`.`):
1. Header: Specifies token metadata, including the signing algorithm used (e.g., `{"alg": "HS256", "typ": "JWT"}`).
2. Payload: Contains claims about an entity (typically the user) and additional session data (e.g., `{"sub": "1234567890", "name": "Jane Doe", "admin": true, "exp": 1774483200}`).
3. Signature: A cryptographic hash created by taking the Base64URL-encoded header, Base64URL-encoded payload, and signing them with a secret key or private key.
Why Base64URL Encoding Is NOT Encryption
A common misconception among developer beginners is assuming that JWT tokens encrypt user payload data. They do not.
Base64URL encoding is a reversible representation format that converts binary data into URL-safe ASCII characters. Anyone who intercepts a JWT string can decode its contents in seconds using standard browser APIs (`atob`). Never store sensitive information such as plain text passwords, credit card numbers, or social security details inside unencrypted JWT payloads.
Common JWT Vulnerabilities: Algorithm Confusion & None Attacks
Security flaws in JWT implementations often arise from improper signature verification logic on backend authentication servers:
• The "alg": "none" Exploit: Early JWT parsing libraries allowed tokens to bypass verification if an attacker set the header `"alg": "none"`. Modern JWT verification middleware must explicitly require a valid algorithm whitelist.
• Algorithm Confusion Attack (RS256 vs. HS256): If a backend expects an asymmetric RS256 signature (which verifies using a public key) but accepts an HS256 token signed with the server public key as a symmetric HMAC secret, an attacker can forge valid admin tokens.
Where to Store Tokens: HttpOnly Cookies vs. LocalStorage
Storing JWT session tokens in browser `localStorage` or `sessionStorage` leaves them vulnerable to Cross-Site Scripting (XSS) attacks. If an attacker injects a malicious script, they can read `localStorage.getItem("token")` and exfiltrate credentials.
The recommended production architecture is storing authentication JWTs inside `SameSite=Strict`, `HttpOnly`, `Secure` HTTP cookies, which prevents JavaScript code from accessing token storage.
Open JWT Decoder
Run this guide with the linked tool. Pages labelled local processing keep the file or text in the browser.
Frequently Asked Questions
Can I decode a JWT token if I do not know the secret key?
Yes. The header and payload are only Base64URL text. Checking or changing the signature requires the key.
What is the `exp` claim in a JWT payload?
The `exp` (expiration time) claim identifies the Unix epoch timestamp after which the token must not be accepted for authentication processing.
What is the difference between HS256 and RS256?
HS256 is a symmetric algorithm using a single shared secret key for signing and verifying tokens. RS256 is an asymmetric algorithm using a private key to sign tokens and a public key to verify signatures.
Is my secret key transmitted over the internet when using Toolioz JWT Decoder?
No. Parsing and an HS256 check run in the browser. The secret is not sent on the network.