What is JWT Decoder?
A JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information. Our JWT Decoder allows developers to easily paste a token and instantly view the decoded Header (Algorithm and Token Type) and Payload (Data Claims) without sending the token over the network. This ensures sensitive session tokens or authorization headers are never logged by a third-party server.
Before you use this tool
Start with a small, representative example and check the result before you rely on it in a larger workflow. Keep the original data and look closely at the edge cases. The safest tool is the one whose limits you understand.
Deep Dive: JWT Decoder
Related Articles
Learn more about this tool and related topics in our blog.
Why Developers Prefer Offline File Tools in 2026
Privacy isn't a perk, it's a requirement. See why top developers are ditching cloud converters for local-first browser utilities.
How Browser-Based File Tools Work (WebAssembly Explained)
Peek under the hood of Filemint. A practical look at WebAssembly, Web Workers, and the browser APIs behind our private file tools.
How to Process Files Privately Without Uploading Them
Your files stay on your device. This guide explains how Filemint processes them in the browser instead of sending them to a server.
βThe single habit that prevents most JWT breaches is simple: never let the token decide how it gets verified. Pin the algorithm on the server, refuse none, and keep asymmetric verification keys public while the signing key stays locked away. Decoding is a fine first step for inspection, but trust must always come from verification with the right key.β
Azeem Mustafa
Privacy Architect
Core Capabilities
- Decoder with JWT/JWS/JWE format detection
- Token encoder with editable Header and Payload JSON
- HMAC verification for HS256, HS384, and HS512
- Claim timeline and security audit panel
- Issuer and audience expectation checks
- Automatic Base64URL normalization and parsing
- Recent token history and JSON export
- Local-only execution for privacy-sensitive debugging
Why It Matters
- Privacy: Securely inspect login tokens without cloud exposure.
- Learning: Understand the "three-part" structure of modern web auth.
- Speed: Instant feedback for debugging complex API issues.
- Security: Verify that you aren't accidentally leaking sensitive data in your payloads.
Quick Start Guide
Grab your token: Copy the long string starting with "eyJ" from your appβs console or network tab.
Inspect the content: The decoder will immediately show you the header, claims, and payload data in a clean format.
Check the timestamps: Review the expiration (exp) and issued-at (iat) dates to see if your token is still valid.
Run a security audit: Check for potential issues like algorithm mismatches or expired sessions in the findings panel.
Verify the signature: If you have the secret key, you can verify if the signature is authentic right there in the UI.
Usage Examples
A standard signed JWT split into three parts
Scenario 01Paste a token like this and the decoder shows the header and payload as JSON while leaving the signature as raw text. The structure is header.payload.signature.
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
HEADER
{
"alg": "HS256",
"typ": "JWT"
}
PAYLOAD
{
"sub": "1234567890",
"name": "John Doe",
"iat": 1516239022
}
SIGNATURE (raw, not validated)
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5cThe alg=none forgery attempt
Scenario 02An attacker edits the header to alg none, changes the role claim, and blanks the signature. A decoder still shows the contents, but a correct verifier rejects it because unsigned tokens must be refused.
eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJ1c2VyMSIsInJvbGUiOiJhZG1pbiJ9.
HEADER
{
"alg": "none",
"typ": "JWT"
}
PAYLOAD
{
"sub": "user1",
"role": "admin"
}
SIGNATURE (empty)
NOTE: decodable, but unsigned. A safe verifier rejects alg=none.A tampered payload with a stale signature
Scenario 03Someone changes the exp claim to push the expiry far out, but keeps the original signature. Decoding shows the new value; verification fails because the signature no longer matches the edited payload.
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyMSIsImV4cCI6MjE0NzQ4MzY0MH0.oldSignatureHere
HEADER
{
"alg": "HS256",
"typ": "JWT"
}
PAYLOAD
{
"sub": "user1",
"exp": 2147483640
}
SIGNATURE (raw)
oldSignatureHere
NOTE: payload edited, signature now invalid on verification.Timestamps rendered as dates
Scenario 04The iat and exp claims are raw epoch seconds. The decoder turns them into readable dates so you can see at a glance whether a token is current.
eyJhbGciOiJSUzI1NiJ9.eyJzdWIiOiJhYmMiLCJpYXQiOjE3MDY1NDgwMDAsImV4cCI6MTcwNjU1MTYwMH0.signature
PAYLOAD
{
"sub": "abc",
"iat": 1706548000 (2024-01-29 20:26:40 UTC),
"exp": 1706551600 (2024-01-29 21:26:40 UTC)
}Common Scenarios
API auth debugging
A request keeps returning 401 and you suspect the token expired or carries the wrong audience. Decode it to read exp and aud without touching the server.
Microservices inspection
Service A calls service B with a forwarded JWT. Decode at the boundary to confirm the claims being passed are what you expect.
Session inspection
You want to know what your own app stored in your session cookie. Decode the JWT to see the claims your backend issued.
Mobile app backend checks
A mobile client gets a token from an identity provider. Decode it to verify issuer and expiry before wiring it into the app.
Security audits
During a review, decode issued tokens to confirm no passwords or PII sit in the payload and that expiries are sane.
Learning the standard
New to JWTs? Decoding real tokens is the fastest way to understand header, payload, and signature.
Token troubleshooting
A token decodes but the server rejects it. Reading the header tells you the algorithm, which often points to a verification config mismatch.
SSO and OAuth flows
Decode the OpenID Connect id_token locally to confirm iss, aud, and nonce before trusting a login.
Questions?
Technical Architecture
Base64url anatomy
Each of the first two JWT segments is base64url(text). Base64url is base64 with two changes: the characters plus and slash become minus and underscore, and the equals sign padding is removed so the value is safe in URLs and headers. Decoding reverses this, then parses the result as JSON. The signature segment is binary signed bytes shown here as its encoded form; it is not JSON.
Signing algorithms
HS256 uses HMAC with SHA256 and a shared secret. RS256 uses RSA with SHA256 and a private key, verified by a public key. ES256 uses ECDSA with the P 256 curve. PS256 adds RSA PSS padding. EdDSA uses Edwards curve signing. The alg claim in the header names the method. RFC 7518 lists these. Asymmetric methods let verifiers use only a public key.
The none algorithm
RFC 7519 defines none as an unsecured JWT with no signature. It exists for cases where integrity is protected by other means. The danger is libraries that accept none from the token header instead of from server config. A safe verifier maintains an allowlist and refuses none. Decoders show the alg value but cannot tell you the server's policy.
Algorithm confusion
When a verifier chooses its algorithm from the token header, an attacker can switch RS256 to HS256 and sign with the public key as the HMAC secret. Because the public key is public, forging tokens becomes possible. The Token Time Bomb NDSS 2026 study found 31 such implementation flaws across 43 libraries in 10 languages, with 20 assigned CVEs. Pin the algorithm and bind keys to one method.
Local decode safety
Decoding is a read only transform. It needs no key and proves nothing about authenticity. Because this tool runs in your browser and sends nothing to a server, you can decode production tokens without the risk that a shared online debugger logs them. Verification, by contrast, needs the correct key and should happen server side.
Claims and expiry math
Time claims such as exp, nbf, and iat are Unix epoch seconds, not milliseconds. The decoder converts them to dates so a human can read them. A token is conceptually invalid after exp, but only a verifier enforces that. Decoding simply shows you the number and its date equivalent.
JWT libraries tested
across 10 languages (NDSS 2026)
implementation flaws found
all enabling auth bypass or DoS
CVEs assigned
Token Time Bomb study
CVSS of CVE-2023-29357
SharePoint JWT forge
How JSON Web Tokens Work
A JWT is a compact string with three parts separated by dots. When you decode it, each part is base64url decoded back into readable text. The shape is always the same:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTYiLCJyb2xlIjoiYWRtaW4ifQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
Header
A small JSON object that names the signing algorithm, HS256 or RS256, and marks the type as JWT. It tells the verifier how to check the signature.
{ "alg": "HS256", "typ": "JWT" }Payload
The claims. These are statements about the user, like their ID, role, and when the token expires. Decoding shows you this data in plain text, but it does not prove it is true.
{ "user": "123", "role": "admin" }Signature
A value created by signing the header and payload with a secret or a private key. The signature is what lets a server confirm the token was not changed after it was issued.
Important: the JWT payload is encoded, not encrypted.
Anyone who holds the token can read the payload. Decoding does not hide anything, which is exactly why you should never put passwords, private keys, or secrets inside it.
When you paste a token here, the tool splits it on the dots, base64url decodes each segment, and prints the header and payload as formatted JSON. Decoding is read only. It shows you the contents but it does not validate them, which is why a separate verification step still matters.
JWT Security Checklist
Decoding a token is a good first look, but safety depends on a few habits. Keep these in mind whenever you work with JWTs:
- βNever put passwords or raw secrets in the payload. The payload is only encoded, not encrypted, so anyone who gets the token can read it.
- βAvoid storing sensitive personal data in a token that travels through browsers and logs.
- βAlways verify the signature on the server before trusting any claim. Decoding alone proves nothing about authenticity.
- βCheck the expiration time (exp) and reject tokens that are past it. Decoding will show the date but will not reject an old token.
- βUse a strong, current algorithm and pin an allowlist on the server. Refuse alg=none and watch for algorithm confusion attacks.
Decode vs Verify JWT
This is the most common point of confusion with JWTs. Decoding turns the encoded token back into readable JSON. It does not prove anything about the token itself. Verification is the step that confirms the token came from a trusted issuer and was not changed.
Decoding only reveals the token contents. It does NOT prove:
- βThe token is authentic.
- βThe signature is valid.
- βThe issuer is trusted.
Verification requires the correct secret or public key and should happen on the server. Use this tool to read a token, then verify it where the key actually lives.
JWT Decoder vs JWT Validator
People search for both, and they are not the same tool. A decoder reads the contents. A validator checks the signature and issuer. Here is how they compare:
| Feature | Decoder | Validator |
|---|---|---|
| Read payload | Yes | Yes |
| Decode Base64URL | Yes | Yes |
| Verify signature | No (optional) | Yes |
| Requires secret or key | No | Yes |
FileMint is a decoder. When you need to confirm a token is genuine, verify it server side with the issuer's key.
Related Developer Tools
These tools pair well with the JWT decoder when you are inspecting tokens, hashes, and encoded data:
- Base64 Encoder & DecoderJWT uses Base64URL for its header and payload, so decode raw segments here.
- JSON FormatterJWT payloads are JSON, so pretty print and validate claims here.
- Hash GeneratorSignatures rely on cryptographic hashing, so produce the SHA values here.
- Developer Tools HubSee the full set of local, privacy-first developer tools.
How the common JWT attacks actually work
Most JWT bugs come from one mistake: letting the token tell the server how to verify itself. The header carries an alg claim, and if the verifier reads that claim instead of its own configuration, an attacker gets to pick the method. Two attacks stand out. The first is alg=none, where the signature is stripped and the server skips checking entirely. The second is algorithm confusion, where a token meant for RS256 is rewritten as HS256 and signed with the public key treated as a shared secret. Both let an attacker forge claims such as role admin. Decoding the token shows you the alg value, which is why a quick local decode is a good first move during a review. To go deeper, read the Intigriti JWT exploitation guide and the PortSwigger Web Security Academy JWT section.
Real world impact is not theoretical. CVE-2023-29357 is a critical, CVSS 9.8 flaw in Microsoft SharePoint Server where a spoofed JWT could bypass authentication and, chained with another bug, reach remote code execution. The NDSS 2026 Token Time Bomb study scanned 43 libraries across 10 languages and found 31 flaws, 20 of them assigned CVEs. These are good reasons to verify server side and to keep your decoding private.
Why decode locally instead of on a shared site
A JWT can carry a live session. Paste it into a public debugger and that token may be logged, cached, or tied to your network address. Decoding in your own browser means the token never travels, so there is nothing to intercept. This is the same privacy principle behind our other local tools. If you want to check raw encoding, the base64 converter shows the mechanics, and the hash generator demonstrates the SHA family used inside the signature. For a broader look at keeping data on device, see our client side processing privacy guide.
When you move from reading tokens to storing credentials, our password generator and password hash tool cover the key side of the story, and the MD5 vs SHA256 comparison explains why weak hashes have no place near a secret. For the standards themselves, start with RFC 7519 and the Auth0 JWT basics lab. The OWASP JWT cheat sheet and Vaadata JWT attacks writeup lay out the fixes step by step.
Learn more
Explore more developer tools
JWT decoding is one part of the local developer toolkit. Visit the Developer Tools hub for Base64, hashing, JSON formatting, and file verification tools that all run in your browser.
Keep Exploring
Power up your workflow with related utilities.
Related Tools
JSON Formatter
The definitive JSON workshop for developers. Transform minified payloads into readable structures, catch syntax errors in real-time, and prepare your data for production with zero cloud exposure.
Use free βBASE64 Converter
The "Safe House" for your data. Encode sensitive strings, create data URIs, and decode API payloads with high-fidelity UTF-8 support and zero cloud exposure.
Use free βHash Generator
The "Digital Fingerprint" factory. Create one-way cryptographic hashes using the Web Crypto API for maximum security, speed, and privacy without cloud exposure.
Use free βRelated Articles
Learn more about this tool and related topics in our blog.
Why Developers Prefer Offline File Tools in 2026
Privacy isn't a perk, it's a requirement. See why top developers are ditching cloud converters for local-first browser utilities.
How Browser-Based File Tools Work (WebAssembly Explained)
Peek under the hood of Filemint. A practical look at WebAssembly, Web Workers, and the browser APIs behind our private file tools.
How to Process Files Privately Without Uploading Them
Your files stay on your device. This guide explains how Filemint processes them in the browser instead of sending them to a server.
Founder & Lead Developer at FileMint
Building privacy-first browser tools powered by WebAssembly. Focused on making file processing fast, secure, and accessible β without ever uploading your data to a server.
View full profile β