JWT decoding happens in your browser — no token data is ever sent to a server.
Skip to JWT decoderA JWT (JSON Web Token) is three Base64url-encoded parts separated by dots: header (algorithm and type), payload (claims such as sub, exp, iat), and signature. Decoding is not encryption—anyone with the token can read the payload.
This tool decodes and inspects tokens in your browser, highlights exp/iat timing, and can sign test tokens with HS256/HS384/HS512 for development. Always verify signatures on your server before trusting claims in production.
Decode for debugging; verify signatures server-side with the real secret or public key.
Common real-world scenarios where this tool saves time.
Inspect access tokens returned by OAuth or custom login endpoints without writing a script.
Confirm exp, aud, and iss values before wiring middleware in your API.
Use Encode mode with HS256 and sample claims to test protected routes locally.
Step-by-step chains that connect related tools for common tasks.
| Action | What it does | Safe to trust claims? |
|---|---|---|
| Decode only | Reads header and payload | No—anyone can decode |
| Verify HMAC (HS256/384/512) | Checks signature with shared secret | Yes, if secret is correct |
| Verify RSA (RS256) | Needs public key | Not in this browser tool—use server |
| alg | Type | Typical use |
|---|---|---|
| HS256 | HMAC + SHA-256 | Monoliths, dev tokens, internal APIs |
| RS256 | RSA signature | OAuth providers, public-key verify |
| ES256 | ECDSA | Modern identity platforms |
Anyone with a JWT can read its payload — decoding proves nothing about authenticity. Use HMAC verification in this tool for dev tokens, or verify RS256/ES256 on your server with the issuer's public key before trusting claims in production.
Use staging keys or throwaway dev secrets only. Production HMAC secrets and private signing keys belong in your backend secret manager (AWS Secrets Manager, Vault, Doppler) — not a web form, even on a local-only tool.
Most auth failures during development are expired access tokens. This tool shows a live countdown to expiry and flags expired exp claims immediately. Refresh the token via your OAuth refresh flow or re-login before debugging API logic.
A token minted for api.example.com must not be accepted by billing.example.com. Confirm aud matches your service identifier and iss matches the identity provider you expect (Auth0, Cognito, Firebase, custom IdP). Mismatches are a common source of silent auth bypass bugs.
The nbf (not-before) claim blocks early use — useful for scheduled token rollout. If nbf is slightly in the future, wait or check server clock sync (NTP). Allow a small leeway (30–60 seconds) in backend validators to handle minor skew between issuers and consumers.
Access tokens decoded here often carry 15–60 minute exp values. Long-lived JWTs increase blast radius if leaked. Pair short access tokens with refresh-token rotation stored server-side or in httpOnly cookies — never put refresh tokens in localStorage.
HS256/384/512 share one secret between signer and verifier — fine for monoliths and dev. RS256/ES256 use asymmetric keys: only the private key signs; verifiers need the public key from JWKS. Never accept alg:none or allow algorithm downgrade in production middleware.
JWTs are header.payload.signature — three dot-separated Base64url parts. Pasting only the middle segment decodes claims but skips signature format checks. From DevTools: Network → request → Headers → copy the value after Bearer .
Generate HS256 test tokens here to hit protected routes in Postman or curl during development. For real issuance, use your auth service or JWT Generator with proper aud, iss, jti, and key rotation — not hand-built JSON in a browser tab.
Expiration alone cannot invalidate a stolen token before it expires. Issue jti (JWT ID) claims and maintain a server-side denylist for logout and compromise response. Decoding shows jti here; your API must check it against the blocklist on every request.
This tool verifies HMAC (HS256/384/512) only. Asymmetric JWTs must be validated server-side with the issuer's public key or JWKS — use your framework's JWT middleware instead.
A full JWT has three parts with claim timing and signature checks. For raw Base64 strings (not JWTs), use Base64 Encoder/Decoder.
Encode mode is for local dev smoke tests. Use JWT Generator or your auth service with proper key rotation and audience scoping for real issuance.
After decoding, paste the payload JSON into JSON Validator to check syntax and structure against your expected shape.
Use Timestamp Converter to convert exp/iat values to local time zones or compare multiple epochs side by side.
Browser verification is a dev convenience. Audit and compliance require server-side signature validation, key management logs, and revocation checks.
Likely cause: Pasted only the payload segment, or the string includes quotes, JSON wrapping, or line breaks.
Fix: Copy the full token from the Authorization header (after Bearer ) or the access_token field. It should look like xxxxx.yyyyy.zzzzz with no spaces.
Likely cause: Wrong algorithm (HS384 token verified with HS256 secret), truncated token, or secret has trailing newline/whitespace from .env files.
Fix: Confirm header alg matches your secret type. Trim the secret. Re-copy the token without line wraps.
Likely cause: Asymmetric algorithms need the issuer's public key or JWKS URL, not an HMAC secret.
Fix: Decode here to inspect claims. Verify on your API with the provider's JWKS (e.g. Auth0, Cognito, Firebase).
Likely cause: Server clock skew, revoked token (jti blocklist), or aud/iss mismatch — decode alone cannot detect revocation.
Fix: Compare server time with iat/exp. Check API logs for aud/iss validation errors. Rotate the token and retry.
Paste the full header.payload.signature string or a Bearer token from an API response or DevTools.
Check alg in the header and claims in the payload—especially exp (expiration) and sub (subject).
The tool flags expired tokens, future nbf (not-before), and missing recommended claims.
Enter a dev-only HMAC secret to test signature match in Encode mode or trusted backend verification in production.
A JWT is three dot-separated Base64url sections: header, payload, and signature. To decode: split on '.', take the second section, add padding if needed, and Base64url-decode it to get the JSON payload. This tool does that automatically and displays the decoded header and payload in a readable format.
Yes for HMAC algorithms (HS256, HS384, HS512)—the server and client share the same secret key and the browser can recompute the signature using the Web Crypto API. Asymmetric algorithms (RS256, ES256, PS256) require the server's public key, which this tool does not currently support.
At minimum: exp (expiration, Unix timestamp) to prevent indefinite use, and sub (subject, usually the user ID) for identification. iss (issuer) and aud (audience) are recommended for multi-service architectures to prevent token reuse across services. iat (issued at) helps compute token age and detect replay.
For development and debugging JWTs, yes—this tool runs entirely in your browser and the token is not sent anywhere. Avoid pasting production JWTs that carry sensitive user data or elevated privileges into any online tool as a security hygiene practice.
Decoding reads the header and payload without checking the signature—any Base64url decoder can do it. Verification checks that the signature was produced by a trusted party holding the correct secret or private key. Always verify the signature server-side before trusting any claims in a JWT.
Paste a JWT or Bearer token and inspect header, payload, timing claims, and warnings instantly in your browser.
Yes. Use Encode mode with HS256/HS384/HS512 signing through browser Web Crypto.
Decode alone is inspection-only. Enter an HMAC secret in the Verify section to check HS256/384/512 signatures in your browser. RS256 and ES256 require the issuer's public key — verify those on your server.
Yes. Processing is local in your browser and tokens are not uploaded.
Yes for HMAC-signed tokens (HS256, HS384, HS512) — enter the shared secret and the tool recomputes the signature with Web Crypto and compares it to the token. RS256, ES256, and PS256 need the issuer's public key; decode those here to read claims, then verify on your backend or via JWKS.
HS256 uses HMAC-SHA256 with a shared secret — both the token creator and verifier need the same secret key. This is simpler but requires all verifiers to know the secret. RS256 uses RSA asymmetric signing — the private key signs, the public key verifies. This allows anyone to verify tokens without access to the private signing key, making it suitable for public identity providers (Google, Auth0, AWS Cognito). ES256 uses ECDSA (smaller keys than RSA, equivalent security).
The exp claim contains the expiration time as a Unix timestamp (seconds since Jan 1, 1970 UTC). Compare it to the current time: if current_time > exp, the token is expired. This tool automatically highlights expired tokens and shows how long ago they expired or how long until they expire. In code: const isExpired = Date.now() / 1000 > payload.exp.
Registered claims (RFC 7519): iss (issuer — who created it), sub (subject — who it represents, usually user ID), aud (audience — intended recipient service), exp (expiration), nbf (not before — earliest valid time), iat (issued at — creation time), jti (unique token ID for revocation). Public claims add application-specific data (email, roles, permissions). Private claims are agreed upon between parties. The only mandatory claim is a valid base64url JSON structure — the rest are application-dependent.
For development tokens used in testing environments, yes — this tool runs entirely in your browser and the token is not sent to any server. For production JWTs carrying real user sessions or elevated privileges: avoid pasting them into any online tool as a general security hygiene practice, even browser-based ones. If you must inspect a production token, use your browser's DevTools console: atob(token.split('.')[1]) decodes the payload locally without using any external tool.
JWT Decoder — Decode & Inspect JSON Web Tokens (/jwt-decoder) runs in your browser when supported—inputs are not uploaded to EverydayTools servers.
Decoding follows RFC 7519 Base64url rules; HMAC signing uses Web Crypto consistent with common libraries.
For planning and development only. Production auth must verify tokens server-side with proper key management.
Part of Developer Tools
More free tools for the same workflow.
Encode text to Base64 or decode Base64 strings free in your browser. UTF-8, URL-safe mode, live convert, file upload—no signup.
Generate MD5, SHA-1, SHA-256, SHA-384, and SHA-512 digests from text or files in your browser. Verify download checksums—nothing is uploaded.
Advertisement
Reviewed by EverydayTools Editorial Team on 2026-05-20.