The first part was already described quite detailed by mti2935: with an vpn you add a step of going to the vpn which is encrypted.
With no VPN:
- For encrypted traffic (like HTTPS) the ISP can view to which domain you are connecting to
- For plaintext traffic (like HTTP) the ISP can view to which domain you are connecting to, as well as the whole contents sent and received.
With an VPN, you add a prior step of sending the information encrypted to the vpn, so:
- The ISP can view that you are connecting to the vpn service
- For encrypted traffic (like HTTPS) the VPN provider can view to which domain you are connecting to
- For plaintext traffic (like HTTP) the VPN provider can view to which domain you are connecting to, as well as the whole contents sent and received.
Since the communication with the vpn is encrypted (and assuming you connected with the real vpn site when setting it up), there's no privacy risk regarding the ISP.
However, you should be aware that you are replacing that the ISP can view certain things with the vpn service being able to view them.
Either using a VPN or not, you should strive to connect using encrypted protocols, for web pages that means using HTTPS if that's available.
Isn't it possible to de-encrypt HTTPS data if we have access to the target server? As I am supposing there should be a de-encryption formula in the server.
AS for this second question, I slightly disagree with mti2935, depending on what you meant to ask.
Obviously, the party that owns the server is able to view what you send it in https. But, if we are talking about an ISP getting the traffic today, and then two months later decrypting that old data they stored, we need to differentiate between two types of ciphers.
Traditionally, what I just described could be done. Anyone having a copy of the server private key could decrypt what was being sent. Intelligence agencies around the world copied huge amounts of data that was transitting, hoping they might be able to decrypt it in the future by getting hold of the private key used.
As a way to make the process more robust, a number of ciphers were added, with the property that they offer what is being called "Perfect Forward Security" (PFS). What they provide is that an attacker which followed the above steps would still not be able to decrypt it.
They manage to do this by encrypting the actual performing a Diffie-Hellman key exchange which lets both client and server derive the same session key, without it actually being explicitly said, or be guessable by an attacker that was viewing everything they exchanged.
The actual cipher you are using when communicating will depend on what is supported by the server and the client. They will negotiate which cipher to use. You can expect that most servers (and clients) do support PFS nowadays, and that it will generally be preferred to non-PFS ciphers.