Just like any other 'tokens', JSON Web Tokens (JWT) is a form of secret that's used for authentication (who you are) and authorization (what you can do). Similarly, a SessionID can also be used for authentication and authorization.
The key difference is JWTs are self-contained, while SessionIDs are not.
A JWT contains three parts:
<header, payload, signature>. I won't go into details but basically
payload contains who the user is and what s/he can do, and
signature verifies the token is valid. So when server receives a JWT, it can already retrieve all the information directly from the token, i.e., self-contained.
In contrast, a SessionID is merely a long, unique, random string. By itself there is no user information. When server receives a SessionID, it needs to do extra work to find out which user it belongs to, and then what s/he can do. This extra work often requires a database lookup.
Another way to look at it, is JWT is a driver's license (proves who a user is, and what s/he can do, drive a car), while SessionID is a credit card (simply a random number that links to a bank account, that each transaction requires a card reader to talk to bank).
The internet has been doing just fine with SessionIDs for many years. Even today, the majority of websites still use SessionIDs. However, in back-end systems that need to handle extremely high volume of http requests, the need to do a database lookup for every single SessionID included in each request can be expensive as it increases latency and reduces throughput.
This is not an issue for JWT as it's all self-contained. The server can simply read the JSON payload from the JWT, without making any database lookups.
First of all, JWT requires you to properly store and distribute private / public keys that are used for signing and verifying JWTs. And key management is hard to be done right, especially in a large-scale distributed system.
Secondly, since JWTs are self-contained, there is no way to revoke a JWT token. Unlike a SessionID that you can simply delete from the database and thus remove its link to a user, JWTs are not stored in database so once it's created it's valid until expired. It's like credit cards are easy to be replaced, but driver licenses, once issued, are valid anywhere.
Last but not least, because JWTs cannot be revoked, we tend to give them shorter expiration time, which requires users to re-fetch a new JWT more often. There is an option to use refresh tokens but that adds more complexity on the client side, comparing to SessionIDs where the client only needs to store a simple string.
Probably not. SessionIDs should work just fine :)