TrustComponent
Sign inGet started

Free developer tools

JWT Decoder & Debugger.

Decode a token, edit header and payload with live re-signing, and verify signatures — without the token ever leaving your browser.

Developed and hosted in the EU
JWT Debugger
Decode · edit · verify
Runs entirely in your browser
Header Payload Signature

Signature

Paste a token to inspect and verify its signature.

Decoding, signing and verification run entirely in your browser — nothing is transmitted or stored. Still: treat production JWTs like passwords.

What is a JWT?

A JSON Web Token (RFC 7519) is a compact, self-contained way to transmit claims between parties — most commonly, proof of who a user is and what they may do. Because the token is signed, an API can trust its contents without a database lookup, which makes JWTs the backbone of stateless authentication, OAuth 2.0, and OpenID Connect.

Three parts, one dot apart

  • Header — metadata: the signing algorithm (alg) and token type.
  • Payload — the claims: registered ones like exp and sub, plus anything the issuer adds.
  • Signature — a MAC or digital signature over the first two parts, proving integrity and origin.

Each part is Base64URL-encoded — encoded, not encrypted. Anyone can read a JWT's contents; only the signature is protected.

Decoding is not verifying

The most common JWT mistake: treating a decoded payload as trustworthy. Decoding requires no key — an attacker can craft any payload they like. Trust comes only from verifying the signature against your secret (HS256) or the issuer's public key (RS256/ES256), and from checking exp, iss and aud. Server-side libraries do this for you — configure an explicit algorithm allow-list.

Keep your tokens safe

  • Never put secrets or personal data in the payload — it is readable by anyone.
  • Keep access-token lifetimes short and rotate with refresh tokens.
  • Send tokens over HTTPS only, and store them out of reach of injected scripts.
  • Reject alg: none and verify against an algorithm allow-list.

Frequently asked questions

Is it safe to paste a JWT into an online decoder?
This debugger runs entirely in your browser — your token is never transmitted, stored, or logged, which you can verify in the network tab of your developer tools. Even so, treat production tokens like passwords: a JWT often grants access to an account or API. Prefer test tokens whenever possible, here or in any other tool.
What is the difference between decoding and verifying a JWT?
Decoding just reads the token: header and payload are Base64URL-encoded, not encrypted, so anyone can decode them. Verifying checks the cryptographic signature against a secret or public key, proving the token was issued by the expected party and has not been tampered with. Never trust a token's claims without verifying its signature.
Can I edit a token and get a valid signature?
Yes — for HMAC algorithms (HS256/384/512), enter the shared secret and the debugger re-signs the token automatically every time you edit the header or payload. For asymmetric algorithms like RS256, signing requires the private key, which you should never paste into a website — so edits leave the old signature in place and it is reported as invalid.
Can I decode a JWT without knowing the secret key?
Yes — decoding needs no key at all, because the header and payload are only Base64URL-encoded. The secret or private key is only needed to create a valid signature, and the secret or public key to verify one.
What are the standard JWT claims?
RFC 7519 defines seven registered claims: iss (issuer), sub (subject), aud (audience), exp (expiration time), nbf (not before), iat (issued at) and jti (unique token ID). All are optional, and applications add their own custom claims — roles, e-mail, scopes — alongside them.
Why is my token marked as expired?
The exp claim holds a Unix timestamp (in seconds); when that moment passes, the token must be rejected. Expired tokens are normal — access tokens are often valid for minutes. Your application should obtain a new token, typically via a refresh token, rather than extending the old one.
What is the difference between HS256 and RS256?
HS256 is symmetric: the same secret signs and verifies, so every verifying service could also forge tokens. RS256 is asymmetric: a private key signs, a shareable public key verifies. Use RS256 (or ES256) whenever tokens cross service boundaries; HS256 is fine when the same service issues and consumes them.
What does alg: none mean, and why is it dangerous?
An unsecured JWT has no signature at all. If a server naively accepts alg: none, an attacker can forge arbitrary tokens. Libraries should be configured with an explicit allow-list of algorithms; this debugger flags such tokens with a warning.
Can this tool decode encrypted JWTs (JWE)?
No. JWE tokens (five Base64URL segments instead of three) are actually encrypted, and reading them requires the decryption key. This tool handles the far more common JWS tokens — the three-segment signed variety.

More free tools

All tools →
UUID Generator

Generate UUIDs (v4, v7 & more) in bulk, with export options.

Open tool
Password Generator

Strong random passwords with configurable length and character sets.

Open tool
Passphrase Generator

Memorable diceware-style passphrases from a 7,776-word list.

Open tool

Free tools from a European software company.

  • Runs in your browser
  • Made & hosted in the EU
  • No account needed
Explore our products Browse resources