JWT Decoder

Decode JWT tokens instantly

100% Client-Side Processing

Your token is decoded entirely in your browser. Nothing is sent to any server.

JWT Token

What is a JWT?

A JSON Web Token (JWT, pronounced “jot”) is an open standard (RFC 7519) for securely transmitting information between parties as a compact, URL-safe JSON object. JWTs are digitally signed, which means the information they contain can be verified and trusted.

JWTs are most commonly used for authentication and authorisation. When a user logs in to a web application, the server generates a JWT containing the user's identity and permissions, then sends it back to the client. The client includes this token in subsequent requests — typically in the Authorization header — so the server can verify who is making the request without querying a database each time.

For example, a hosting control panel at NetOz might issue a JWT after a customer logs in. That token could contain the customer's account ID, their hosting plan, and an expiry time. Every API request to manage their web hosting or email services would include this token, allowing the server to validate access instantly.

Unlike traditional session-based authentication where the server stores session data, JWTs are stateless. The server doesn't need to keep track of active sessions — all the information it needs is embedded in the token itself. This makes JWTs particularly useful for distributed systems, microservices, and single sign-on (SSO) implementations.

JWT Structure

Every JWT consists of three parts separated by dots (.): the header, the payload, and the signature. Each part is Base64URL-encoded, making the entire token safe to transmit in URLs, HTTP headers, and cookies.

A typical JWT looks like this:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyXzEyMyIsIm5hbWUiOiJKb2huIERvZSIsImlhdCI6MTcxMDAwMDAwMH0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Header Payload Signature

The compact format makes JWTs easy to pass around in HTTP headers, query parameters, or POST body data. Because each part is independently decodable, you can inspect the contents of a JWT without needing the signing key — which is exactly what this decoder tool does.

Header, Payload, and Signature

Header

The header typically contains two fields: the signing algorithm (alg) and the token type (typ). Common algorithms include HS256 (HMAC with SHA-256) for symmetric signing, and RS256 (RSA with SHA-256) for asymmetric signing.

{
"alg": "RS256",
"typ": "JWT"
}

The header may also include a kid (Key ID) field, which indicates which key was used to sign the token. This is common in systems that rotate signing keys, such as OAuth 2.0 providers.

Payload

The payload contains the claims — statements about the user and additional metadata. Claims fall into three categories:

Registered claims: Standard fields defined by the JWT specification, including iss (issuer), sub (subject), exp (expiration), iat (issued at), and aud (audience).
Public claims: Custom claims registered in the IANA JSON Web Token Claims registry or defined using collision-resistant names (URIs).
Private claims: Custom claims agreed upon between parties, such as roles, plan, or permissions.

{
  "iss": "https://auth.netoz.au",
  "sub": "user_8842",
  "exp": 1710003600,
  "iat": 1710000000,
  "roles": ["customer", "admin"]
}

Signature

The signature ensures the token hasn't been tampered with. It is created by taking the encoded header, the encoded payload, a secret or private key, and the algorithm specified in the header:

HMACSHA256(
base64UrlEncode(header) + "." + base64UrlEncode(payload),
secret
)

When using asymmetric algorithms like RS256, the token is signed with a private key and verified with the corresponding public key. This allows any service with the public key to verify the token without having access to the signing key — ideal for microservices architectures where multiple services need to validate tokens independently.

Note that this decoder does not verify signatures — it only decodes the Base64URL content. To verify a signature, you need the secret key or public key used to sign the token.

JWT Security Risks

While JWTs are widely used and generally secure when implemented correctly, there are several common security pitfalls developers should be aware of:

Algorithm Confusion Attacks

If a server accepts the alg value from the token header without validation, an attacker could change the algorithm from RS256 (asymmetric) to HS256 (symmetric) and sign the token with the public key — which is often publicly available. Always validate and restrict the accepted algorithms on the server side.

The “none” Algorithm

The JWT specification allows an algorithm value of none, meaning the token has no signature. Some libraries have been vulnerable to accepting unsigned tokens when this algorithm is specified. Servers should always reject tokens with alg: "none" unless explicitly intended.

Token Expiry and Revocation

Because JWTs are stateless, there is no built-in mechanism to revoke them before they expire. If a user's permissions change or their account is compromised, any previously issued tokens remain valid until their exp claim lapses. Mitigation strategies include using short expiry times (15–60 minutes), implementing token blacklists, or using refresh token rotation.

Sensitive Data in Payloads

JWT payloads are only Base64URL-encoded, not encrypted. Anyone with a token can decode it and read the claims — as this very tool demonstrates. Never store passwords, credit card numbers, API keys, or other sensitive data in a JWT payload. If you need to transmit sensitive data, use JSON Web Encryption (JWE) instead.

Token Storage

Storing JWTs in localStorage makes them accessible to any JavaScript running on the page, including malicious scripts injected via cross-site scripting (XSS). A more secure approach is to store tokens in HTTP-only cookies with the Secure and SameSite flags set, which prevents JavaScript access entirely.

Weak Signing Keys

When using symmetric algorithms like HS256, the signing secret must be strong enough to resist brute-force attacks. Short or predictable secrets can be cracked, allowing attackers to forge valid tokens. Use a cryptographically random secret of at least 256 bits, and rotate keys periodically.

Use this JWT decoder to inspect tokens during development and verify that your implementation follows security best practices. For related security checks, try our SSL Certificate Checker to verify your site's TLS configuration, or our HTTP Header Checker to ensure your security headers are properly set.