Paste a JSON Web Token to instantly view its decoded header and payload claims — entirely in your browser.
No, this tool only decodes and displays the header and payload — it doesn't verify the signature, which requires the secret or public key used to sign the token.
Decoding happens entirely in your browser and the token is never sent to a server, but as a general precaution avoid pasting tokens with highly sensitive production data into any tool.
JWTs are Base64-URL encoded, not encrypted — this is by design, since JWTs are meant to be readable but tamper-evident via their signature, not confidential.
"exp" stands for expiration time, a standard JWT claim storing a Unix timestamp indicating when the token should no longer be considered valid, used by receiving systems to reject expired tokens.
This usually means the pasted text isn't a valid JWT — check that it has exactly three dot-separated parts, and that nothing was accidentally truncated or altered when copying it.
Yes, this is a common use case during development — decoding a token your own backend issued to visually confirm the expected claims are present and correctly formatted before shipping.
This tool decodes a JSON Web Token (JWT) and displays its header and payload as readable JSON, entirely in your browser. It's useful for debugging authentication issues, inspecting token claims, and understanding what data a JWT actually contains.
A JWT consists of three parts separated by dots: a header, a payload, and a signature. The header typically specifies the signing algorithm and token type. The payload contains the actual claims — data like user ID, expiration time, and any custom fields the issuer included. The signature is a cryptographic hash that lets the receiving system verify the token hasn't been tampered with, provided they have the correct secret or public key.
A common misconception is that JWTs are encrypted. They're not — the header and payload are simply Base64-URL encoded, which is a reversible text encoding, not encryption. Anyone who has a JWT can decode its header and payload instantly, exactly as this tool demonstrates. This is by design: JWTs are meant to be tamper-evident (via the signature) rather than confidential. Sensitive data that shouldn't be readable by anyone holding the token should never be placed in a JWT payload.
JWTs show up throughout modern web and mobile applications, most commonly as authentication tokens issued after a successful login, carried along with subsequent requests to prove the user's identity without requiring them to log in again on every single request. They're also used in OAuth and single sign-on flows, API access tokens for third-party integrations, and in some cases for securely passing structured data between services that both trust the same signing key. Recognizing the general shape of a JWT — three dot-separated Base64 segments — is a useful skill for anyone working with modern web APIs, since encountering one in a request header or API response is extremely common across contemporary backend systems.
While a JWT's payload can contain any custom data an issuer chooses to include, several standard claim names appear across most implementations. "sub" (subject) typically identifies the user the token represents. "iat" (issued at) records when the token was created. "exp" (expiration) specifies when the token should stop being accepted. "iss" (issuer) identifies which system generated the token. "aud" (audience) specifies which system the token is intended for. Recognizing these standard claim names makes it much faster to understand an unfamiliar token's structure at a glance, since they follow a consistent convention across most JWT implementations rather than being specific to any one system.
Verifying a JWT's signature requires the same secret key (for HMAC algorithms like HS256) or the corresponding public key (for RSA/ECDSA algorithms like RS256) that was used to sign it — information that only the issuing server should have. Since this tool has no access to that secret, and receiving it would defeat the purpose of keeping it secret, this tool intentionally only decodes and displays the token's contents without claiming to verify its authenticity.
All decoding happens directly in your browser using JavaScript's built-in Base64 decoding — your token is never sent to a server, logged, or stored anywhere.
While this tool never transmits anything you paste, it's still good general practice to avoid pasting tokens from live production systems containing real user sessions into any third-party tool, including this one, simply as a matter of habit. For development and debugging, generating a test token with dummy claims, or using a token from a local development environment, achieves the same inspection goal without involving any data tied to a real user or live system.
JWTs gained widespread adoption largely because they're self-contained and stateless — a server can verify a token's validity using just the signature and the secret key, without needing to look up a session record in a database for every single request. This makes JWTs particularly well suited to distributed systems and microservice architectures, where multiple independent services need to verify a user's identity without all querying a shared central session store. The tradeoff is that a JWT's claims, once issued, can't easily be revoked before expiration without additional infrastructure, which is a consideration worth understanding alongside the convenience this tool helps you inspect and debug.