JWT Decoder
Decode a JWT's header and payload, with optional signature verification.
Example: A token like "eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.xyz" decodes to a header showing HS256 as the signing algorithm and a payload revealing the "sub" claim as "1234", typically set to expire within 1 hour — useful for debugging why an API call with that token is being rejected, without needing the signing secret.
Decodes tokens per the JWT standard, RFC 7519, published in 2015.
How JWT decoding and verification work
A JWT's header and payload are just base64url-encoded JSON — no secret is needed to read them, which is why decoding alone can never tell you whether a token is genuine. This tool decodes those two parts immediately so you can inspect claims like the issuer, subject, and expiry, and shows you the algorithm the token claims to be signed with.
Signature verification is a separate, optional step — supply the HMAC secret (for HS256/384/512 tokens) or the PEM public key (for RS256/ES256/PS256 tokens) and this tool checks the signature against the header and payload to confirm the token hasn't been tampered with. Never paste a private signing key here or anywhere else; only the public key or shared secret needed for verification is required.
Frequently asked questions
- Does this verify the JWT signature?
- Only if you provide a secret or public key. Without one, this tool only decodes the header and payload — it never asks you for anything sensitive by default. Signature verification requires the secret key (HS256/384/512) or the PEM public key (RS256/ES256/PS256), never the private key.
- Is it safe to paste my JWT here?
- Treat JWTs like passwords — they grant access to whatever they represent. For production tokens, use this tool only in a trusted environment. For debugging, prefer tokens from a test/staging environment.
- What is base64url encoding?
- A variant of standard Base64 that replaces + with - and / with _, making it safe for use in URLs and HTTP headers without percent-encoding. JWT uses base64url for all three of its parts.
- What is a JWT?
- A JSON Web Token (JWT) is a compact, URL-safe token format commonly used for authentication and information exchange. It encodes a set of claims (like a user ID or expiry time) as JSON, and can be cryptographically signed so a server can trust the claims haven't been tampered with.
- What are the three parts of a JWT?
- A JWT has three base64url-encoded parts separated by dots: the header (specifies the signing algorithm and token type), the payload (the actual claims — data about the user or session), and the signature (a cryptographic value proving the header and payload haven't been altered, if signed).
- What is the difference between decoding and verifying a JWT?
- Decoding just base64url-decodes the header and payload back into readable JSON — anyone can do this without any secret, since the content isn't encrypted, only encoded. Verifying additionally checks the signature against a secret or public key to confirm the token is authentic and hasn't been tampered with — decoding alone tells you nothing about whether a token is trustworthy.
- What is the `exp` claim in a JWT?
- The `exp` (expiration) claim is a standard JWT claim specifying a Unix timestamp after which the token should no longer be accepted. Servers are expected to reject any token where the current time is past `exp`, regardless of whether the signature is otherwise valid.
- Why should JWTs not be decoded on the client side for security decisions?
- Anyone can decode a JWT's payload without the signing key — decoding it client-side only reveals what the token claims, not whether those claims are genuine. Security-sensitive decisions (authorization, access control) must always be based on server-side signature verification, never on trusting a client-decoded payload at face value.