| Algorithm | Type | Key | Strength | Best for |
|---|---|---|---|---|
| HS256 | Symmetric HMAC | Shared secret | 128-bit | Server-to-server, internal APIs |
| HS384 | Symmetric HMAC | Shared secret | 192-bit | Higher-assurance internal tokens |
| HS512 | Symmetric HMAC | Shared secret | 256-bit | Longest HMAC — overkill for most uses |
| RS256 | Asymmetric RSA | Private + Public | 2048-bit key | Public key distribution (OAuth 2, OIDC) |
| RS384 | Asymmetric RSA | Private + Public | 2048-bit key | Legacy compliance |
| RS512 | Asymmetric RSA | Private + Public | 2048-bit key | High-security public-key scenarios |
| ES256 | Asymmetric ECDSA | EC P-256 key pair | 128-bit equiv. | Mobile apps, shorter tokens |
| ES384 | Asymmetric ECDSA | EC P-384 key pair | 192-bit equiv. | Financial services, high-security APIs |
| none | Unsecured | None | ⚠️ No security | Testing only — never in production |
- HS256 — default for server-side APIs where you control all parties
- RS256 — use when third parties need to verify tokens without the signing secret (e.g. OIDC)
- ES256 — same as RS256 but smaller signatures; prefer for mobile/IoT bandwidth
- HS384/HS512 — rarely needed; SHA-256 collision resistance is sufficient for JWTs
Understanding Authentication Tokens
JSON Web Tokens (JWT) are lightweight, cryptographically signed tokens primarily used to authorize requests against modern REST APIs and microservices. Because the server can mathematically verify a JWT's signature locally, it rarely needs to query a database to authenticate a request.
SAML (Security Assertion Markup Language) is a robust, XML-based standard primarily used for Enterprise Single Sign-On (SSO) systems. It requires heavier back-and-forth parsing and is highly secure, but JWT's JSON format makes it significantly easier to transmit across HTTP headers in web and mobile applications.
The Authorization Code flow securely exchanges a temporary code for an Access Token (JWT).
graph TD
User([Resource Owner])
Client[Client App]
AuthServer[(Auth Server)]
API[(API Server)]
User -->|1. Clicks Login| Client
Client -->|2. Requests Auth Code| AuthServer
AuthServer -.->|3. Prompts for Consent| User
User -.->|4. Grants Consent| AuthServer
AuthServer -->|5. Returns Auth Code| Client
Client -->|6. Exchanges Code for Tokens| AuthServer
AuthServer -->|7. Returns Access Token JWT| Client
Client -->|8. API Call with Bearer JWT| API
API -->|9. Validates JWT & Returns Data| Client
JWT Token Structure
A JSON Web Token consists of three parts separated by dots, each Base64Url encoded.
graph LR
JWT[Encoded JWT Token]
Header[Header: Algorithm & Type]
Payload[Payload: Data & Claims]
Signature[Signature: Verification]
JWT -->|Part 1| Header
JWT -->|Part 2| Payload
JWT -->|Part 3| Signature
style Header fill:#df3852,stroke:#fff,stroke-width:2px,color:#fff
style Payload fill:#d72199,stroke:#fff,stroke-width:2px,color:#fff
style Signature fill:#4d7dff,stroke:#fff,stroke-width:2px,color:#fff
Frequently Asked Questions
Is my JWT token safe when I paste it here?
Yes. All JWT decoding and signature verification happens entirely in your browser using the Web Crypto API. Your tokens, signing keys, and payloads never leave your device or touch our servers.
What JWT signing algorithms are supported?
The debugger supports HMAC-based algorithms (HS256, HS384, HS512) for symmetric verification and RS256, ES256 for asymmetric key pairs. You can verify the signature by providing your secret key or public key directly in the tool.
How do I check if a JWT token has expired?
Paste your JWT into the debugger and switch to the Payload view. The tool automatically detects the exp (expiration) claim and shows a live countdown of how long until the token expires, or how long ago it expired.
JWT Structure
A JSON Web Token consists of three Base64URL-encoded parts separated by dots: Header.Payload.Signature. The header specifies the algorithm (e.g., HS256, RS256). The payload contains claims — registered (iss, sub, exp, iat), public, or private. The signature verifies the token hasn't been tampered with.
Decoding Process
Decoding is performed entirely in your browser using atob() with URL-safe Base64 substitutions. No data is sent to any server. The header and payload can always be decoded; signature verification requires the secret key.
Signature Verification
For HS256/HS384/HS512 (HMAC-based), the browser's Web Crypto API recomputes the signature using your provided secret. If it matches the token's signature, the token is valid and untampered. For RS256/RS384/RS512, an RSA public key is needed instead.
Common Claims
exp: expiration time (Unix timestamp). iat: issued-at time. nbf: not-before time. sub: subject (usually user ID). iss: issuer. aud: audience. This tool highlights expired tokens automatically.
Security Note
Never share JWTs containing sensitive data in public forums or logs. This debugger runs entirely client-side — your token and secret never leave your browser.
Personalised history, favourites & saved settings — coming soon for logged-in users