Configuration

Algorithm

Encryption Secret

Base64 encoded

JWT Encoder / Decoder | HS256

Encoded JWT | Generated

Validation: Unknown

Decoded JWT | Source ⬅

JWT Encoder / Decoder

Decode a JSON Web Token to inspect its header and claims, or encode one with the algorithm of your choice. Useful for debugging an authentication problem, checking what a token actually asserts, or confirming when it expires. Decoding happens in your browser, so tokens you paste here are never transmitted.

JWT Components

A JWT (JSON Web Token) is a compact and secure way to represent claims between two parties, typically for authentication. It consists of three components:

Component	Description
Header	Contains metadata about the token, including the signing algorithm (alg) and token type (typ).
Payload	Contains the claims (statements about an entity), such as user data or roles. It can include registered claims (like exp, iss, sub), or custom claims.
Signature	Ensures the token's integrity and authenticity. It's created by signing the header and payload with a secret key (or private key for RSA).

Encoding / Decoding

Algorithm	Description
Encoding	Encode the Header: The header (which includes the algorithm and token type) is serialized to a JSON string. It is then Base64Url encoded, which turns the string into a compact, URL-safe format. Encode the Payload: The payload (which contains claims) is serialized into a JSON string. This string is also Base64Url encoded, creating the second part of the JWT. Create the Signature: The encoded header and payload are combined, separated by a period (.). The signature is generated by applying the specified signing algorithm (e.g., HMAC SHA-256 or RSA) to the combined string, using a secret key (or private key for RSA). The resulting signature is Base64Url encoded. Finally, the JWT is formed by concatenating the three parts with periods (.): [Base64Url(header)] . [Base64Url(payload)] . [Base64Url(signature)]
Decoding	Split the JWT: The JWT is split into three parts by periods (.); [Header] . [Payload] . [Signature] Decode the Header and Payload: The first two parts (header and payload) are Base64Url decoded to retrieve the original JSON strings. This provides the header (metadata) and the payload (claims/data). Verify the Signature: To ensure the JWT hasn't been tampered with, the signature is verified: The decoded header and payload are re-encoded (Base64Url). The verification algorithm (e.g., HMAC SHA-256 or RSA) is used with the secret key (or public key for RSA) to check if the signature matches the expected one. If the signature is valid, the JWT is authentic and untampered. If invalid, the JWT should be rejected. This process allows to extract and validate the information contained in the JWT.

Supported Algorithms

Symmetric Key Algorithms (both signing and verification use the same key)

Name	# Hash	Description
HS256	SHA-256	The HS256 (HMAC with SHA-256) is a symmetric-key signing algorithm used in JWTs. It combines the HMAC (Hash-based Message Authentication Code) mechanism with the SHA-256 cryptographic hash function to ensure data integrity and authenticity.
HS384	SHA-384	The HS384 (HMAC with SHA-384) is a symmetric key signing algorithm used in JWTs, similar to HS256, but with a stronger hash function (SHA-384) for enhanced security.
HS512	SHA-512	The HS512 (HMAC with SHA-512) is a symmetric key signing algorithm for JWTs that uses the SHA-512 hash function, offering an even higher level of security than HS256 and HS384.

Asymmetric Key Algorithms (the signing and verification processes use different keys - private key is used for signing and public Key is used for verifying the JWT's authenticity)

Name	# Hash	Description
RS256	SHA-256	The RS256 (RSA Signature with SHA-256) is an asymmetric signing algorithm used in JWTs. It uses the RSA algorithm for signing and the SHA-256 hash function for creating the signature.
RS384	SHA-384	The RS384 (RSA Signature with SHA-384) is an asymmetric signing algorithm used in JWTs, similar to RS256, but with a stronger hash function (SHA-384 instead of SHA-256) for added security.
RS512	SHA-512	The RS512 (RSA Signature with SHA-512) is an asymmetric signing algorithm for JWTs that uses the RSA algorithm combined with the SHA-512 hash function for creating the signature.
ES256	SHA-256	The ES256 (ECDSA with SHA-256) is an asymmetric signing algorithm for JWTs that uses Elliptic Curve Digital Signature Algorithm (ECDSA) with the SHA-256 hash function.
ES384	SHA-384	The ES384 (ECDSA with SHA-384) is an asymmetric signing algorithm used in JWTs that employs Elliptic Curve Digital Signature Algorithm (ECDSA) with the SHA-384 hash function for signing.
ES512	SHA-512	The ES512 (ECDSA with SHA-512) is an asymmetric signing algorithm for JWTs that uses the Elliptic Curve Digital Signature Algorithm (ECDSA) with the SHA-512 hash function.
PS256	SHA-256	The PS256 (RSASSA-PSS with SHA-256) is an asymmetric signing algorithm for JWTs that uses RSASSA-PSS (RSA Signature Scheme with Appendix - Probabilistic Signature Scheme) combined with the SHA-256 hash function. It provides enhanced security compared to traditional RSA signatures (like RS256) by using a probabilistic approach to signing.
PS384	SHA-384	The PS384 (RSASSA-PSS with SHA-384) is an asymmetric signing algorithm used in JWTs that employs the RSASSA-PSS (RSA Signature Scheme with Appendix - Probabilistic Signature Scheme) combined with the SHA-384 hash function.
PS512	SHA-512	The PS512 (RSASSA-PSS with SHA-512) is an asymmetric signing algorithm used in JWTs that combines RSASSA-PSS (RSA Signature Scheme with Appendix - Probabilistic Signature Scheme) with the SHA-512 hash function.

A Signed Token Is Not an Encrypted One

This is the most important thing to understand about JWTs, and the source of a great many security incidents. The header and payload are Base64url encoded, not encrypted. Anyone holding the token can read every claim in it without the key — this tool does exactly that.

The signature does not provide secrecy. It provides integrity: it proves the token was issued by someone holding the signing key and has not been altered since. Those are different guarantees, and confusing them is how personal data ends up sitting readable inside a token.

The practical rule: never put anything in a payload that you would not be willing to show the token's bearer. No passwords, no secrets, no sensitive personal information.

Standard Claims

The payload can carry anything, but a set of registered claim names have agreed meanings and are what libraries validate automatically.

iss (issuer) — who created the token.
sub (subject) — who the token is about, typically a user ID.
aud (audience) — who the token is intended for. A service should reject tokens not addressed to it.
exp (expiration time) — after this moment the token must be rejected.
nbf (not before) — the token is invalid until this time.
iat (issued at) — when the token was created, useful for age policies.
jti (JWT ID) — a unique identifier, used to prevent replay.

Time claims are Unix timestamps — seconds since 1 January 1970 — which is why they look like large integers rather than dates.

Common Uses

Debugging authentication — see what claims a token actually carries when a request is rejected.
Checking expiry — confirm whether a token has lapsed, the single most common cause of a sudden 401.
Inspecting OAuth and OpenID tokens — identity providers issue JWTs, and reading them clarifies what a provider is asserting.
API development — verify that the tokens your service issues contain the claims you intended.
Confirming the algorithm — check that a token is signed with the algorithm you expect.

Security Pitfalls

The "none" algorithm. A token can claim it needs no signature. Libraries that honored this allowed anyone to forge tokens freely. Always validate against an expected algorithm rather than trusting the header.
Trusting the header's algorithm choice. Related, and equally serious: an attacker who can switch a token from RSA to HMAC may be able to sign it with the public key. Pin the algorithm on the server.
Not verifying at all. Decoding is not validating. A token is only trustworthy once its signature has been checked against the correct key.
Long or absent expiry. A leaked token stays valid until it expires, and JWTs cannot easily be revoked. Keep lifetimes short and use refresh tokens.
Storing tokens carelessly. A token in browser storage is exposed to any script running on the page.

Frequently Asked Questions

Can anyone read my JWT?

Yes. The payload is only Base64url encoded, so any holder of the token can read it without a key. Treat the contents as public and put nothing sensitive inside.

What does the signature actually prove?

That the token was issued by a party holding the signing key and has not been modified. It says nothing about confidentiality — only about authenticity and integrity.

HMAC or RSA — which should I use?

HMAC algorithms such as HS256 use one shared secret, which is simpler when the same service issues and verifies tokens. RSA and ECDSA algorithms sign with a private key and verify with a public one, so use those when verifiers should be able to check tokens without the power to mint them.

Why is my token rejected even though it looks correct?

Most often expiry. Check the exp claim against the current time. After that, the usual causes are a mismatched audience, an algorithm the server does not accept, or clock skew between the issuing and verifying machines.

How do I revoke a JWT?

You largely cannot, which is the main tradeoff of the design. Because verification is self-contained, a valid token stays valid until it expires. Practical approaches are short lifetimes plus refresh tokens, or a server-side denylist — though the latter reintroduces the state that JWTs exist to avoid.

Is my token sent anywhere by this tool?

No. Encoding and decoding run entirely in your browser, so tokens you inspect here are never transmitted or logged.