BrowserTools
Advertisement
Home / Encoders / JWT Decoder

JWT Decoder

Decode and inspect JSON Web Tokens locally, header, payload and expiry claims.

Loading JWT Decoder… If nothing happens, please enable JavaScript.

Frequently asked questions

Is my token uploaded to a server?
No. Decoding happens entirely in your browser using JavaScript's built-in atob function and JSON.parse. Your JWT — which may contain user identity, permissions, or session data — never leaves your device and is never sent over the network.
What are the three parts of a JWT?
A JWT is three Base64url-encoded JSON objects separated by dots. The header declares the token type ('JWT') and the signing algorithm (e.g., HS256, RS256). The payload contains the claims — standard fields like iss (issuer), sub (subject), exp (expiration), iat (issued at), plus any custom application claims. The signature is computed by the issuing server over the header and payload, and allows recipients to verify the token has not been tampered with.
When should I use a JWT in my own application?
JWTs are ideal for stateless authentication: once issued, the server does not need to store session state — the token itself carries everything needed to authorise a request. They are well-suited for microservices and APIs where multiple services need to verify identity without sharing a session database. They work well for short-lived access tokens (minutes to hours). For long-lived sessions where you need instant revocation, a traditional server-side session with a database lookup is often more appropriate.
How is a JWT different from a session cookie?
A session cookie stores a random opaque identifier; the server looks up the actual session data in a database on every request. A JWT is self-contained: the server validates the signature and reads the claims from the token itself, with no database lookup required. JWTs are therefore faster and easier to scale horizontally, but harder to revoke — you cannot 'log out' a JWT before it expires unless you maintain a token blocklist, which reintroduces server-side state.
Does this tool verify the JWT signature?
No, and deliberately so. Signature verification requires the issuer's secret key (for HMAC algorithms like HS256) or public key (for RSA/ECDSA algorithms like RS256). You should never paste a secret key into any third-party tool. This decoder shows you the decoded header and payload claims for inspection purposes only. For production signature verification, use a trusted library in your own environment.
What do the standard timestamp claims mean?
iat (issued at) is the Unix timestamp when the token was created. exp (expiration time) is the timestamp after which the token must be rejected. nbf (not before) is the timestamp before which the token must not be accepted. All three are seconds since the Unix epoch (January 1, 1970 UTC). This tool converts them to human-readable dates automatically so you can instantly see whether a token is expired or not yet valid.
Can a JWT be used without a signature (alg: none)?
The JWT spec technically permits an unsecured token with 'alg': 'none' and an empty signature. However, accepting such tokens in production is a critical security vulnerability. Several early JWT libraries trusted 'alg': 'none' by default, allowing attackers to forge arbitrary tokens. Always configure your JWT library to require a specific algorithm and reject tokens with 'alg': 'none' unless you have a very specific reason to allow unsigned tokens.
Are JWT payloads private and confidential?
No. A standard JWT (JWS — JSON Web Signature) signs the payload to guarantee integrity but does not encrypt it. The payload is simply Base64url-encoded, which anyone can decode instantly. Never include sensitive information — passwords, credit card numbers, national IDs, or any data you would not want exposed — in a JWT payload. If you need encrypted tokens, use JWE (JSON Web Encryption) instead, which is a separate standard.
What is the difference between HS256 and RS256?
HS256 uses HMAC-SHA256: the same secret key is used to both sign and verify the token, making it a symmetric scheme. This is simple but means every service that verifies tokens must know the secret. RS256 uses RSA-SHA256: the issuer signs with a private key, and any service can verify with the corresponding public key. RS256 is preferred in multi-service architectures because public keys can be shared freely via a JWKS endpoint, without exposing the signing secret.
What is a common mistake developers make with JWTs?
The most common mistake is treating a valid signature as proof of authorisation without also checking the exp claim — an expired token with a valid signature should always be rejected. A close second is storing the JWT in localStorage instead of an HttpOnly cookie, which exposes it to any JavaScript on the page (XSS attacks). A third pitfall is putting too much data in the JWT payload: large tokens add latency to every request because they must be transmitted in every HTTP header.

About JWT Decoder

A JSON Web Token (JWT) is a compact, URL-safe string that encodes a signed set of claims — assertions about a user, a session, or a permission — in a format that any party holding the right key can independently verify. Defined by RFC 7519 (2015) and part of the broader JOSE (JSON Object Signing and Encryption) standards family, JWTs quickly became the dominant mechanism for stateless authentication and API authorisation across web, mobile, and microservice architectures. A JWT consists of three Base64url-encoded segments separated by dots: the header (algorithm metadata), the payload (claims), and the signature.

JWTs appear in virtually every modern authentication flow. OAuth 2.0 access tokens are almost universally issued as JWTs. OpenID Connect ID tokens are JWTs that carry the authenticated user's identity claims. Single sign-on systems pass JWTs between identity providers and service providers. Serverless functions and edge workers validate JWTs locally without a database lookup, enabling stateless, horizontally scalable auth. Mobile apps store JWTs as bearer tokens and include them in the Authorization header of every API request. Understanding what is inside a token — what permissions it grants, when it expires, and who issued it — is a daily task for any backend or security engineer.

This tool decodes the header and payload of any JWT entirely inside your browser. It Base64url-decodes each segment, parses the JSON, and presents the claims in a readable format. Numeric timestamps (iat, exp, nbf) are automatically converted to human-readable dates so you can instantly see whether a token has expired. The signature is displayed as-is but is deliberately not verified: verification requires the issuer's secret (for HMAC) or public key (for RSA/ECDSA), and you should never paste either into an untrusted online tool. Because decoding happens locally, not even the token itself leaves your device.

A few security points to keep in mind: JWTs are signed but not encrypted by default — the payload is merely Base64url-encoded, meaning anyone who intercepts the token can read its claims. Never include sensitive personal data (passwords, credit card numbers) in a JWT payload. The alg: none attack is a known vulnerability in naive JWT libraries that accept unsigned tokens; always use a well-audited library that explicitly validates the algorithm. Also check the exp claim before trusting a token — a valid signature does not mean the token is still active.

The rise of the JSON Web Token

JSON Web Tokens were introduced by the Internet Engineering Task Force (IETF) as part of the JOSE (JSON Object Signing and Encryption) working group, with RFC 7519 published in May 2015. The goal was to create a compact, self-contained credential format that could replace the verbose and complex SAML XML assertions used in enterprise single sign-on systems. The dot-delimited, Base64url-encoded design was deliberately chosen to be URL-safe and to fit comfortably inside an HTTP header.

Adoption was explosive. Within a few years of publication, nearly every major authentication framework — from Auth0 to Firebase Authentication to AWS Cognito — had standardised on JWTs as their token format. The jwt.io website, launched by Auth0 as a debugging tool, became one of the most visited developer utilities on the internet. This popularity also attracted scrutiny: security researchers catalogued a series of implementation vulnerabilities (the 'alg: none' bug, algorithm confusion attacks) that affected naive library implementations, spurring a wave of improvements in JWT libraries across every programming language.

An interesting design choice in JWTs is that the payload is readable by anyone — the signature guarantees integrity but not secrecy. This was intentional: the designers wanted tokens to be debuggable without a key, enabling tools like JWT decoders to help developers inspect tokens during development. The trade-off is that developers must be disciplined about what claims they include, a lesson that has been learned the hard way by teams that accidentally shipped JWTs containing sensitive user data.

Related tools

Base64 Encoder & Decoder

Encode and decode Base64 text or files locally in your browser.

Hash Generator (SHA-1, SHA-256, SHA-384, SHA-512)

Compute cryptographic hashes of text or files locally, SHA-1, SHA-256, SHA-384 and SHA-512.
Advertisement