What Is a JWT (JSON Web Token)?
A JWT, or JSON Web Token, is a compact, self-contained token used to securely pass identity and permission information between systems. It packs data — such as who a user is and when the token expires — into a signed string of three parts separated by dots. Because the signature lets any server verify the token without a database lookup, JWTs enable stateless authentication: a user logs in once, receives a token, and includes it with each request to prove who they are.
- Stands for
- JSON Web Token, an open standard defined in RFC 7519 (IETF)
- Structure
- Three Base64URL parts — header, payload, signature — joined by dots
- Signed, not secret
- The signature verifies integrity; the payload is encoded, not encrypted
- Common use
- Stateless authentication in APIs and single-page apps
- Caution
- Never store sensitive data in the payload; anyone can decode it (Auth0 docs)
What a JWT actually is #
A JWT, pronounced 'jot,' is a small package of information that one system can hand to another as proof of identity or permission. It is a string that looks like gibberish — three chunks of letters and numbers separated by dots — but each chunk holds structured data. The middle chunk, the payload, might say 'this user is customer 42, they are an admin, and this token expires at noon.' The clever part is the signature: the server that issued the token signs it with a secret, and any server that knows how to check that signature can trust the token's contents without contacting a database. That property makes JWTs popular for modern web applications and APIs, where a user logs in once and then presents the token on every subsequent request. JWTs are an open standard, so tools in every programming language can create and read them. If your business runs a web app with user accounts, our /services/web-app-development team likely uses tokens like these to keep logins fast and secure.
The three parts of a JWT #
A JWT is three Base64URL-encoded parts joined by dots: a header describing the algorithm, a payload of claims, and a signature. Decoded, the first two parts are just readable JSON.
// A raw JWT (shortened): header.payload.signature
eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiI0MiJ9.dBjftJ...
// Decoded header:
{ "alg": "HS256", "typ": "JWT" }
// Decoded payload (claims):
{
"sub": "42",
"name": "Alex",
"role": "admin",
"exp": 1799999999
}How JWTs enable stateless login #
Traditional logins are stateful: when you sign in, the server stores a session record and hands your browser a session ID; on every request it looks that ID up to remember who you are. JWTs flip this around. After you log in, the server builds a token containing your identity and signs it, then sends it to your browser or app. On each following request you send the token back, and the server simply verifies the signature and reads the identity straight from the token — no database lookup required. This is called stateless authentication, and its appeal is scale: any server in a cluster can validate the token on its own, so you can add servers without sharing session storage between them. That makes JWTs a natural fit for APIs and applications spread across multiple machines. The tradeoff is that a valid token is trusted until it expires, which shapes how you handle logout and revocation. Our /services/web-app-development team weighs these tradeoffs when choosing how your app keeps users signed in.
Signed vs encrypted: a key distinction #
The single most misunderstood fact about JWTs is that a standard one is signed, not encrypted. Signing guarantees integrity: if anyone alters the payload, the signature no longer matches and the server rejects the token. But signing does not hide the contents. The payload is only Base64URL-encoded, which anyone can decode in seconds using a free online tool — it is not secret at all. This has a critical consequence: you must never put sensitive information such as passwords, full credit-card numbers, or private personal data in a JWT payload, because it is effectively public to whoever holds the token. Store only non-sensitive identity claims like a user ID, role, and expiry. If you genuinely need to conceal the contents, a separate encrypted variant exists, but most systems simply keep secrets out of the token. Misunderstanding this leads to real data leaks. Our /services/website-security team reviews how tokens are built so private data never rides along inside them where it does not belong.
JWTs vs sessions and cookies #
Choosing between JWTs and traditional server sessions is a genuine design decision with tradeoffs on both sides, and anyone claiming one is always right is oversimplifying. Server sessions store state centrally, which makes logging a user out instant — you just delete their session — but requires shared storage across servers. JWTs store state in the token itself, which scales effortlessly across many servers and suits APIs, but makes immediate revocation harder because a signed token stays valid until it expires. Cookies and JWTs are not opposites; a JWT can be delivered inside a secure cookie, combining the token model with the browser's built-in protections. For a small brochure website, none of this matters. For a web app with accounts, an internal tool, or an API serving a mobile app, the choice affects security and scalability meaningfully. There is no universal winner. Our /services/web-app-development team picks the approach that fits how your application is actually built and used, rather than following whichever pattern is currently fashionable.
Where JWTs are used #
JWTs quietly power a large share of modern software. Single-page applications built with frameworks like React or Vue commonly use them to keep a user logged in as they navigate. APIs that serve mobile apps rely on JWTs so each request carries proof of identity without a session lookup. They also appear inside OpenID Connect, the identity layer over OAuth, where the 'ID token' that proves who you are is itself a JWT. Microservice architectures pass JWTs between internal services so each can verify a request came from an authenticated user. Even many 'Sign in with Google' flows hand your app a JWT describing the signed-in user. In short, if you use web apps, mobile apps, or social logins, JWTs are working on your behalf constantly. For a business, the practical takeaway is that your app's login and your API integrations probably depend on tokens like these behaving correctly. Our /services/api-crm-integrations team makes sure the tokens flowing between your connected systems are issued, validated, and refreshed the way each service expects.
Common JWT security mistakes #
JWTs are safe only when handled correctly, and a handful of mistakes cause most incidents. Putting sensitive data in the payload is the classic error, since the payload is readable by anyone. Another is accepting a token's own claim about which algorithm to use, which historically let attackers slip through with the 'none' algorithm or a downgraded signature; servers should pin the expected algorithm. Storing tokens in browser localStorage exposes them to cross-site scripting attacks, so a secure, HttpOnly cookie is often safer. Setting expiry times too long means a stolen token stays useful for hours or days, while never planning for revocation leaves no way to force a compromised token out early. Finally, failing to verify the signature at all — surprisingly common in rushed code — makes the whole scheme worthless. Each of these has a known fix. Our /services/website-security team reviews token handling against these exact pitfalls, because a login system is only as trustworthy as the least careful line of code that checks a token.
Should your business use JWTs? #
For most small businesses, JWTs are an implementation detail your developers choose, not something you request by name — and that is fine. If your site is a brochure or a standard WordPress install, sessions and cookies handle logins perfectly well and JWTs add needless complexity. JWTs earn their place when you build a custom web app, a mobile app backed by an API, or a system spread across multiple servers, where stateless verification genuinely simplifies scaling. The right question to ask a developer is not 'are we using JWTs' but 'how do users stay logged in, and how do we revoke access if a token is stolen.' A good answer covers expiry, secure storage, and a revocation plan. What matters to you is that logins are both convenient and secure, whichever mechanism delivers that. Our /services/web-app-development team recommends the simplest approach that meets your security needs, and a /free-website-audit can flag whether an existing app handles its tokens safely before a problem surfaces.
Token expiry and refresh #
Expiry is what keeps JWTs from becoming permanent skeleton keys. Because a signed token is trusted until it expires, tokens are deliberately short-lived — often 15 minutes to an hour — so a stolen one is useful only briefly. But forcing users to log in again every hour would be miserable, so systems pair a short-lived access token with a longer-lived refresh token. The access token proves identity on each request; when it expires, the app quietly presents the refresh token to get a fresh access token without bothering the user. Refresh tokens are stored more carefully and can be revoked, which restores the ability to cut off a compromised session that a bare access token lacks. Tuning these lifetimes balances convenience against risk: shorter access tokens are safer but refresh more often. Getting this balance right is central to a secure, pleasant login experience. Our /services/web-app-development team configures expiry and refresh so your users stay signed in comfortably while stolen tokens expire fast enough to limit any damage.
FAQ
How do you pronounce JWT?
It is commonly pronounced 'jot,' as the JSON Web Token specification itself suggests, though many developers simply spell out the letters J-W-T. Both are understood. The word 'jot' also nicely captures the idea of a small, quickly readable note carrying a bit of trusted information from one system to another.
Is data in a JWT secret?
No. A standard JWT is signed, not encrypted, so its payload is only encoded and anyone holding the token can decode and read it in seconds. Never place passwords or sensitive personal data inside. Store only non-sensitive claims like a user ID, role, and expiry time that you would not mind being visible.
What happens when a JWT expires?
The server rejects it, and the user must obtain a new token. To avoid constant re-logins, apps usually pair a short-lived access token with a longer-lived refresh token that silently fetches a new access token in the background. Short expiry limits how long a stolen token can be misused, which is the security point.
Can a JWT be revoked before it expires?
Not easily, which is a known tradeoff. Because servers trust a signed token without a lookup, there is no built-in list to invalidate one early. Teams work around this with short expiry times, a revocation list checked on sensitive actions, or revocable refresh tokens. If instant logout is critical, server sessions may suit you better.
Are JWTs better than session cookies?
Neither is universally better. JWTs scale easily across many servers and suit APIs and mobile apps because they need no central session store. Session cookies allow instant revocation and are simpler for traditional websites. The right choice depends on your application's architecture and security needs, not on which approach sounds more modern.
Where should JWTs be stored in a browser?
A secure, HttpOnly cookie is generally safer than browser localStorage, because HttpOnly cookies cannot be read by JavaScript and so resist cross-site scripting theft. localStorage is convenient but exposes the token to any injected script. The right storage choice depends on your app, and a security review should confirm it protects against common attacks.
How Local Web Advisor checks this for you
Is your own website getting security & compliance right?
Our free AI audit scans your site and tells you — in plain English — exactly what to fix for security & compliance and seven other areas, with the business impact and the fix for each. No login needed to start.
Run my free website audit →Was this helpful?