JWT Decoder

JWT Decode Tokens Online

Decode any JSON Web Token instantly with this free online jwt decode tool. This jwt decoder parses the three segments of a JWT, revealing the header algorithm, payload claims, and signature data without requiring a secret key. Whether you are debugging authentication flows, inspecting json web token contents from an API response, or verifying token expiration times, get structured decoded output in real time.

What is JWT Decoding

JWT decoding is the process of parsing a JSON Web Token to reveal its contents. A JWT consists of three Base64URL-encoded segments separated by periods: the header, the payload, and the signature. Decoding extracts and displays the JSON data contained in the header and payload segments, making the token's claims and metadata human-readable.

JSON Web Tokens are defined in RFC 7519 and are widely used for authentication and authorization in web applications. When a user logs in, the server creates a JWT containing claims about the user's identity and permissions, signs it with a secret key or private key, and sends it to the client. The client includes this token in subsequent requests to prove its identity.

It is important to understand that JWT decoding is not the same as JWT verification. Decoding simply reads the token contents, which anyone can do without a secret key. Verification checks the cryptographic signature to confirm that the token was issued by a trusted party and has not been tampered with. Decoding reveals what the token says; verification confirms whether it can be trusted.

How JWT Decoding Works

A JWT is a string with three parts separated by dots: header.payload.signature. The decoding process splits the token on the period characters, then Base64URL decodes the first two segments to reveal their JSON content. The third segment (signature) is binary data that is only meaningful for cryptographic verification.

The header segment contains metadata about the token, typically including the signing algorithm (alg) and token type (typ). A common header looks like {"alg":"HS256","typ":"JWT"}, indicating the token uses HMAC-SHA256 for its signature. Other algorithms include RS256 (RSA with SHA-256), ES256 (ECDSA with SHA-256), and "none" for unsigned tokens.

The payload segment contains the claims, which are statements about the user and additional metadata. Standard claims defined in RFC 7519 include iss (issuer), sub (subject), aud (audience), exp (expiration time), nbf (not before), iat (issued at), and jti (JWT ID). Custom claims can contain any JSON-serializable data such as user roles, permissions, or application-specific information. The payload is Base64URL encoded, which is the same encoding used by our Base64URL decoding converter tool for general-purpose decoding.

Syntax Comparison

Here is how to decode JWTs in popular programming languages:

JavaScript: Split the token on dots and decode each part: JSON.parse(atob(token.split(".")[1].replace(/-/g,"+").replace(/_/g,"/"))). Libraries like jsonwebtoken and jose provide decode functions with additional validation.

Python: The PyJWT library provides jwt.decode(token, options={"verify_signature": False}) to decode without verification. For manual decoding, use base64.urlsafe_b64decode with padding correction on each segment.

Java: Libraries like java-jwt (Auth0) and jjwt (io.jsonwebtoken) provide built-in decode methods. For manual decoding, use java.util.Base64.getUrlDecoder().decode() on each segment.

Go: The golang-jwt/jwt library provides ParseUnverified() for decoding without signature verification. The standard library's encoding/base64 package with RawURLEncoding handles the Base64URL decoding step.

Common Use Cases

Debugging Authentication Flows: When building or troubleshooting OAuth 2.0 and OpenID Connect integrations, developers frequently need to inspect JWT contents to verify that tokens contain the expected claims, correct audience values, and appropriate expiration times. Decoding tokens during development helps identify configuration issues before they reach production.

Token Expiration Checking: JWTs contain an "exp" claim with a Unix timestamp indicating when the token expires. Decoding the token lets you quickly check whether a token has expired, how much time remains before expiration, and whether the token lifetime matches your application's configuration.

Claim Inspection: API developers decode JWTs to verify that custom claims like user roles, permissions, tenant IDs, and feature flags are correctly populated. This is especially important when integrating with third-party identity providers that may structure claims differently than expected.

Security Auditing: Security teams decode JWTs to audit what information is being transmitted in tokens. Since JWT payloads are only encoded and not encrypted, any sensitive data in the payload is visible to anyone who intercepts the token. Auditing helps ensure that tokens do not contain unnecessary personal information.

JWT Decode Examples

Here are practical examples demonstrating jwt decode with common token structures:

Example 1 - Basic Access Token: A typical access token decodes to a header of {"alg":"HS256","typ":"JWT"} and a payload containing {"sub":"1234567890","name":"John","iat":1516239022}. The "sub" claim identifies the user, "name" is a custom claim, and "iat" records when the token was issued as a Unix timestamp.

Example 2 - OAuth 2.0 Token: An OAuth access token might decode to a payload with {"iss":"https://auth.example.com","sub":"user123","aud":"api.example.com","exp":1735689600,"scope":"read write"}. The "iss" identifies the authorization server, "aud" specifies the intended API, "exp" sets the expiration, and "scope" defines the granted permissions.

Example 3 - OpenID Connect ID Token: An OIDC ID token payload typically includes {"iss":"https://accounts.example.com","sub":"user456","aud":"client-app-id","exp":1735689600,"email":"user@example.com","email_verified":true,"nonce":"abc123"}. ID tokens contain identity claims like email and verification status alongside standard JWT claims.

Example 4 - RS256 Signed Token: A token signed with RS256 has a header of {"alg":"RS256","typ":"JWT","kid":"key-id-123"}. The "kid" (key ID) claim helps the verifier select the correct public key from a JWKS (JSON Web Key Set) endpoint. RS256 tokens use asymmetric cryptography, allowing verification with a public key while only the issuer holds the private signing key.

To understand the Base64URL encoding used in each JWT segment, our Base64URL encoding tool demonstrates how the raw JSON is transformed into the URL-safe format. For standard Base64 operations outside of JWT contexts, our Base64 decoding tool handles the traditional alphabet with padding.

Frequently Asked Questions

Is it safe to decode a JWT in the browser?

Yes, decoding a JWT in the browser is safe because the token contents are not secret. JWT payloads are Base64URL encoded, not encrypted, so anyone with access to the token can read its contents. The security of a JWT comes from its cryptographic signature, which prevents tampering, not from hiding the payload. However, you should never paste production tokens containing real user data into third-party online tools.

What is the difference between JWT decoding and JWT verification?

Decoding extracts the header and payload from a JWT by reversing the Base64URL encoding. Anyone can decode a JWT without any keys. Verification checks the cryptographic signature to confirm the token was created by a trusted issuer and has not been modified. Verification requires the signing key (secret key for HMAC algorithms, public key for RSA or ECDSA). Always verify tokens on the server side before trusting their claims.

Can a JWT be tampered with after decoding?

A JWT can be modified by anyone since the payload is just Base64URL-encoded JSON. However, any modification invalidates the cryptographic signature. When the server verifies the token, it recalculates the signature using the original header and payload. If the recalculated signature does not match the token's signature, verification fails and the token is rejected. This is why signature verification is critical for security.

What does the "exp" claim mean in a JWT?

The "exp" (expiration time) claim contains a Unix timestamp (seconds since January 1, 1970 UTC) indicating when the token becomes invalid. For example, an exp value of 1735689600 represents a specific date and time. Servers should reject tokens where the current time exceeds the exp value. Short expiration times improve security by limiting the window during which a stolen token can be used.

Why does my JWT have three dots?

A JWT uses dots (periods) as delimiters between its three segments: header, payload, and signature. The format is header.payload.signature where each segment is Base64URL encoded. If you see only two dots with nothing after the second one, the token is unsigned (using the "none" algorithm). Unsigned tokens should never be trusted in production systems as they provide no integrity guarantees.

What is the difference between JWS and JWE?

JWS (JSON Web Signature) and JWE (JSON Web Encryption) are two different JWT formats. JWS tokens are signed but not encrypted, meaning their payload is readable by anyone but tamper-proof. JWE tokens are encrypted, meaning their payload is hidden from anyone without the decryption key. Most JWTs in practice are JWS tokens. This decoder handles JWS tokens, which are the standard format for OAuth 2.0 and OpenID Connect.

Can JWTs contain sensitive information?

JWTs can technically contain any JSON data, but storing sensitive information in a standard JWT (JWS) is not recommended because the payload is only encoded, not encrypted. Anyone who intercepts the token can decode and read its contents. Avoid putting passwords, credit card numbers, or other sensitive data in JWT payloads. If you need to transmit sensitive claims, use JWE (encrypted JWTs) or keep sensitive data server-side and reference it by ID in the token.