Everyday use
Does a VPN Drain Your Phone Battery? Where the Power Actually Goes (2026)
Yes, a little — and almost none of it is encryption. Every phone shipped in the last decade has dedicated instructions for the ciphers a tunnel uses, so the cryptography costs a rounding error. The power goes somewhere far less glamorous: keeping the radio awake.
The radio is the expensive part
A mobile radio is not simply on or off. Sending anything wakes it into a high-power state, and it stays there for seconds afterwards before stepping down. A handful of bytes therefore costs roughly what a much larger transfer costs, because the tail dominates. Anything that produces small packets at regular intervals is expensive out of all proportion to the data it moves.
A tunnel does exactly that. To stay usable it has to keep its path alive, which means periodic keepalive traffic even while you are doing nothing at all.
Why keepalives exist at all
Carrier networks put subscribers behind large-scale address translation, and every translation table entry has a timeout — commonly between thirty seconds and a few minutes for UDP. When the entry expires, return traffic has nowhere to go and the connection is silently dead until something re-establishes it. Keepalives keep the entry alive, and their interval is a direct trade: shorter means faster reconnects and more radio wakeups, longer means better battery life and occasional stalls after idle periods.
What actually changes consumption
- Always-on versus on-demand. Always-on keeps the tunnel alive around the clock, including hours when the screen never turns on. This is the single largest factor.
- Keepalive interval. Where the client exposes it, longer intervals cost less power. Where it does not, this is decided for you.
- Signal quality. A weak signal makes every transmission cost more. The same tunnel on one bar and on full bars are not comparable measurements.
- Protocol behaviour under loss. A tunnel that retransmits aggressively on a poor link keeps the radio busy longer than one that tolerates loss.
- Split routing. Sends less traffic through the tunnel, but does not let the radio sleep any more than before — the savings are smaller than people expect. See split tunnelling.
Encryption, protocol choice and server distance are not on this list in any meaningful way. Distance changes latency, not power; the cipher is handled in hardware.
Measuring it on your own phone
- 1Charge to full, then use the phone normally for a full day with the tunnel off. Note the battery percentage at a fixed hour.
- 2Repeat the next day with the tunnel always on, at the same hour, with a comparable pattern of use.
- 3Read the per-app breakdown: Settings → Battery on both iOS and Android list the VPN client separately.
- 4Compare two days, not two hours. Standby is where the difference accumulates, and an hour of active use tells you nothing about it.
- 5If the client appears near the top of the list, look at its always-on and keepalive settings before changing anything else.
For most people on a modern phone the honest expectation is a few percent of daily drain, indistinguishable from a day with slightly worse signal. If you are seeing far more than that, the cause is usually always-on plus a short keepalive on a weak mobile signal — a combination worth changing, and one you can change.
FAQ
Does turning the VPN off overnight help?
Yes, and it is the most effective single change. Standby hours are where an always-on tunnel spends its power, because nothing else is waking the radio during them.
Which protocol uses the least battery?
The differences between modern protocols are small compared with how often the client wakes the radio. A protocol that survives longer idle periods without keepalives will beat a faster one that needs them every thirty seconds.
Does a nearer server save power?
Not in any measurable way. A closer exit lowers latency; the radio wakes just as often either way.
My phone gets warm with the VPN on. Is that the encryption?
Almost certainly not. Sustained warmth points at the radio working hard on a weak signal, or at an application retrying in a loop behind the tunnel. Check signal strength and per-app usage before blaming the cipher.
Did this help?
Nothing follows from the answer; only we see it.