Skip to main content

Decode JWT headers and payload claims online for auth debugging.

TempGBox

Runs 100% in your browserUpdated April 2026Free, no signup

JWT Decoder

Decode JWT header and payload. No verification, client-side only. Do not paste secrets.

A Deep Dive into JSON Web Tokens (JWT)

JSON Web Tokens (JWT) are an open, industry-standard (RFC 7519) method for representing claims securely between two parties. They are overwhelmingly used in modern web applications to authorize user sessions and share identity information between distinct backend microservices without needing to query a centralized database on every request.

The Anatomy of a JWT

A JWT consists of three parts separated by dots: the Header, the Payload, and the Signature.

  • Header: Typically consists of two parts: the type of the token (which is JWT) and the signing algorithm being used, such as HMAC SHA256 or RSA.
  • Payload: Contains the claims. Claims are statements about an entity (typically, the user) and additional data. Standard claims include the issuer (iss), expiration time (exp), and subject (sub).
  • Signature: Created by taking the encoded header, the encoded payload, a secret, and the algorithm specified in the header to digitally sign the token. This guarantees the token was not altered in transit.

Decoding Does Not Mean Verified

It is critical to understand that the header and payload of a standard JWT are Base64Url encoded, not encrypted. Our decoding tool simply reverses the Base64 encoding to reveal the raw JSON underneath. Anyone who intercepts a JWT can read its contents. Therefore, you must never store sensitive information (like passwords or credit card numbers) in a standard JWT payload. Decoded tokens must still be cryptographically verified against a server's secret key before determining trust.

What is JWT Decoder?

JWT Decoder helps with JWT Decoder Online. Decode JWT headers and payload. No verification, client-side only.

TempGBox keeps the workflow simple in your browser, so you can move from input to result quickly without extra software.

How to use JWT Decoder

  1. Open JWT Decoder and enter the text, value, file, or settings you want to work with.
  2. Review the output and adjust the available options until the result matches your use case.
  3. Copy, download, or reuse the final result in your workflow, content, app, or support task.

Why use TempGBox JWT Decoder?

  • Decode JWT headers and payload. No verification, client-side only
  • Useful for JWT Decoder Online
  • Fast browser-based workflow with no signup required

Common uses for JWT Decoder

JWT Decoder is useful for JWT Decoder Online. It fits well into quick checks, repeated office work, development flows, content updates, and everyday browser-based problem solving.

Because the tool is available instantly on TempGBox, you can handle one-off tasks and repeated workflows without installing extra software.

FAQ

Is JWT Decoder free to use?

Yes. JWT Decoder on TempGBox is free to use and does not require signup before you start.

What is JWT Decoder useful for?

JWT Decoder is especially useful for JWT Decoder Online.

Understanding JWT Decoder

A JSON Web Token consists of three Base64url-encoded segments separated by dots: header.payload.signature. The header declares the signing algorithm (typically RS256 or HS256) and token type. The payload contains claims — standardized fields like "iss" (issuer), "exp" (expiration as a Unix timestamp), "sub" (subject/user ID), "aud" (intended audience), and "iat" (issued-at time). The signature is computed over the header and payload using the specified algorithm and a secret or private key.

Client-side JWT decoding is inherently safe because the header and payload are not encrypted — they are merely Base64url-encoded. Anyone who possesses a JWT can decode and read its claims. The signature exists to prevent tampering, not to hide content. This is a common misconception: JWTs provide integrity and authenticity, not confidentiality. If you need to hide claim values from the client, use JWE (JSON Web Encryption) or keep the data server-side.

The choice between session-based authentication and JWT-based (stateless) authentication involves real tradeoffs. Sessions store state on the server (typically in Redis or a database), enabling instant revocation — delete the session and the user is immediately logged out. JWTs are stateless: the server does not need to look anything up, making them ideal for distributed systems with multiple backend instances. The downside is that revoking a JWT before its expiration requires a blocklist, reintroducing server-side state.

Common JWT vulnerabilities include the "alg:none" attack (where the attacker sets the algorithm to "none" and removes the signature), key confusion attacks (tricking an RS256 verifier into treating the public key as an HS256 secret), and token leakage via URL parameters or browser history. Always validate the "alg" header against an allowlist, never accept "none", and transmit tokens only in Authorization headers or httpOnly cookies — never in query strings.

Step-by-Step Guide

  1. Paste your complete JWT (all three dot-separated segments) into the input field. The tool accepts tokens from any issuer — Auth0, Firebase, AWS Cognito, Keycloak, or custom implementations.
  2. The decoder instantly splits the token and Base64url-decodes the header, revealing the algorithm ("alg"), token type ("typ"), and any additional header parameters like key ID ("kid").
  3. Inspect the payload claims. Standard claims include "sub" (user identifier), "iss" (who issued the token), "aud" (intended recipient), "exp" and "iat" (expiration and issued-at as Unix timestamps), and "nbf" (not-before time).
  4. Check the "exp" claim against the current time. The tool highlights whether the token is currently valid or expired, converting the Unix timestamp to a human-readable date.
  5. Review any custom claims added by your application — roles, permissions, tenant IDs, or feature flags. These are application-specific and not governed by the JWT spec.
  6. Examine the signature segment. While client-side tools cannot verify the signature (that requires the secret or public key), you can confirm the algorithm matches your expectations and detect tokens using "none".
  7. Copy the decoded header and payload as formatted JSON for use in bug reports, documentation, or debugging conversations.

Real-World Use Cases

A mobile developer integrates Firebase Authentication and needs to verify that the ID token contains the expected custom claims (admin: true) before enabling admin features in the UI. Decoding the token reveals that the claim was set on the backend but the token has not been refreshed.

A DevOps engineer is troubleshooting 401 errors in a microservices architecture. Decoding the JWT passed between services reveals that the "aud" claim specifies the API gateway's URL, but the downstream service expects its own URL, causing audience validation to fail.

A security auditor reviewing an API discovers that access tokens have 30-day expiration times and contain PII (email, phone number) in custom claims. The decoded payload provides evidence for the audit report recommending shorter token lifetimes and removing PII from token claims.

Expert Tips

When debugging OAuth flows, decode both the ID token and the access token. They often contain different claims: the ID token identifies the user (name, email), while the access token authorizes specific API scopes.

Check the "kid" (key ID) header when RS256 signature verification fails. If the issuer rotated their signing keys and your service cached the old public key, the "kid" mismatch is the root cause.

Never store JWTs in localStorage for production applications. Prefer httpOnly cookies with Secure and SameSite flags to prevent XSS-based token theft. localStorage is accessible to any JavaScript running on the page.

Frequently Asked Questions

Is it safe to decode a JWT in the browser?

Yes. JWT payloads are not encrypted — they are only Base64url-encoded, which is a reversible encoding, not a security mechanism. Anyone who possesses the token can read the claims. Decoding in the browser does not expose any information that is not already visible to anyone with the token string.

What does the "exp" claim mean and how do I read it?

The "exp" claim is the token's expiration time expressed as a Unix timestamp — the number of seconds since January 1, 1970 UTC. A value of 1735689600, for example, represents January 1, 2025 at midnight UTC. After this time, the token should be rejected by any properly implemented verifier.

What is the difference between HS256 and RS256?

HS256 (HMAC-SHA256) is a symmetric algorithm — the same secret key is used to sign and verify. RS256 (RSA-SHA256) is asymmetric — a private key signs and a separate public key verifies. RS256 is preferred for distributed systems where multiple services need to verify tokens without sharing a secret.

Can I verify a JWT signature in the browser?

For HS256 tokens, you would need the shared secret, which should never be exposed to a browser client. For RS256 tokens, verification is theoretically possible using the issuer's public key (often available via a JWKS endpoint), but it is computationally expensive and typically unnecessary for debugging purposes.

Why does my JWT have three parts separated by dots?

The three parts are the header (algorithm and token type), the payload (claims about the user and token metadata), and the signature (cryptographic proof that the header and payload have not been tampered with). Each part is independently Base64url-encoded, and the dots are literal separator characters.

What happens if I change a claim in a JWT?

Modifying any byte in the header or payload invalidates the signature. A properly configured server will reject the altered token because the recalculated signature will not match the one in the token. This is the entire purpose of the signature segment — to detect tampering.

Privacy: JWT decoding runs entirely in your browser. Tokens often contain personal information like email addresses and user IDs. This tool never transmits your tokens to any server, so sensitive claims remain on your device.