JWT Decoder & Encoder

Decode, inspect, and verify JSON Web Tokens instantly. Paste any JWT to see its decoded header, payload claims, and signature. Supports HS256, RS256, and all standard algorithms. Ideal for debugging authentication flows, inspecting OAuth tokens, and building secure APIs. All processing is in-browser — your tokens never leave your device.

0 characters
89 characters

What is a JWT?

A JSON Web Token (JWT) is an open standard (RFC 7519) for securely transmitting information between parties as a digitally signed JSON object. A JWT consists of three dot-separated Base64URL-encoded sections: Header, Payload, and Signature.

JWTs are stateless — all the information needed to authorise a request is embedded in the token itself, removing the need for server-side session storage.

JWT Structure

  • HeaderToken type (JWT) and signing algorithm, e.g. HS256, RS256
  • PayloadClaims: sub (subject), iat (issued at), exp (expiry), and custom claims
  • SignatureHMAC or RSA signature of header + payload, used to verify authenticity
  • Formatxxxxx.yyyyy.zzzzz — three parts joined by dots

Security Notes

  • JWT payloads are only Base64URL encoded — not encrypted. Never store sensitive data in the payload.
  • Always verify the signature server-side — never trust unverified tokens.
  • Prefer short expiry times (exp) and use refresh tokens.
  • Use RS256 (asymmetric) for public APIs; HS256 for internal services.
  • Store tokens in httpOnly cookies, not localStorage, to protect against XSS.

Common JWT Use Cases

API Auth

Debug Bearer tokens in REST API requests from Postman or browser DevTools.

OAuth / OIDC

Inspect access and ID tokens from Google, Auth0, or Okta OAuth flows.

SSO

Verify Single Sign-On tokens and check expiry and claim values.

Microservices

Inspect service-to-service JWTs for internal API authentication.

Frequently Asked Questions

JSON Web Tokens and Modern Authentication

JSON Web Tokens have become the backbone of stateless authentication in web applications. Unlike traditional session-based auth that stores state on the server, JWTs embed all necessary information — user identity, permissions, and expiry — directly in the token itself. This eliminates the need for server-side session storage, makes horizontal scaling trivial, and enables seamless authentication across microservices. Every major authentication provider — Auth0, Okta, Firebase, AWS Cognito — uses JWTs as the default token format for OAuth 2.0 and OpenID Connect flows.

JWT Security Best Practices

JWTs are signed, not encrypted — anyone with the raw token can decode and read the payload. Never store passwords, credit card numbers, or sensitive PII in JWT claims. Always verify the signature server-side before trusting any claim. Use short expiry times (15 minutes for access tokens) paired with refresh tokens for long-lived sessions. Store tokens in httpOnly cookies rather than localStorage to protect against XSS attacks. For public-facing APIs, prefer RS256 (asymmetric RSA) over HS256 (symmetric HMAC) so the verification key can be shared publicly via JWKS endpoints without compromising the signing key.

Debugging Authentication Flows

Debugging JWT-based authentication often starts with decoding the token to inspect its claims. Common issues include expired tokens (check the exp claim), incorrect audience (aud mismatch), missing scopes, and algorithm confusion attacks. Our decoder parses all three sections — header, payload, and signature — instantly, colour-coding claim types for fast visual scanning. For encoding credentials, use the Base64 Tool. Generate secure signing secrets with the Password Generator. Test API endpoints with the API Request Builder. Explore all tools on the homepage.