Is a decoded JWT a security review?

No. It is only a readable view. Verification needs cryptographic checks with the right keys.

Can I paste production tokens into the browser tool?

Avoid real secrets. Use test tokens or redacted samples you are allowed to share.

What about refresh tokens?

Treat them as high-value secrets. Many are opaque and not meant to be decoded in a generic JWT UI.

What is Base64url in JWTs?

JWT segments use a URL-safe Base64 alphabet (often called Base64url) with different padding rules than standard Base64.

JWT Explained - What is a JSON Web Token & How Does It Work?

What a JWT is

A JSON Web Token (JWT) is a compact, URL-safe way to pass claims between parties. The familiar form is three dot-separated Base64url-encoded pieces: header, payload, and signature (or encryption metadata for JWE). The header and payload are JSON once decoded, which is why a decoder feels like “pretty-printing a secret string.”

Decoding the middle segment does not prove the token is legitimate. Signature verification (using the issuer’s keys and the exact bytes that were signed) must happen in a trusted environment—typically your API gateway or backend. Our JWT decoder is for debugging and learning, not for authorization decisions in production.

When teams reach for JWTs

Stateless session patterns, mobile clients, and microservices often carry JWTs as bearer tokens. The payload might include sub, exp, and custom claims. Keep payloads small, rotate keys, and prefer short lifetimes with refresh strategies that match your threat model.

If you are comparing encodings, remember JWT segments use Base64url—a close cousin to standard Base64. For plain text and images, our Base64 tools cover the classic alphabet.

JWT structure: header, payload, signature (in depth)

The header often names alg and type. The payload carries public claims. The signature (or MAC) covers base64url(header) + "." + base64url(payload) bytes. Library APIs hide this, but the bytes matter when keys rotate or algorithms are negotiated.

How JWT signing works (HS256 vs RS256)

HS256 (HMAC) uses a shared secret. If any client that should not mint tokens can read that secret, your trust model is broken. RS256/ES256 use asymmetric keys: the issuer signs with a private key; verifiers use a public key from JWKS. Prefer asymmetric public-key flows for multi-tenant and browser-exposed client IDs.

JWT vs session cookies

Server-side sessions are opaque IDs with state on the server; JWTs can carry state in the token, which removes some lookups but complicates logout and key rotation. Neither is "more secure" by default— threat models differ.

JWT security best practices

Short exp and explicit refresh/rotation stories
Validate iss, aud, and clock skew in server code
HTTPS only; do not log bearer tokens; prefer secure storage for clients that need persistence
Key rotation and JWKS published by the identity provider; pin libraries with good algorithms support

Common JWT vulnerabilities to avoid

Accepting alg: "none", using weak shared secrets, confusing audiences, and skipping expiry checks are recurring bug classes. Always verify in your service using the same libraries you run in production, not a visual decoder in a web tab.

JWT — FAQ

Is a decoded JWT a security review?: No. It is only a readable view. Verification needs cryptographic checks with the right keys.
Can I paste production tokens into the browser tool?: Avoid real secrets. Use test tokens or redacted samples you are allowed to share.
What about refresh tokens?: Treat them as high-value secrets. Many are opaque and not meant to be decoded in a generic JWT UI.
What is Base64url in JWTs?: JWT segments use a URL-safe Base64 alphabet (often called Base64url) with different padding rules than standard Base64.
Where should signatures be verified?: On your server or API gateway using the issuer’s keys and the exact bytes that were signed—not in a public decoder.

JWT explained — what is a JSON Web token & how it works