- A single VoIP call uses only a small fraction of typical UK broadband capacity, so headline speed is rarely the limiting factor for one or two lines.
- VoIP needs both upload and download capacity, and because upload is usually the smaller figure on UK connections, it is more often the constraint.
- The codec used to compress the voice determines bandwidth per call, with compressed codecs needing less than uncompressed wideband ones.
- Ofcom reports UK average broadband speeds have risen sharply with fibre rollout, leaving most connections with ample capacity for voice.
- Latency, jitter and packet loss affect call quality more than raw speed once a baseline of a few hundred kilobits per second per call is met.
A single VoIP call typically needs under 100 kilobits per second in each direction, so almost any UK broadband can carry it. Upload capacity and connection stability matter more than headline download speed.
Last reviewed: June 2026
Why VoIP needs less speed than people assume
A common worry when switching a phone line to VoIP is that the broadband will not be fast enough. In practice, voice is one of the lightest things a connection ever carries. A telephone conversation contains a narrow band of audio frequencies, and the codecs that turn that audio into data packets compress it efficiently. The result is that a single call occupies a tiny slice of capacity compared with video streaming, large downloads or cloud backups. Even a modest connection from the era before fibre can usually carry several simultaneous calls without strain.
The reason call quality problems still occur is that bandwidth is only part of the story. Voice is real-time and unforgiving of delay, so the steadiness of the connection matters as much as its width. A fast connection that suffers spikes of latency or loses occasional packets can deliver worse calls than a slower but stable one. This is why measuring whether a connection can handle VoIP means looking beyond the headline speed to how consistently the line behaves under load.
Bandwidth per call by codec
The amount of data a call uses depends on the codec. A codec is the method used to encode and compress voice. The widely used G.711 codec sends uncompressed audio and produces good quality but uses the most bandwidth, in the region of 80 to 90 kilobits per second of payload per direction once packet overhead is included. The G.729 codec compresses the audio heavily and cuts that to roughly a quarter, at the cost of slightly reduced fidelity. Wideband codecs such as G.722 deliver clearer, more natural sound and use bandwidth broadly comparable to G.711, trading capacity for quality.
These figures are per call and per direction, so a household making one call at a time needs only a small reserve. The picture changes for offices running many concurrent calls, where the totals add up. A small business with several agents on calls simultaneously should multiply the per-call figure by the number of lines and add headroom. Even then, the totals remain modest against a modern fibre connection. The table below sets out indicative requirements.
It helps to understand why the payload figure is not the whole story. The raw voice data a codec produces is wrapped in several layers of packet headers before it travels across the network, and for short, frequent voice packets that overhead is proportionally large. This is the reason the usable bandwidth per call sits above the bare codec rate, and why doubling the codec efficiency does not halve the total demand. The size and frequency of packets can be tuned, with larger packets carrying more audio and reducing overhead at the cost of slightly more delay if one is lost, but the defaults most systems use are a sensible balance. The Opus codec behaves differently again, because it can vary its bitrate dynamically, dropping its demand when the connection is constrained and raising quality when there is room, which is why it has become common in modern software clients.
VoIP bandwidth requirements by codec and concurrent calls
The following table gives indicative bandwidth needs per direction, combining the codec payload with typical packet overhead. Figures are approximate and intended to show the scale rather than to serve as exact engineering values.
| Codec | Per call (each direction) | 3 concurrent calls | Quality notes |
|---|---|---|---|
| G.711 (uncompressed) | around 80-90 kbps | around 240-270 kbps | Clear standard quality |
| G.729 (compressed) | around 25-35 kbps | around 75-105 kbps | Lighter, slightly reduced fidelity |
| G.722 (wideband) | around 80-95 kbps | around 240-285 kbps | Fuller, more natural sound |
| Opus (variable) | around 30-90 kbps | around 90-270 kbps | Adapts to available bandwidth |
Why upload speed is the figure that matters
Most attention on broadband packages goes to download speed, the figure quoted in advertising. For VoIP, the upload speed is frequently the more important number, and it is often overlooked. A call sends voice in both directions at once, so the connection must reliably push outgoing audio up the line at the same time as receiving the other party's audio. On many UK connections, particularly older copper-based ones, upload capacity is a small fraction of download capacity, which means the upstream path can become congested long before the download path does.
The practical effect is that VoIP problems often trace back to something saturating the upload, such as a cloud backup, a video call uploading footage or a large file being sent. When the upstream link fills, voice packets queue behind the bulk traffic and arrive late, producing one-way audio or broken speech. This is why VoIP guidance places so much emphasis on protecting upload headroom, and why a connection should be assessed on its upload capacity and stability rather than its download speed alone.
What happens at low bandwidth and how to test
When a connection cannot give a call the capacity it needs, the symptoms are distinctive. Audio breaks into fragments, words drop out, there may be a robotic or underwater quality, and in severe cases the call drops entirely. These effects come from packet loss and jitter, the variation in packet arrival times, rather than from a shortage of average bandwidth. A connection that is fast on paper can still produce these problems if it buffers traffic poorly under load or if another device is monopolising the link.
Testing whether a connection can handle VoIP starts with measuring the genuine upload and download speeds, not just the advertised figures, ideally while nothing else is using the line. Comparing that against the per-call requirements in the table shows whether there is enough raw capacity. The second test matters more: checking latency, jitter and packet loss, which several connection-quality tools report. A useful real-world check is to make test calls while deliberately running a large upload or download, since this reveals whether the connection holds up when busy. If quality collapses under load but is fine when idle, the issue is prioritisation rather than speed, and router QoS settings are the place to look.
It is worth putting these requirements in the context of how UK connections have changed. Ofcom reports that average UK broadband speeds have risen substantially as fibre coverage has grown, which means raw capacity is rarely the obstacle it once was, and the analogue network that voice traditionally rode on is itself being retired in favour of IP services under Openreach's published migration, scheduled to complete in 2027. The practical consequence is that the binding constraint has shifted away from headline speed and toward the quieter qualities of a connection. Jitter, the variation in how packets are spaced as they arrive, is smoothed by a small buffer at the receiving end, but only up to a point, beyond which audio is discarded. Latency, the one-way delay, becomes noticeable in conversation when it grows large enough that the two parties begin talking over each other. Because these effects are invisible on a simple speed test, a connection should be judged on a short period of monitoring under realistic conditions rather than a single instantaneous number, and where a router supports it, prioritising voice traffic ahead of bulk transfers is usually the single most effective fix.
Frequently Asked Questions
How much broadband speed do I need for VoIP?
A single VoIP call typically needs under 100 kilobits per second in each direction, far less than most UK connections provide. The figure rises with the number of simultaneous calls and the codec used, but even a small office running several lines needs only a few hundred kilobits per second. Stability matters more than raw speed once that baseline is met.
Does VoIP need upload or download speed?
It needs both, because a call sends and receives audio at the same time. Upload is usually the more important figure, since UK connections typically have far less upload than download capacity, so the upstream path congests first. Protecting upload headroom is the key to reliable calls.
Can ADSL support VoIP?
Yes, ADSL can carry VoIP because a call uses so little bandwidth. The constraint on older ADSL lines is the limited upload speed, which can be saturated by other activity and may struggle with several simultaneous calls. For a single line on an otherwise quiet connection, ADSL is generally sufficient.
How do I test if my broadband can handle VoIP?
Measure your real upload and download speeds while nothing else is using the line, then compare them with the per-call requirements. More importantly, check latency, jitter and packet loss using a connection-quality tool, and make test calls while running a large upload or download. If quality only fails under load, the issue is prioritisation rather than speed.
What happens to VoIP call quality at low broadband speeds?
When capacity runs short, audio breaks into fragments, words drop out, and the call can take on a robotic quality before dropping entirely. These effects come mainly from packet loss and jitter rather than from average bandwidth. They often appear only when another device saturates the connection, which points to a prioritisation problem rather than a slow line.
