How to Decode a JWT Token Online
Decode and inspect JWT tokens instantly with our free JWT Decoder. See header, payload, and signature without any server-side tools.
Steps
Copy your JWT token
Find the JWT you want to inspect. It is a long string of three dot-separated parts, typically beginning with 'eyJ' (the Base64url encoding of the JSON header). Copy the entire token including all three parts.
Paste the token
Paste the full JWT string into the input field. The tool splits the token at the dots and decodes each section independently.
Inspect the header
The decoded header shows the algorithm (alg) — typically HS256, RS256, or ES256 — and the token type (typ: JWT). The algorithm tells you how the signature was generated, which is important for verification.
Read the payload claims
The payload section contains the actual claims: standard fields like sub (subject/user ID), iat (issued at timestamp), exp (expiry timestamp), iss (issuer), and aud (audience), plus any custom claims your application added. The tool converts Unix timestamps to human-readable dates automatically.
Check expiry and other timestamps
Compare the exp claim against the current time to determine if the token is still valid. A token where exp is in the past is expired and will be rejected by any properly implemented server. The nbf (not before) claim, if present, tells you the earliest time the token is valid.
JWT Structure: Header, Payload, and Signature
A JSON Web Token consists of three Base64url-encoded parts separated by dots: HEADER.PAYLOAD.SIGNATURE. The header is a JSON object describing the token type and signing algorithm. The payload is a JSON object containing claims — statements about the subject (usually a user) and additional metadata. The signature is computed by applying the algorithm specified in the header to the encoded header and payload using a secret key. The signature ensures the token has not been tampered with since it was issued. Importantly, the header and payload are only encoded, not encrypted — anyone can decode and read them. Never put sensitive secrets like passwords or API keys in a JWT payload unless you are using JWE (JSON Web Encryption) for a fully encrypted token.
Standard JWT Claims Explained
The JWT specification defines several registered claim names with specific meanings. iss (Issuer): identifies the party that issued the token, often a domain name or service identifier. sub (Subject): the principal the token refers to, usually a user ID. aud (Audience): the intended recipient(s) of the token. exp (Expiration Time): a Unix timestamp after which the token must not be accepted. nbf (Not Before): a Unix timestamp before which the token must not be accepted. iat (Issued At): the Unix timestamp when the token was issued. jti (JWT ID): a unique identifier for the token, used to prevent replay attacks. Applications add custom claims beyond these standard ones — for example, a role claim for user permissions or an email claim for the user's address.
Common JWT Problems and How to Debug Them
The most common JWT issues in development are: expired tokens (check the exp claim and ensure your system clocks are synchronised using NTP), wrong audience (the aud claim must match what your server expects), signature validation failures (ensure the server is using the same secret or public key that was used to sign the token), and algorithm confusion attacks (servers should explicitly specify expected algorithms rather than trusting the alg header value — the 'none' algorithm attack exploits servers that accept alg: none). Use this decoder to quickly inspect what a token actually contains when debugging authentication issues. Compare the claims against what your application expects to identify mismatches.
Frequently Asked Questions
Our decoder runs entirely in your browser — the token never leaves your device. No data is sent to any server. That said, treat production JWTs with care: they often contain user identity information and access credentials. For production tokens with sensitive payloads, use a local decoder or decode manually in your terminal with: echo 'payload_part' | base64 -d. Only paste tokens into online tools from development or test environments.
Decoding shows you the header and payload but cannot verify the signature without the secret key. To verify, you need the secret (for HMAC algorithms like HS256) or the public key (for RSA/ECDSA algorithms like RS256/ES256). Use a server-side JWT library in your language of choice (jsonwebtoken for Node.js, PyJWT for Python, java-jwt for Java) to perform full signature verification.
The header and payload sections of a JWT are Base64url-encoded JSON objects. All JSON objects start with { which encodes to eyJ in Base64url. This is why all standard JWTs begin with eyJ — it is the Base64url encoding of the opening characters of a JSON object.
Traditional session tokens are opaque random strings — the server stores session data and looks it up by the token ID. JWTs are self-contained: all the claims are encoded in the token itself, so the server does not need a database lookup to read them. This makes JWTs stateless and scalable, but also means you cannot invalidate them before they expire without maintaining a deny-list.