Is JWT authentication stateless at the server level or the system level?

It depends on what you mean by system and what kind of state you are talking about. If the client sends a self-contained signed token and the backend verifies it without looking up a session, the authentication process can be stateless on the backend. The client still holds information established by an earlier interaction, so the client and backend together aren't free of state.

That doesn't mean the backend has no data at all. It might still store user records or application data. Saying authentication is stateless is narrower than saying the entire application is stateless.

Think about what another server instance needs to handle the same request. With a shared session database, it can look up the session, but that interaction still depends on backend session state. With a self-contained token, it can validate the supplied token without reconstructing that session history.

That's useful when thinking about replication and testing. You still need the relevant verification keys and any other dependencies the endpoint uses. A JWT alone doesn't guarantee that the whole request can be processed without backend lookups.

There is a practical catch with JWTs: check what the server actually does with them. If it consults a revocation list or session store on every request, authentication depends on server-side state even though the client carries a token.

If it only verifies the token and uses its claims, there's no server-side session lookup in that flow. The token's expiry and the verification keys still matter, so describe those assumptions when comparing designs.

I wouldn't get too hung up on finding one universal label for the whole system. Say the application servers don't keep local sessions, or say authentication doesn't require a backend session store. Those descriptions make the architecture much clearer than just calling everything stateless.