What this tool does
JWT Decoder
Your input is sent to the server for this request and is not saved as a tool content record. Infrastructure logs may still record request metadata, so do not submit secrets.
JWT Decoder expects exactly three dot-separated sections, Base64URL-decodes the header and payload, and parses both as JSON. It also reports whether a signature section is present.
Decoding is not cryptographic verification. Do not trust issuer, audience, expiry, permissions, or any other claim until the application verifies the signature with the expected algorithm and key and applies its own validation rules.
How to use this tool
How to decode a JWT for inspection
Paste the JWT.
Run the decoder.
Inspect the header and payload.
Before and after example
Decoded JWT header and payload example
Input
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJzY3JpcHR6aXAiLCJyb2xlIjoidG9vbCJ9.signatureOutput
{
"header": {"alg": "HS256", "typ": "JWT"},
"payload": {"sub": "scriptzip", "role": "tool"}
}Options, errors, and limitations
JWT decoding and signature-verification limits
Parent category
Explore the Security Tools hub
Developer utilities for JWT inspection, hashing, regex review, and safe encoding workflows.
Related articles
Read more from the developer blog
Practical guides
Troubleshoot and choose the next step
FAQ
JWT Decoder FAQ
Can I decode a JWT without the secret key?
Yes for a normal signed JWT. The header and payload are Base64url encoded and are not encrypted, so they can be read without the signing key. The key is needed to verify the signature, not to read those segments.
What is the difference between decoding and verifying a JWT?
Decoding only reads the token contents. Verification cryptographically checks that the signature was created by a trusted key and that the token has not been altered, while validation also checks claims such as issuer, audience, and expiration.
Why does a JWT usually have three parts?
A compact signed JWT commonly consists of a header, payload, and signature separated by periods. The header describes metadata such as the algorithm, the payload carries claims, and the signature protects integrity.
What do exp, iat, and nbf mean in a JWT?
exp is the expiration time, iat is the issued at time, and nbf is the not before time. Applications should interpret these claims according to the JWT specification and their own clock skew and validation rules.
Why does normal Base64 decoding sometimes fail on a JWT?
JWT segments use Base64url, which uses a URL safe alphabet and often omits padding. A decoder must apply Base64url rules rather than assuming classic Base64 input.
Can a JWT payload be trusted just because it decodes correctly?
No. An attacker can create or modify a token that decodes perfectly. Trust the claims only after verifying the signature and validating the expected issuer, audience, algorithm, time based claims, and application rules.
Can a JWT be encrypted instead of just signed?
Yes, but encrypted JWT content uses JSON Web Encryption and is different from a normal readable signed JWT. A basic JWT decoder cannot reveal encrypted claims without the appropriate decryption key.
Is it safe to paste a live JWT into an online decoder?
Be cautious because a JWT can act as a bearer credential. Avoid sharing production access tokens, refresh tokens, or sensitive session tokens with third party services unless you fully trust their privacy and processing model.
What does the JWT signature prove?
A valid signature proves that the signed header and payload have not been modified since signing and that the signer possessed the relevant key. It does not automatically prove the token should be accepted for your application unless claim validation also passes.
Should my application accept whatever algorithm appears in the JWT header?
No. Secure implementations should allow only the algorithms expected by the application and key configuration. JWT best practices warn against algorithm confusion and other cases where untrusted token metadata influences verification incorrectly.