What is a JWT decoder?

A JWT decoder is a tool that reads a JSON Web Token and displays its contents in plain readable JSON. A JWT has three parts separated by dots: the header, the payload, and the signature. The header describes the algorithm used to sign the token. The payload contains the actual claims like user ID, expiry time, and issuer. Decoding simply means reading these parts, which are Base64 encoded, not encrypted.

Can I decode a JWT without a secret key?

Yes. Decoding a JWT does not require a secret key because the token is encoded not encrypted. Anyone with the token can read the header and payload by Base64 decoding them. The secret key is only needed to verify the signature, which proves the token was issued by a trusted source and has not been tampered with. This tool decodes but does not verify.

What information can I see after decoding a JWT?

After decoding you can see everything in the header and payload. The header typically shows the token type and signing algorithm such as HS256 or RS256. The payload shows claims like sub which is the subject or user identifier, iss which is the issuer, exp which is the expiry timestamp, and iat which is the time the token was issued. Applications can also add custom claims for their own purposes.

Is it safe to decode JWT tokens online?

It is safe when the tool runs entirely in your browser without sending data to a server. This tool processes everything locally using JavaScript. Your token never leaves your machine. That said avoid pasting tokens that are still active and grant access to sensitive production systems in any public tool as a general security practice.

How do I decode a JWT in JavaScript?

You can decode a JWT in JavaScript by splitting the token on the dot character, taking the second part which is the payload, and passing it to atob() to Base64 decode it, then parsing the result with JSON.parse(). For production use the jsonwebtoken library on Node.js handles both decoding and verification and is the industry standard.

What are the three parts of a JWT?

A JWT consists of three Base64 encoded sections separated by dots. The first is the header which contains the token type and algorithm. The second is the payload which contains the claims or data. The third is the signature which is created by signing the header and payload with a secret key. The signature cannot be decoded, only verified using the original key.

OpsBash.com ⚡ Free Tools

Buy me a Koffee

⚡ Free Online Tool

JWT Decoder – Free Online JSON Web Token Decoder

Paste a JWT and instantly see the header, payload and expiry details. Runs entirely in your browser. Nothing is uploaded or stored anywhere.

JWT Token

Frequently Asked Questions

What is a JWT Token?

A JWT or JSON Web Token is a compact string made up of three parts joined by dots. The header describes the signing algorithm. The payload holds the claims, which is the actual data being transmitted. The third part is the signature, which a server uses to confirm the token has not been altered. Both the header and payload are Base64 encoded, which means anyone can read them with a jwt decoder without needing a key. Decoding is always possible but verifying the signature requires the original secret. JWTs are the standard mechanism for stateless authentication in REST APIs and web applications because they carry all the information a server needs without a database lookup.

How JWT Authentication Works

When a user logs in, the server verifies their credentials and issues a signed JWT. The client stores this token, usually in memory or local storage, and sends it with every subsequent request in the Authorization header as a Bearer token. Because the server does not need to query session state from a database, this pattern is called stateless authentication. Any server that knows the signing key can validate requests independently, which makes JWT a natural fit for microservices where requests may be handled by different instances on each call. The tradeoff is that tokens cannot be invalidated server side before they expire, which is why short expiry times matter.

Understanding JWT Claims

Claims are the key-value pairs stored in the JWT payload. The specification defines a set of registered claims: sub identifies the subject, which is usually a user ID; iss names the issuer of the token; exp sets the expiry timestamp; iat records when the token was issued; and nbf sets the earliest time the token becomes valid. Public claims are shared in the IANA registry to avoid naming collisions across different systems. Private claims are custom fields agreed on between the parties. Real world examples include Kubernetes service account tokens, which use sub for pod identity, and OAuth2 access tokens, which commonly carry scope and aud claims to restrict what the token can access.

JWT Security Best Practices

Always verify the JWT signature server side before trusting any claim in the payload. Never rely on the payload contents alone. Use short expiry times so that stolen tokens become useless quickly. Keep in mind that the payload is only Base64 encoded and not encrypted, so anyone holding the token can read its contents. Never store passwords, credit card numbers, or other sensitive data in the payload. Always serve your application over HTTPS to prevent tokens being intercepted in transit. Rotate your signing keys on a regular schedule and revoke active tokens immediately when a breach is suspected.

The alg: none Attack: Why Decoding Isn't the Same as Trusting

The JWT specification includes an algorithm value called none, meaning literally no signature. A verifier that naively trusts whatever algorithm a token's own header claims can be tricked into skipping signature checking entirely. The attack: take any token, Base64 decode the header, change "alg": "RS256" to "alg": "none", edit the payload to whatever claims grant access such as "role": "admin", re-encode both pieces, and join them with a trailing dot and an empty signature. If the server's verification code accepts alg none, that forged token is treated as valid.

This isn't a hypothetical. Auth0 had a critical authentication bypass tied to exactly this in 2015, multiple WordPress plugins were vulnerable to the identical attack, and a popular LLM proxy project disclosed the same root cause in a security report as recently as February 2026. The fix is one parameter: never trust the algorithm a token declares about itself. Verification code should hardcode an explicit allowlist of accepted algorithms and reject everything else, including none, no matter what the payload contains.

This is exactly why decoding a JWT, which is what this tool does, is not the same as verifying one. Decoding reads the header and payload and tells you what a token claims. Verifying checks the signature against a secret key only your server holds, which tells you whether those claims can be trusted. Use this decoder to confirm a token's claims and expiry while debugging, then check your server's verification logic, specifically its algorithms allowlist, for the answer to whether it should actually be trusted.

If you work with JSON data try our JSON to YAML converter to move configs between formats instantly. Need to set file permissions on your server? Use our chmod calculator to calculate the right octal value for any permission set.