HTTP is in no way encrypted. Any network sniffer that can sniff packets between an HTTP client and a server (most network adapters support promiscuous mode for this purpose) can view HTTP data.
HTTPS data, on the other hand, is HTTP data that is encrypted using SSL / TLS. SSL / TLS encrypts outgoing data before it enters the network, and decrypts incoming data after leaving the network. There is no plain text on the network, so it doesn’t matter if third-party packages sniff. Without encryption keys, sniffing data is garbage. During SSL / TLS communication, the client and server negotiate encryption keys, certificates, etc. With each other, before any application exchange data can be exchanged. This ensures that encrypted data sent by the client can only be decrypted by the server and vice versa.
The only way to intercept and extract plaintext from an encrypted SSL / TLS connection is the man-in-the-middle attack. This means that the SSL client connects to MITM, and then MITM connects to the SSL server and combines the data between them. MITM needs access to the network on which the client or server is running, and should be able to redirect the client connection to itself, and not to the server. But if possible, MITM can negotiate its own SSL / TLS connections with both parties in order to have all the necessary encryption information. He can then receive and decrypt the data sent by the SSL client using the encryption keys that he agreed with the SSL client, and then re-encrypt and transfer this data to the SSL server using the encryption keys negotiated with the SSL server. And vice versa. The SSL client and the SSL server will not know that they are talking with MITM, and not with each other if you are not using certificates, so the SSL client and SSL server can verify each other's identifiers during the initial handshake. SSL / TLS does not require certificates, but they are good to use if you have them.