JWT Decoder
Decode JWT header and payload claims instantly. Inspect expiration, audience, scopes, and custom claims — all in your browser, no data transmitted.
Decoding is not verifying. This is the single most important thing to understand about JWTs. Anyone can decode a JWT — paste it here, and you will see the header, payload, and claims instantly. But only the holder of the signing key can verify that the token is authentic and has not been tampered with. A token with a fake signature decodes just as easily as a real one.
This tool decodes the three JWT segments — header (algorithm and token type), payload (claims about the user and permissions), and signature (raw Base64URL bytes). It extracts standard claims (exp, iat, nbf, aud, iss, sub, scope, jti) into a readable table, converts timestamp claims to human-readable dates, and shows the token's expiration status. Use it with demo tokens for learning and debugging.
Every operation runs entirely in your browser. Your JWT string is never transmitted by this tool. However, never paste a production bearer token into any online tool — a bearer token grants access to an account or API, and browser extensions, clipboard managers, or accidental copy-paste can expose it. Use sanitized demo tokens for testing.
Try it now
Paste a demo JWT and decode instantly
Decoding is not verifying. Use demo tokens for testing.
Server-side verification checklist
JWT structure — header.payload.signature
Every JWT is three Base64URL-encoded segments joined by dots. The first two are JSON; the third is binary.
Contains the token type (JWT) and the signing algorithm (HS256, RS256, ES256, etc.). Always Base64URL-encoded JSON.
{"alg":"HS256","typ":"JWT"}Contains the claims — statements about the user, token, and permissions. Standard claims include sub, exp, iat, aud, iss, scope, and jti.
{"sub":"demo@example.com","exp":1770000000}Cryptographic signature over the header and payload. Generated by the issuer using the secret key or private key. Anyone can decode; only the key holder can create a valid signature.
HMACSHA256(header.payload, key)
Common JWT mistakes (and how to fix them)
Understanding these seven pitfalls will save you hours of debugging — and prevent security vulnerabilities.
Why it breaks
Decoding a JWT in a browser tool reveals the claims, but it does not confirm the token is authentic. An attacker can craft a token with any claims and a fake signature — and it will still decode just fine. Only signature verification proves authenticity.
How to fix
Always verify the signature in your backend or API gateway before trusting the claims. Use the issuer's public key (RS256/ES256) or shared secret (HS256) to cryptographically validate the token.
Why it breaks
A token with an exp (expiration) timestamp in the past should be rejected. Continuing to accept expired tokens means a stolen token remains valid indefinitely — a serious security risk.
How to fix
Check exp on every request. Convert it from a Unix timestamp (seconds). Reject tokens where the current time exceeds exp, with a small clock-skew tolerance (typically 30–60 seconds).
Why it breaks
The aud (audience) claim specifies who the token is for. Accepting a token intended for a different service or API allows cross-service token reuse, which can lead to privilege escalation.
How to fix
Always validate that aud contains your API's identifier. Multi-audience tokens use an array — check that your identifier is one of the values.
Why it breaks
Pasting a real production JWT into any online tool exposes it to browser extensions, clipboard managers, and potentially the tool itself. A bearer token grants access — it is functionally a password.
How to fix
Use sanitized demo tokens for testing. For production debugging, use a local CLI tool like jq, jwt-cli, or your backend's JWT library. Never send production tokens to third-party services.
Why it breaks
JWT uses Base64URL (not standard Base64). Characters like + and / are replaced with - and _, and = padding is stripped. A standard Base64 decoder will fail or produce corrupted output for JWT segments.
How to fix
Use a Base64URL-aware decoder (like this tool). If you must use a standard decoder, replace - with + and _ with /, then add = padding to reach a multiple of 4 characters.
Why it breaks
The alg:none header tells the verifier to skip signature validation. Vulnerable JWT libraries may accept alg:none tokens, letting an attacker forge tokens with arbitrary claims and no signature at all.
How to fix
Explicitly whitelist the algorithms your application accepts (e.g., only RS256). Reject tokens with alg:none or any unexpected algorithm. Most modern JWT libraries have safe defaults — but verify your version.
Why it breaks
JWT exp, iat, and nbf claims are numeric Unix timestamps in UTC seconds. Converting them with a local-time assumption can make tokens appear expired or valid when they are not. A five-hour offset looks like a broken token.
How to fix
Convert JWT timestamps using UTC. Use the Timestamp Converter tool on this site to quickly check exp/iat/nbf values in both UTC and local time.
Understanding JWT decoding
Decode vs. verify: the most important distinction
Decoding and verifying are completely different operations. Understanding this distinction is essential for using JWTs securely:
Decoding
- Base64URL-decodes each segment.
- Parses the JSON in the header and payload.
- Anyone can do it — no key required.
- This is what browser tools do.
Verifying
- Cryptographically validates the signature.
- Requires the secret (HS256) or public key (RS256/ES256).
- Confirms the token was issued by a trusted authority.
- Must be done in your backend or API gateway.
Standard JWT claims reference
These are the registered claim names defined by RFC 7519. Every JWT library recognizes them:
| Claim | Name | Type | What to check |
|---|---|---|---|
exp | Expiration Time | NumericDate (seconds) | Reject if current time ≥ exp. Allow 30–60s clock skew. |
iat | Issued At | NumericDate (seconds) | Informational — when the token was created. |
nbf | Not Before | NumericDate (seconds) | Reject if current time < nbf. Token is not yet valid. |
aud | Audience | String or array of strings | Must contain your API’s identifier. |
iss | Issuer | String (URL) | Must match your expected authorization server URL. |
sub | Subject | String | The user or principal this token represents. |
Real-world use cases
Debugging authentication failures
When a user reports a 401 Unauthorized error, paste their (sanitized) JWT here to check: Is the exp claim in the past? Is the aud claim wrong? Are required scopes missing? These checks often resolve auth issues without touching backend code.
Comparing tokens across environments
Development, staging, and production identity providers may issue tokens with different claims, audiences, or expiration policies. Decode tokens from each environment side by side to spot configuration mismatches.
Verifying OAuth/OIDC token scopes
OpenID Connect and OAuth 2.0 tokens carry scope claims that define permissions. Decode the token to confirm the expected scopes are present before investigating why a specific API call was denied.
Checking token expiration in support tickets
When a user sends a screenshot of an error mentioning JWT expiration, decode the token to extract the exp value and confirm whether the token genuinely expired or if a clock-skew or time-zone issue is at play.
Learning JWT structure
If you are new to JWTs, paste a demo token here and see the header, payload, and signature side by side. Understanding the three-part structure and common claims will help you read tokens in logs, browser DevTools, and API documentation.
Validating custom claims in microservices
When your auth service adds custom claims (tenant ID, role, feature flags), decode the token to verify those claims have the expected values before the token reaches downstream services that depend on them.
When to verify server-side instead of decoding in a browser
- Production authentication: Every production API endpoint that accepts JWTs must verify the signature server-side. Browser decoding is for debugging and learning only — never for access control decisions.
- Sensitive claims: Claims containing user IDs, email addresses, roles, permissions, or PII should not be pasted into browser tools. Use your backend's JWT library to inspect production tokens.
- Token lifecycle management: Issuing, refreshing, revoking, and rotating tokens requires server-side logic with access to your signing keys and token store. Browser tools play no role in this flow.
- Compliance environments: In regulated industries (finance, healthcare, government), pasting tokens into external tools may violate data handling policies. Use internal, audited tooling.
Security and privacy
JWT decoding runs entirely in your browser. Your token is never uploaded to any server by this tool. However, never paste a production bearer token into any online tool— a bearer token is effectively a password. Anyone with it can impersonate the user. Browser extensions, clipboard managers, screen readers, and device-level software can all access textarea content. For production debugging, use a CLI tool like jqor your backend's JWT library with logging disabled. The demo tokens on this page are all fake — they have no valid signature and grant no access.
Frequently asked questions
Does decoding verify a JWT signature?
No. Decoding only reads the header and payload — it does not validate the signature. Anyone can decode a JWT; the signature exists so the receiver can cryptographically verify that the token was issued by a trusted authority and has not been tampered with. Always verify signatures in your backend or API gateway before trusting claims.
What is the difference between Base64 and Base64URL?
JWT segments use Base64URL encoding, which replaces + with -, / with _, and strips trailing = padding. This makes JWTs safe to include in URLs, HTTP headers, and query parameters without additional escaping. Standard Base64 decoders will fail on JWT segments — use a Base64URL-aware decoder like this one.
Why does my token show as expired?
The exp (expiration) claim is a Unix timestamp in seconds. If the current time is past that value, the token is expired. Common causes: (1) the token genuinely expired — request a new one; (2) your system clock is wrong — check NTP sync; (3) the exp value is in milliseconds instead of seconds — divide by 1000; (4) time zone confusion — exp is always UTC-based.
Can I edit a JWT after decoding it?
You can edit the decoded JSON, but the original signature will no longer match. A JWT signature covers the encoded header and payload — any change invalidates it. To create a valid token with modified claims, you need the signing key and must re-sign it with the issuer's secret or private key.
Is it safe to paste a JWT into an online decoder?
Never paste production bearer tokens into any online tool. A bearer token grants access to an account or API — it is effectively a password. Use sanitized demo tokens for testing. If you need to inspect a production token for debugging, use a local CLI tool (jq, jwt-cli) or your backend's JWT library with logging disabled.
What does the 'alg' field in the header mean?
The alg claim specifies the algorithm used to sign the token: HS256 (HMAC with SHA-256, symmetric), RS256 (RSA with SHA-256, asymmetric), ES256 (ECDSA with SHA-256), or others. In production, always validate that the algorithm matches what you expect — accepting 'none' or an attacker-controlled algorithm is a well-known JWT vulnerability.
What standard claims should I check during debugging?
The most important claims: exp (expiration — reject if past), nbf (not before — reject if future), aud (audience — reject if your API is not listed), iss (issuer — reject if unexpected), sub (subject — the user or client), scope (permissions), and jti (token ID for replay detection). Custom claims carry application-specific data and should also be verified.
Related tools you might need
Convert exp, iat, nbf timestamps to human-readable dates in UTC and local time.
Encode or decode Base64 and Base64URL strings — the encoding used by JWT segments.
Format and validate the JSON payload after decoding JWT claims.
Generate HMAC, SHA-256, and other hashes to understand JWT signing algorithms.
Tool guide
About JWT Decoder
JWTs contain Base64URL-encoded header and payload sections. A decoder helps you inspect claims such as issuer, subject, audience, issued-at time, not-before time, expiration time, scope, and custom application fields during debugging.
Decoding a JWT does not verify its signature. Treat decoded claims as untrusted unless the token has been verified by your application, API gateway, identity provider, or backend service.
Be careful with real production tokens. A bearer token can grant access to an account or API, so use sanitized samples whenever possible.
Privacy note
Most FreeToolsBox tools run directly in your browser for processing. Some pages may still load analytics, ads, or third-party services. Avoid entering passwords, private keys, production tokens, personal IDs, or other sensitive data.
Validation-grade guide
How to use JWT Decoder well
Best for
Decode JWT header and payload for inspection without verifying the signature.
Makes token claims readable so developers can inspect exp, iat, aud, iss, and custom payload fields during debugging.
Example workflow
- Input: Paste a JWT from a local development request header.
- Action: Decode it and inspect the header algorithm and payload claims.
- Expected result: Header and payload become readable JSON while the signature remains unverified.
Quality checks
- Clearly separates decoding from cryptographic verification.
- Handles Base64URL padding and structured JSON output.
- Pairs with timestamp conversion for exp and iat interpretation.
Watch out for
- A decoded JWT can still be forged or expired.
- Tokens may contain personal data or authorization scopes.
- Some systems use opaque tokens that are not JWTs.
Do not use it for
- Trusting a token in production without server-side signature verification.
- Pasting live user tokens from production systems into shared environments.
What to measure in the 90-day validation
- tool_used:decode
- tool_error rate
- related_tool_clicked:timestamp
- tool_copied
Decoding runs in the browser; treat JWTs as sensitive because payloads are only encoded, not encrypted.
Learn the concept
JWT decode vs verify
A developer guide to decoding JWT header and payload fields, verifying signatures, reading exp and iat claims, and avoiding common token mistakes.
Read the guide →Common use cases
- Inspect token claims while debugging authentication and authorization.
- Check expiration, issued-at, and not-before timestamps.
- Compare token payloads between staging, production, and local environments.
- Verify whether an API client is sending the expected audience, issuer, scope, or role claim.
- Explain token contents in support tickets without sharing secrets.
Examples
- Paste a sample JWT and inspect the alg and typ fields in the header.
- Decode the payload and convert exp or iat values with the timestamp converter.
- Compare two tokens to see whether aud, iss, scope, or role claims differ between environments.
Practical tips
- Never paste production bearer tokens or private secrets into tools you do not trust.
- Decoding is not the same as validating a signature.
- Check exp, nbf, aud, iss, scope, and role claims when troubleshooting auth.
- If a JWT has fewer than three dot-separated sections, it is not a standard signed JWT.
Related tools
Frequently asked questions
Does decoding verify a JWT?
No. Decoding only reads the header and payload. Signature verification must be done separately with the correct secret or public key.
What is Base64URL?
Base64URL is a URL-safe variant of Base64 used by JWT segments. It avoids characters that can be awkward inside URLs and headers.
Can I edit a JWT after decoding it?
Changing a token payload invalidates the original signature unless it is re-signed by a trusted issuer.
Why does my token say it is expired?
Check the exp claim and convert it as a Unix timestamp in seconds. Also confirm that your server and client clocks are synchronized.
Is it safe to paste a JWT into an online decoder?
Use sanitized or test tokens whenever possible. Production bearer tokens may grant access and should be treated like passwords.
Is JWT Decoder free to use?
Yes. JWT Decoder is free to use in your browser with no signup required.