What does a JWT decoder actually solve?
A JWT decoder turns the visible parts of a token back into readable JSON so you can inspect authentication data without manually splitting Base64URL segments. It is most useful when a login, API call, environment switch, or permission check fails and you need to see what the token claims, not when you need to prove the token is trustworthy.
Tool boundary
This page is scoped to decoding and inspection. It does not ask for a secret or public key, does not verify the signature, and does not generate or re-sign JWTs.
A JWT is three Base64URL segments, not an encrypted blob
A common signed JWT is written as `header.payload.signature`. The header and payload are normally JSON encoded with Base64URL, which uses URL-safe characters and may omit padding. Anyone holding the token can decode those two JSON objects, so payload readability is expected and should not be confused with authorization.
- Header: describes metadata such as token type and the intended signing algorithm.
- Payload: carries claims about the subject, issuer, audience, time limits, scopes, or business-specific facts.
- Signature: protects the encoded header and payload, but it is meaningful only after verification with the correct key material.
Registered claims you should recognize
| Claim | Meaning | Debugging question |
|---|---|---|
| iss | Issuer | Was this token issued by the expected authority? |
| sub | Subject | Is the token describing the user or entity you expected? |
| aud | Audience | Is this token intended for the API that received it? |
| exp / nbf | Expiration and not-before time | Is the token currently within its valid time window? |
| iat / jti | Issued time and token identifier | Does the age or identifier match the expected session behavior? |
このツールの使い方
- Paste the complete three-part JWT so the workspace can decode both the header and the payload claims.
- Inspect the algorithm, issuer, audience, and exp or nbf timestamps before deciding what you need to verify next.
- Use the decoded view for inspection only, then verify the signature and required claims in the real authentication system.
A practical reading order for decoded JWTs
Read a decoded JWT in a stable order so you separate formatting issues from real authentication failures. First confirm that the token has the expected segment count, then inspect the algorithm and type, then read the claims that control issuer, audience, time, subject, and scope.
- Check `typ` and `alg` in the header before reasoning about the payload.
- Translate time claims into the timezone used by the system logs you are comparing against.
- Treat decoded custom claims as evidence to inspect, not as permission to grant access.
JWT デコーダー の例
この例は、JWT デコーダー が想定している入力の形と、自分の作業に使う前に確認しておきたい結果の見え方を示しています。
入力例
eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjMifQ.signature
期待される出力
{
"alg": "HS256"
}
{
"sub": "123"
}Decoded header and payload example
Header:
{ "alg": "HS256", "typ": "JWT" }
Payload:
{
"sub": "toolkit-user",
"name": "ToolKit Online",
"iat": 1700000000
}
Signature:
present, but not verified by this decoderSafe decoding-only pseudocode
parts = token.split(".")
if parts.length < 2:
rejectAsMalformed()
header = parseJson(base64UrlDecode(parts[0]))
payload = parseJson(base64UrlDecode(parts[1]))
signatureSegment = parts[2] || ""
show(header, payload, signatureSegment)
warn("decoded output is not signature verification")Where a JWT decoder is most useful
A decoder is a visibility tool for authentication and authorization debugging. It gives developers, support engineers, and API owners a common way to discuss what the token says before they inspect server-side signature verification, key configuration, or authorization rules.
- Confirm whether a frontend is sending a staging token to production or the reverse.
- Compare `aud`, `iss`, and scope claims when one API accepts a token and another rejects it.
- Check whether `exp`, `nbf`, or clock skew explains a sudden login or refresh failure.
よくある使い方
JWT デコーダー は、ブラウザを離れずに短く反復的な作業をすばやく片づけたい場面向けに設計されています。
- ドキュメント、チケット、リリースノートを書きながら小さな値を素早く確認する。
- チームメンバーや顧客へ共有する前に、コピーした内容を整える。
- 表計算、IDE、デスクトップアプリを開かず、同じ変換を繰り返す。
What the Decoder Helps You Check
The decoder is most useful during authentication debugging, environment verification, and claim inspection. It narrows the problem quickly, but final trust decisions still belong to the live auth stack.
- Use the decoded payload to inspect claim presence, not to bypass server-side verification rules.
- Review `exp`, `nbf`, `iss`, `aud`, and algorithm metadata together when investigating auth failures.
- Remember that Base64URL formatting details can differ slightly from standard Base64 assumptions.
Decoding is not verification
This is the single most important boundary. A decoder can reveal claims, but it cannot tell you whether the token was issued by a trusted signer, whether the signature is valid, or whether the token should still be accepted by the real authentication system.
- Always review `exp`, `nbf`, `iss`, `aud`, and any domain-specific claims in their real validation context.
- Treat copied production tokens carefully because payload data may contain account or session details.
Algorithms are header context, not a local trust result
Values such as `HS256`, `RS256`, or `ES256` tell you what algorithm the token says was used. A real verifier must still enforce an allowed algorithm list, select the correct secret or public key, reject unexpected `alg` values such as unsecured tokens, and validate required claims after signature verification.
- Do not accept an algorithm just because it appears in the token header.
- Do not put passwords, secrets, private keys, or sensitive customer data in the payload because decoded payloads are readable.
- Use short lifetimes, HTTPS transport, key rotation, and server-side revocation or refresh-token design where the real product requires them.
JWT inspection actions compared
| Action | What it answers | Available on this page? |
|---|---|---|
| Decode | What do the header and payload say? | Yes |
| Verify | Does the signature match the expected key and claims? | No |
| Generate or re-sign | Can I create a new token with selected claims? | No |
| Introspect | Does the authorization server currently consider this token active? | No |
JWT compared with nearby token styles
| Style | What the client carries | Operational consequence |
|---|---|---|
| JWT | Structured claims plus signature segment | Easy to inspect locally, but still needs real verification |
| Opaque session ID | A random identifier | Requires server lookup to learn state |
| API key | A long-lived credential string | Usually not self-describing and should be treated as secret |
実用上の注意
- JWT デコーダー は既定でブラウザ内で動作するため、別のツールチェーンを用意せずにすばやくローカル確認を行えます。
- 実際の入力が大きい、機密性が高い、または業務上重要な場合は、まず代表的なサンプルから始めてください。
- 本番環境、顧客向け、法務、財務、安全性が重要な作業に使う前に、最終結果を必ず確認してください。
JWT デコーダー の参考情報
JWT デコーダー では、JWT の header、payload、signature、有効期限、デコードと検証の違いを説明します。
- JWT は通常、header、payload、signature という 3 つの Base64URL 部分で構成されます。
- header と payload は URL セーフな Base64 アルファベットでエンコードされた JSON で、signature は `header.payload` の ASCII 形式に対して計算されます。
- 署名アルゴリズムは HS256 のような対称方式、または RS256/ES256 のような非対称方式がありますが、デコードだけでは信頼性を証明できません。
- 実際の認証システムでは、exp、nbf、iss、aud と署名検証を確認してください。
参考資料
FAQ
JWT デコーダー の用途と、入力・出力・結果に関するよくある疑問をまとめています。署名を検証せずに JWT の header と payload をローカル解析します。
Is decoding in JWT デコーダー the same as verifying a JWT?
No. Decoding only makes the header and payload readable. Verification requires the correct secret or public key plus claim checks such as `exp`, `nbf`, `iss`, and `aud`.
Why can anyone read the payload shown by JWT デコーダー?
Because JWT header and payload are usually just Base64URL-encoded JSON, not encrypted content. Readability is not proof of trust.
Should I paste live production tokens into JWT デコーダー?
Use caution with real tokens. Prefer short-lived samples or redacted test values when the token carries sensitive claims, customer identifiers, or operational access.
Which claims should I review first in JWT デコーダー?
Start with `alg`, `iss`, `aud`, `exp`, and `nbf`, then inspect any subject, scope, or custom claims that influence authorization or routing.
What kind of JWT strings containing Base64URL header, payload, and signature parts is JWT デコーダー best suited for?
JWT デコーダー is built to decode JWT header and payload claims locally. It is most useful when JWT strings containing Base64URL header, payload, and signature parts must become readable JSON for the token header and payload for login debugging, API authorization checks, environment mismatches, permission claims, and support investigations.
What should I review in the readable JSON for the token header and payload before I reuse it?
Review three-part token shape, Base64URL decoding, exp and nbf times, issuer, audience, and the fact that decoding is not signature verification first. Those details are the fastest way to tell whether the result is actually ready for downstream reuse.
Where does the readable JSON for the token header and payload from JWT デコーダー usually go next?
A typical next step is login debugging, API authorization checks, environment mismatches, permission claims, and support investigations. The output is written to be reused there directly instead of acting like a generic placeholder.
When should I stop and manually double-check the result from JWT デコーダー?
Do not trust a decoded JWT unless the real authentication system also verifies the signature and required claims.