JWT decoding · HMAC verification · token generator

JWT Decoder & Generator

Decode token headers and payloads, inspect common claims, verify HS256/HS384/HS512 signatures, and generate test tokens. Everything runs locally in your browser for better privacy.

Local processing No uploads Web Crypto (HMAC) Fast on mobile
Decode instantly
Header, payload, signature
Verify HMAC
HS256 · HS384 · HS512
Generate tokens
Editable JSON inputs
Privacy notice: Your JWT is processed entirely inside your browser. No data is uploaded to our servers.
Warning: Do not paste production secrets or sensitive authentication tokens unless you trust your current device and browser session.
Try a sample
These presets are generated locally in your browser and never uploaded.
JWT Decoder
Structure Decoded Signature

Decoding is not verification. Decoding only reads the header and payload. Verification checks the signature using the secret and algorithm.
Header (JSON)
Payload (JSON)
Signature
Base64URL signature (3rd part)
JWT Claims Inspector
Expiration
Issued at (iat)
Not before (nbf)
Expires (exp)
Status
Paste a JWT to inspect claims.
Tip: Paste a token generated on the right, or click Use In Decoder after generating.
JWT Generator

JWT guide

A JSON Web Token (JWT) is a compact token format used to pass claims between systems—commonly between a browser/mobile client and an API. JWTs show up in login sessions, OAuth flows, API gateways, and service-to-service authentication. A JWT has three parts: the header, the payload, and the signature.

The header and payload are Base64URL-encoded JSON. Decoding means converting those two parts into readable JSON so you can inspect claims like sub, iss, aud, exp, and iat. Decoding does not prove a token is trustworthy.

Verification answers a different question: “Was this token actually signed by someone who knows the secret (or holds the private key)?” This page supports local HMAC verification for HS256, HS384, and HS512 using the browser Web Crypto API. If the secret or algorithm is wrong, verification fails—even if decoding works.

The header typically declares the algorithm (alg) and token type (typ). The payload contains claims—identities, permissions, and metadata. In many systems, the payload is readable by anyone who has the token, so you should not treat it as encrypted data.

JWTs can use symmetric algorithms (HMAC: HS256/384/512) or asymmetric algorithms (RSA/ECDSA). This tool focuses on HMAC because it’s common in internal services, test environments, and quick debugging scenarios. For production, choose algorithms and key management that match your threat model.

You’ll encounter JWTs when building SPA authentication, mobile login, API authorization, OAuth/OIDC integrations, and microservices. They’re also used in test fixtures, Postman collections, CI environments, and staging systems to simulate real auth flows.

Debugging a JWT often means checking claim values, time windows (exp/nbf), and signature validity across environments. If a token works in one environment but not another, common causes are mismatched secrets, different algorithms, clock drift, or incorrect audience/issuer validation.

Tokens can contain user identifiers, roles, internal URLs, and sometimes accidental secrets. Processing locally reduces the risk of leaking sensitive data to third parties. This page does not store tokens automatically and does not upload token contents for decoding or verification.

  • Assuming decoding means the token is valid or authentic.
  • Trusting payload claims without verifying the signature.
  • Using weak or reused HMAC secrets across environments.
  • Forgetting to validate exp, iss, and aud in your backend.
  • Putting sensitive data in the payload (JWTs are not encryption).

Related developer tools

FAQs

A JSON Web Token (JWT) is a compact string used to represent claims between parties. It typically contains a header, a payload (claims), and a signature, separated by dots.

This tool is designed for privacy: decoding, verification, and generation run locally in your browser. Still, you should avoid pasting production secrets unless you trust your device and browser session.

No. The JWT header, payload, signature, and secret are processed locally in your browser and are not uploaded to our servers.

Decoding converts the Base64URL header and payload into readable JSON. Verification checks that the signature matches the header+payload using a secret (for HMAC) and the selected algorithm.

Yes. Use the Generator panel, choose HS256, enter your secret, and click Generate JWT. HS384 and HS512 are supported too.

Common reasons include missing sections (JWT must have 3 dot-separated parts), invalid Base64URL encoding, non-JSON header/payload, or a signature that does not match the secret/algorithm.

Base64URL is a URL-safe variant of Base64 used by JWTs. It replaces characters like + and / with - and _, and omits padding (=).

You can verify signatures in your browser with this tool. Verification still requires the correct secret (for HS256/384/512) and the matching algorithm.

They are HMAC-based JWT signing algorithms that use SHA-256, SHA-384, and SHA-512 respectively. They require a shared secret for signing and verification.

No. Decoding only reveals the token contents. Authentication requires verifying the signature and validating claims (issuer, audience, expiration, etc.) according to your system’s rules.