Guide

Where to store a JWT: localStorage vs cookie

Where you store a JWT in the browser changes your XSS and CSRF risk.

localStorage: easy to use but readable by JavaScript, so it's vulnerable to XSS — an injected script can steal the token.
HttpOnly cookie: JavaScript can't read it, so it resists XSS, but it's sent automatically, so you need CSRF defense (SameSite / CSRF token).
Recommended: keep the refresh token in an HttpOnly, Secure, SameSite cookie and the access token briefly in memory (a variable).
Wherever you store it, HTTPS is a must; keep token lifetimes short and never put sensitive data in the payload.

Try decoding a token yourselfJust paste and the header, payload and claims unfold instantly.

Open the decoder

Related

A JWT (JSON Web Token) is a small, signed JSON token format for securely passing information between parties.

The three-part JWT structure

Every JWT consists of header.payload.signature, and each part is base64url encoded.

JWT security checklist

A short checklist of the key principles for using JWT safely.

JWT vs session authentication

The difference between token (JWT) auth and server session (cookie) auth, and when to use each.

Common JWT errors and fixes

The errors you meet most often when working with JWT, with their causes and fixes.

Access tokens and refresh tokens

The role of the short-lived access token and the refresh token that renews it.

JWS vs JWE (signed vs encrypted)

A JWT is usually a signed JWS; to hide the content you use an encrypted JWE. Here is the difference.

Custom claims (public vs private)

Beyond registered claims (iss, exp, ...), the kinds of claims you define yourself and how to avoid collisions.

JWT in OAuth 2.0 & OpenID Connect

How JWT is used in OAuth 2.0 and OpenID Connect.