ToolDeck

رمزگشای JWT

رمزگشایی و بررسی JSON Web Token

یک مثال امتحان کنید

توکن JWT

به‌صورت محلی اجرا می‌شود · جای‌گذاری اسرار امن است
همچنین امتحان کنید:رمزگذار JWT

What Is a JWT (JSON Web Token)?

A JSON Web Token (JWT) is a compact, URL-safe token format defined in RFC 7519. It encodes a set of claims as a JSON object, then signs — and optionally encrypts — it so the recipient can verify the data has not been tampered with. JWTs are the de facto standard for stateless authentication in REST APIs, single-sign-on systems, and microservice authorization.

JWT Anatomy: Header · Payload · Signature

Every JWT is three base64url-encoded segments separated by dots. The header and payload are plain JSON — readable by anyone — while the signature is a cryptographic value that can only be verified with the correct key.

Encoded token

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyMTIzIiwibmFtZSI6IkFsaWNlIiwicm9sZSI6ImFkbWluIiwiaWF0IjoxNzE3MjAwMDAwLCJleHAiOjE3MTcyMDM2MDB9.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

HeaderPayloadSignature
Header
json
{
  "alg": "HS256",
  "typ": "JWT"
}
Payload
json
{
  "sub":  "user123",
  "name": "Alice",
  "role": "admin",
  "iat":  1717200000,
  "exp":  1717203600
}

Why Use a JWT Decoder?

Raw JWTs look like random text. This tool instantly renders the header and payload as formatted JSON so you can inspect claims, check expiration times, and audit algorithm choices without writing a single line of code.

🔍
Instant Claim Inspection
See every claim in the payload — sub, iss, aud, exp, custom roles, permissions — formatted and readable in one click.
🔓
No Secret Key Needed
The header and payload are public; only the signature requires the secret. This tool decodes both without your signing key.
⏱️
Expiry & Timestamp Parsing
Unix timestamps (exp, iat, nbf) are automatically converted to human-readable dates so you can instantly see whether a token has expired.
🔒
Runs Entirely in Your Browser
Everything is processed locally — no token data is sent to any server. Safe to use with production tokens while debugging.

Standard JWT Claims Reference

RFC 7519 defines seven registered claim names. These are not required, but their use is strongly recommended for interoperability. You can add any custom claims to the payload.

ClaimDescriptionType
issIssuerIdentifies who issued the token — e.g. your auth server URL or application name.string
subSubjectIdentifies the principal the JWT is about — typically a user ID or service account.string
audAudienceIdentifies the intended recipients. The receiving party must verify this matches their identifier.string | string[]
expExpiration TimeUnix timestamp after which the token must not be accepted. Always set this to limit damage from a stolen token.number
nbfNot BeforeUnix timestamp before which the token must not be accepted. Useful for scheduling future-dated tokens.number
iatIssued AtUnix timestamp at which the token was issued. Used to calculate token age.number
jtiJWT IDA unique identifier for the token. Enables revocation by storing and checking used JTI values server-side.string

JWT Signing Algorithms

The alg header claim declares which algorithm signed the token. The choice affects security, performance, and whether third-party services can verify tokens without the private key.

AlgorithmFamilyKey typeNotes
HS256HMACSymmetricMost common. Shared secret — anyone with the secret can both sign and verify.
HS384HMACSymmetricStronger HMAC variant; moderate performance cost.
HS512HMACSymmetricStrongest HMAC variant.
RS256RSAAsymmetricMost widely used asymmetric algorithm (Google, Auth0, Okta). Public key verifies without the private key.
RS384RSAAsymmetricHigher-security RS variant.
RS512RSAAsymmetricStrongest RS variant.
ES256ECDSAAsymmetricElliptic curve — shorter signatures than RSA, popular on mobile and IoT.
PS256RSA-PSSAsymmetricRSA-PSS: more modern and secure than PKCS1v1.5-based RS256.
noneNo signature — critically dangerous. Never accept tokens with alg: none in production.

Security Considerations

Decoding a JWT is always safe. Trusting a JWT without proper signature verification is not. Keep these rules in mind whenever you consume tokens in your application.

Always safe
  • Decode and inspect a JWT in developer tools or this tool
  • Use exp, iat, and nbf to understand token lifetime
  • Log payload claims for debugging (omit sensitive PII)
  • Read the alg header to understand how the token was signed
Never do this
  • Trust claims in the payload without verifying the signature server-side
  • Accept tokens with alg: none — this means no signature at all
  • Store access tokens in localStorage on high-security applications (prefer httpOnly cookies)
  • Set exp far in the future for tokens that carry sensitive permissions

Common Use Cases

Debugging Authentication Flows
Paste a token from your browser's network tab to inspect claims, check embedded roles, and verify expiration without touching production code.
Inspecting Third-Party Tokens
Quickly read tokens from Google, Auth0, Okta, or Azure AD to see what claims your provider includes and compare them with your expected schema.
API Development & Testing
When writing or testing API endpoints, decode the authorization header to confirm your token-generation logic sets the right sub, aud, and scope values.
Microservice Authorization
In service meshes, each service validates the JWT from the upstream caller. Decode tokens to trace which service issued the token and what permissions it asserts.
Support & Incident Response
When a user reports an authentication error, decode their token to check if it has expired, if the audience is wrong, or if a required claim is missing.
Security Auditing
Audit JWT usage across services by checking algorithm choices, expiry windows, and whether sensitive data is accidentally stored in the unencrypted payload.

Decoding JWT in Code

The header and payload are base64url-encoded — just reverse the encoding. Base64url replaces + with - and / with _, and omits = padding. Only the signature requires the secret key.

JavaScript (browser)
function decodeJWT(token) {
  const [, payload] = token.split('.')
  const json = atob(payload.replace(/-/g, '+').replace(/_/g, '/'))
  return JSON.parse(json)
}
Node.js
const [, payload] = token.split('.')
const decoded = JSON.parse(
  Buffer.from(payload, 'base64url').toString()
)
Python
import base64, json

def decode_jwt(token):
    payload = token.split('.')[1]
    padding = '=' * (-len(payload) % 4)
    return json.loads(base64.urlsafe_b64decode(payload + padding))
CLI (bash + jq)
TOKEN="eyJhbGc..."
echo $TOKEN | cut -d. -f2 | base64 -d 2>/dev/null | jq .

Frequently Asked Questions

Can I decode a JWT without the secret key?
Yes. The header and payload of a JWT are simply base64url-encoded JSON — not encrypted. Anyone can decode and read them. The secret (or private key for RS/ES algorithms) is only needed to verify the signature, confirming the token was not tampered with.
Does decoding a JWT mean the signature is verified?
No. Decoding only reads the claims. Verification is a separate step that checks the cryptographic signature using the correct key. Always verify the signature before trusting any claims in your application.
What is the difference between HS256 and RS256?
HS256 uses a single symmetric secret shared between the issuer and verifier — anyone with the secret can both create and verify tokens. RS256 uses an asymmetric key pair: the private key signs, the public key verifies. With RS256 you can distribute the public key so external services can verify tokens without the ability to forge them.
Why does base64 decoding sometimes fail?
JWTs use base64url encoding, which uses - instead of + and _ instead of /, and omits = padding characters. Standard base64 decoders require + and / and may require padding. Add the padding back (pad to a multiple of 4 with =) and swap the characters before decoding manually.
Is it safe to paste a production JWT into this tool?
Yes — this tool runs entirely in your browser and sends no data to any server. However, be mindful of who can see your screen or browser history. For highly sensitive tokens, decode them locally in your terminal instead.
What does alg: none mean and is it dangerous?
alg: none means the token has no cryptographic signature — anyone can craft a token with arbitrary claims and set alg to none. Some early JWT libraries accepted these tokens, creating a critical vulnerability. A secure JWT library always rejects tokens with alg: none unless explicitly configured otherwise. Never disable this check.