開発者向けJWTツール トークンを解読、エンコード、および有効期限を確認

すべてのバックエンド開発者が経験したことがある状況：コンソールに401 Unauthorizedが表示され、その場で戦いが始まる。トークンが期限切れになったのか？間違ったシークレットで署名されたのか？サービス間でパラメータが失われたのか？JWT（JSON Web Token）は現代の認証のつながりであり、それが壊れると、認証ゲートの後ろのすべてが暗くなる。

JWTが複雑であるという問題ではない。構造は実際にはシンプルで、3つのbase64urlエンコードされたセグメントがドットでつながっている——ヘッダー、ペイロード、署名。問題は、そのような原始的なトークンが解読されるまで何も教えてくれないということだ。 eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyXzEyMyIsInJvbGUiOiJhZG1pbiIsImV4cCI6MTc0NjA5NjAwMH0.mK2xVpQ8nZ3aF7tLdRhW6sYbcXeUoIPjNvGqTmAS1kE tells you nothing until you decode it. And decoding it — fast, in a browser, without installing anything — is exactly what these three free tools handle.

このガイドは、JWTの完全なワークフローを説明する：トークンを解読して中身を確認し、テストで認証を模倣するためのトークンを生成し、期限切れを確認してタイムアウトエラーを診断する。各セクションは上記の仮のトークンを使用しているため、端末まで一貫して追跡できる。

ツール1 — JWTデコーダー：トークンの内部を瞬時に確認

の JWTデコーダー any token and splits it into its three components, decoding the header and payload from base64url to readable JSON.

Paste the example token above and you’ll see the header decoded to:

{
  "alg": "HS256",
  "typ": "JWT"
}

And the payload:

{
  "sub": "user_123",
  "role": "admin",
  "exp": 1746096000
}

それは人々を混乱させます。2つの選択肢があります：キーワードまたは度数の角度です。 exp field is a Unix timestamp. At a glance it means nothing — but the decoder converts it to a human-readable date so you immediately know whether the token is still valid or already stale.

One thing to understand: the decoder does not verify the signature by default. Signature verification requires the secret (for HS256) or the public key (for RS256/ES256). What the decoder gives you is the decoded content — which is everything you need when you’re debugging a 401, checking what claims were included, or inspecting a token from a third-party identity provider.

Worth noting: the JWT payload is base64url encoded, not encrypted. Any tool (or person) with the token can read the payload without the secret. The signature only proves the token hasn’t been tampered with. That’s why you should never store sensitive data — passwords, credit card numbers, SSNs — inside a JWT payload.

ツール2 — JWTエンコーダー：テスト用のトークンを作成

の JWT encoder does the reverse: you supply a JSON payload, choose an algorithm (HS256 is the default), enter a secret, and the tool generates a signed token you can use immediately.

最も一般的な使用例は、テストで認証を模倣すること。統合テストが保護されたAPIエンドポイントにアクセスする必要がある場合、実際のログインフローを接続する代わりに、エンドポイントが期待する正確なクレームを持つトークンを作成する。

{
  "sub": "test_user_001",
  "role": "editor",
  "iat": 1746009600,
  "exp": 1746096000
}

Sign it with your test secret, drop the resulting token into your test headers, and your protected routes respond as if a real user authenticated. No mocking the auth middleware, no spinning up an identity provider — just a valid token with the claims you need.

エンコーダーは、新しいサービスを開発している際に、特定のクレーム組み合わせをテストする場合にも役立ちます。欠落したロール、期限切れのトークン、予期しないスコープなど、エッジケースのペイロードでトークンを生成し、ミドルウェアがどのように反応するかを確認できます。

If you need to understand the base64url encoding step itself — since the JWT payload is just encoded, not encrypted — the base64 decoder lets you decode either segment manually. Paste the middle portion of any token (the payload segment) into the base64 decoder and you’ll get the raw JSON back. Same approach, one step at a time.

ツール3 — JWT期限チェックツール：数学を使わずに401エラーを診断

Token expiry is responsible for a large share of auth failures in production. The JWT有効期限チェックツール takes any token and tells you immediately: is it expired? If so, by how much?

Paste the example token and the checker extracts the exp field, converts it from a Unix timestamp to a readable date, and compares it against the current time. You get a clear status: valid (with time remaining) or expired (with how long ago it expired).

This matters more than it sounds. When a 401 hits in production, the first question is always “is the token expired or is something else wrong?” Answering that question by mental arithmetic on a Unix timestamp — 1746096000 - current_time / 3600 — wastes time and introduces errors. The expiry checker answers it in one paste.

It also surfaces the iat (issued at) timestamp when present, so you can see exactly when the token was generated and how long the session has been active. Useful when debugging token refresh bugs or tracking down why a long-lived session suddenly failed.

まとめ：典型的なデバッグワークフロー

You get a 401. Here’s the fastest path from error to resolution:

1. Check expiry first. Paste the token into the 有効期限チェックツール. If it’s expired, the fix is a token refresh — no further debugging needed.
2. Inspect the payload. If the token is still valid, paste it into the JWTデコーダー. Check the claims: is the sub correct? Is the expected role または scope present? Is the audience (aud) right for the endpoint you’re hitting?
3. Reproduce with a custom token. If you suspect a specific claim combination is causing the rejection, build a token with the encoder and test directly. This isolates whether it’s the claim content or the token structure itself causing the failure.

Three tools, under a minute, no installs. Most JWT-related 401s resolve at step 1 or 2.

あなたも好きかもしれません

新しい

CORSを説明する： curlで動作するがブラウザではエラーになる理由

続きを読む "

更新日 2026年6月20日

新しい

WebSockets と SSE と長時間ポーリング — チャットアプリが溶ける前に正しいリアルタイムパターンを選んでください

続きを読む "

更新日 2026年6月19日

新しい

localStorage と sessionStorage と IndexedDB と Cookie — ブラウザストレージの3時までの後悔なし

続きを読む "

更新日 2026年6月18日

新しい

TypeScriptのユーティリティ型 — 適切に覚えておくべきもの（およびそれ以外）

続きを読む "

更新日 2026年6月17日