JWTデコード
JWT Decoder reads the header and payload of a JSON Web Token in your browser and explains what it found: the signing algorithm, every claim with its meaning, and expiry decoded into a real date. It never verifies the signature, because that would require sending your token to whoever holds the key.
このツールの画面は英語表記です。
以下の解説は英語のみでご覧いただけます。
How does JWT Decoder work?
A JSON Web Token is three base64url-encoded segments joined by dots: header.payload.signature. The first two are JSON objects, and they are not encrypted — base64url is an encoding, not a cipher. Anyone holding the token can read every claim in it, which is why putting a password, a card number or an internal database ID into a JWT payload is a mistake people make regularly and discover late.
Decoding is therefore straightforward: split on the dots, base64url-decode the first two segments, parse each as JSON. The care goes into the details that break naive decoders. JWT segments are unpadded base64url (RFC 7515 §2), so a decoder that insists on = padding rejects most real tokens. The alphabet uses - and _ rather than + and /, so a standard Base64 decoder fails on roughly half of all tokens depending on what the random bytes happened to encode.
What this tool adds beyond decoding is interpretation. Registered claims from RFC 7519 are annotated with what they mean. exp, nbf and iat are NumericDates — seconds since the Unix epoch — so they are rendered as a real timestamp and a relative time, because “1757546000” is not something you can act on and “expired 4 hours ago” is.
Then it looks for the specific problems that cause incidents: an alg of none, an empty signature segment, a token with no exp, a token not yet valid because the issuer’s clock is ahead, a missing aud that allows the token to be replayed against a different service trusting the same issuer.
It deliberately stops short of verification. Checking a signature needs the issuer’s secret or public key, and the only way a web page gets one is by sending your token somewhere. Offering that would undo the single property that makes it safe to paste a live credential into this page.
Token segment
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 .eyJzdWIiOiJ1c3JfOGYyYTFiIiwiZXhwIjoxNzU3NTQ2MDAwfQ .3Zc0Kz1qHhVQ9oFmR2sT7xYbN4dJwEuLpAiCgXvKmO8
Decoded
header { "alg": "HS256", "typ": "JWT" }
payload { "sub": "usr_8f2a1b", "exp": 1757546000 }
exp 2026-09-10 21:53:20 UTC (expired)
sub Subject — who the token is aboutWhat options and edge cases does JWT Decoder support?
| Parameter | Type | Default | Behaviour & edge cases |
|---|---|---|---|
| alg | string | required | Signing algorithm, in the header. HS* is HMAC with a shared secret; RS*/PS* are RSA; ES* is ECDSA; EdDSA is Ed25519. A value of "none" is flagged as an error: a library that trusts alg from the token itself lets anyone forge one. |
| typ / kid | string | optional | typ is conventionally "JWT". kid identifies which key signed the token, and is what lets an issuer rotate keys without invalidating everything at once. |
| exp | NumericDate | optional | Seconds since the Unix epoch, not milliseconds and not an ISO string. Decoded here to a UTC timestamp and a relative time. A token with no exp never expires by itself and can only be stopped by revocation. |
| nbf | NumericDate | optional | Not-before. A token that is not valid yet is almost always clock skew between the issuing server and the machine reading it, rather than a deliberate delay. |
| aud | string | string[] | optional | Intended recipient. A service must reject a token whose audience is not itself; without aud, a token minted for one service can be replayed against another that trusts the same issuer. |
| Segment encoding | base64url | unpadded | RFC 7515 §2 uses the URL-safe alphabet (- and _) with padding removed. Standard Base64 decoders fail on tokens whose bytes produce + or /, which is why a token sometimes decodes in one tool and not another. |
| Signature | base64url | not verified | Shown but never checked. Verification requires the issuer's key; obtaining one would mean transmitting your token. An empty signature segment is flagged, since it means no integrity protection at all. |
| Input size | bytes | 8 MB | The main-thread ceiling shared across the site. Real tokens are a few kilobytes; the limit exists so pasting the wrong thing cannot lock the tab. |
Frequently asked questions
Is it safe to paste a real JWT into this page?
The decoding happens entirely in your browser and the token is never transmitted — open DevTools, switch to the Network panel, paste a token, and you will see no request carrying it. That makes this page categorically safer than a decoder that posts to a server, where your token lands in an access log. The remaining caveat is not about this site: any credential you paste into any browser on a machine you do not control should be rotated afterwards.
Why can't it verify the signature?
Because verification needs the key. For HS256 that is the shared secret; for RS256 it is the issuer's public key, usually fetched from a JWKS endpoint. A browser page could only do either by sending your token, or the secret, somewhere — which would destroy the property that makes this page safe to use. Verification belongs in your service, where the key already lives.
My token decodes here but my library rejects it. Why?
Decoding and accepting are different questions. The commonest causes are: the token has expired (check the exp row — this tool shows it as a real date); the audience does not match what your service expects; the nbf is in the future because the issuing server's clock is ahead; or the signature does not verify against the key your service is configured with, often because the issuer rotated keys and the kid now refers to one your cache has not picked up.
What does alg: none mean and why is it flagged as an error?
It means the token is unsigned. The danger is not the value itself but what a verifier does with it: some JWT libraries historically read alg from the token and selected the verification method accordingly, so an attacker could take a valid token, change the algorithm to none, strip the signature, and have it accepted. A correct verifier decides the expected algorithm from its own configuration and ignores what the token claims.
Is a JWT encrypted?
No. A standard JWT (a JWS) is signed, not encrypted — the signature proves the payload has not been altered, and does nothing to hide it. Every claim is readable by anyone holding the token, which is exactly what this page demonstrates. If you need the contents hidden you want a JWE, which has five segments rather than three and cannot be read without the decryption key.
Can I decode a token that has already expired?
Yes. Expiry is a claim inside the payload, not a property of the encoding, so an expired token decodes exactly like a live one. This tool reads it and tells you when it expired and how long ago, which is usually the fastest way to confirm that an intermittent 401 is a token-lifetime problem rather than a permissions one.