If the task is to protect data from human-in-the-middle (MITM), then the most effective way is to use the Secure Sockets Layer (SSL). To do this, you will need to acquire a private key, and send a certificate (public key) to the client. There is no point in listing the implementation details here - everything is encapsulated inside the HTTPS application-level protocol. Therefore, to use this technology, it is enough to make sure that your hoster supports requests via the HTTPS protocol.
A simpler option (if real-time protection against MITM is not required, but there is some small amount of transmitted traffic that we would like to protect), then there is no solution. At least safe. No, for the reason that any information encrypted on the client’s side (any cryptographic algorithm, its keys, etc.) is in the public domain — its encryption algorithm is known a priori by anyone who knows how to use the F12 key (and the like). However, the method voiced in paragraph 1, open cryptography, remains valid. But in this case, again, the client will first need to send the public key from the server, which is already implemented automatically at the SSL / TLS level - such a cipher can be "unlocked" either by the server or by the software that managed to access the information before using to her public key.
PS about
"The bottom line is that it would be impossible to replace the ID transmitted by the visitor. For this, I want to encrypt it."
.. then just take it for granted that all data sent by the client, with a probability close to one, will be changed by the interceptor. So just implement secure server-side logic that does not trust the client.
