Upload Speed for Remote Work: How Much You Actually Need

T-Mobile publishes a typical upload range for its Amplified and All-In home internet plans, and the range is 12 to 55 Mbps. The download range printed beside it in the same table is 170 to 498 Mbps (network speed and performance metrics, read 28 September 2026). The same page says what the two ends of those ranges are: projections based on "roughly the 25th and 75th percentiles of network tests." So the 12 is not a floor. Roughly a quarter of the underlying tests came in below it, nothing on the page tells you which end your own house lands on, and the spread across the range is more than four to one.

For anyone selling internet service, the first number in that pair is the product. For anyone working from a spare bedroom, the second one decides whether the day goes well. Your camera feed, your screen share, the corporate VPN, the sync client quietly shipping yesterday's files to a bucket somewhere — all of it goes the other way, up a channel that is usually a fraction of the one in the advertisement, and that nobody quotes at you when you sign up.

So the useful question is not whether your plan is fast. It is how much of your day is spent pushing, how much room the upstream has, and how to establish which of those two numbers is actually the smaller one.

What a working day sends upstream, in the vendors' own figures

Microsoft publishes a per-modality table for Teams on its prepare your organization's network page, read 28 September 2026. The column header carries the detail that summaries tend to drop: Bandwidth requirements (bitrate kilobit/s up/down). Upstream is the first figure in each pair, and the pairs are reproduced below as published rather than flattened to one direction.

It is worth pausing on which cells are not matched pairs, because there are only two of them and they sit in the same row. Video in a meeting is the exception: 150 up against 200 down at the minimum, and 2,500 up against 4,000 down at the recommended tier. Every other cell in the table is symmetric. That makes the recommended meeting figure the one number here whose meaning changes when the pair is read backwards, and reading it backwards inflates the upstream you think you need to budget from 2.5 Mbps to 4 Mbps. Take the order from the header.

Google's Meet hardware requirements page, read the same day, is blunter about the asymmetry of the ask. For HD quality, "outbound signals from a participant in all situations must meet a 3.2 Mbps bandwidth requirement," while inbound scales with the number of people on the call: 2.6 Mbps at two participants, 3.2 at five, 4.0 at ten. The SD figures are 1 Mbps outbound, 1 to 2 Mbps inbound.

Two things follow that the round numbers in shopping guides miss.

The first is that these are per-endpoint figures. Microsoft says so directly: the requirements "are based on per-endpoint usage," and a person joining from a laptop and a phone is two endpoints. A household with two people in HD meetings is asking for roughly 6.4 Mbps upstream on Meet's numbers before anything else in the house sends a byte. Add a screen share and a phone that joined for audio, and 10 Mbps of live upstream demand in a two-adult house is ordinary rather than extreme.

The second is that outbound demand does not shrink when the meeting gets bigger. Inbound does scale with attendees, which is why a large all-hands feels heavier. But you are still only one camera. That is why the upstream requirement is flat in Google's table and the downstream one is not, and why a remote worker's problem so rarely looks like the problem a speed test is designed to find.

The federal floor is 20 Mbps up, and 2026 was the year it stayed there

If you have ever wondered where the 20 in "100/20" came from, it is recent. The Commission raised its fixed benchmark to 100 Mbps down and 20 Mbps up in March 2024, calling it "a four-fold increase from the 25/3 Mbps benchmark set by the Commission in 2015" (FCC news release DOC-401205A1).

This year the Commission was asked to go further and said no. The 2026 Section 706 Report, GN Docket No. 25-223, adopted 13 August 2026 and released the following day, puts it in paragraph 16: "We maintain 100/20 Mbps as our benchmark in defining advanced telecommunications capability for fixed broadband. The record unanimously supports a benchmark of at least this speed, and we are not aware of a reason why it should be reduced." Then the part that concerns anyone whose job lives upstream:

Some commenters suggest that we should raise our benchmark to faster speeds or, at minimum, raise the upload speed to a symmetrical 100 Mbps. Such commenters, however, rely almost exclusively on market trends and aspirational standards rather than an analysis of the present use of broadband service.

The Commission agreed instead with USTelecom that raising the bar beyond the 100/20 figure used by the still-new BEAD program would be premature. Paragraph 17 goes one step further and abolishes "without replacement the long-term goal of 1,000/500 Mbps established in the 2024 Report," on the reasoning that section 706 does not mention long-term goals and that setting one could conflict with the Commission's obligation to stay technologically neutral.

Two practical consequences, neither of them about politics.

A line that delivers 20 Mbps upstream is a fully served location in the federal accounting, so nothing about your county's map status will improve because your calls are breaking. And the 500 Mbps upstream figure that used to sit in the record as a direction of travel is gone, which removes the one federal number a consumer could point at when asking why the upstream on a coaxial plant has barely moved in a decade. What you are owed is now entirely a matter of your provider's own published label and your own agreement. Nothing in the 706 framework obliges anybody to sell you more upstream.

A full upstream pushes back on the download side

The reason the upstream is the small channel is physical on everything except fiber, and the numbers behind that are in the comparison of what each access technology actually delivers rather than repeated here. What belongs here is the consequence, because it is the part people get wrong when they decide an upload problem is somebody else's problem.

Saturating the upstream degrades the downstream. This is not folklore; it is written into an IETF Best Current Practice. RFC 3449, BCP 69, on TCP performance over asymmetric paths, works an example where the two directions differ in raw capacity by a factor of 200. Because acknowledgements have to travel the narrow way, it concludes that once the receiver acknowledges more often than one ACK every eight data packets — which ordinary TCP does — "the upstream link will become saturated before the downstream link, limiting the throughput in the forward direction." The document dates from 2002, which is the point: this is older than any plan you can buy today. The same document observes that "an asymmetric workload (more downstream than upstream traffic) may cause ACKs to be queued in some wireless nodes (especially in the end host modems)" and lists cable modem uplinks among the shared media where that queuing happens.

Put plainly: the big outbound transfer you started because "it only uses upload" is not a background job. It can slow the download side of the same line, and it will lift latency while it runs. The FCC added a metric for exactly this. Its Thirteenth Measuring Broadband America report, which analyzes validated data collected in September and October 2022, reports "latency under load, or working latency in the presence of downstream traffic and upstream traffic," and explains why it bothered: with more traffic inside homes and heavier use of "roundtrip latency-sensitive real-time applications such as for videoconferencing, the latency under load metric has become increasingly important."

If your calls fail specifically while something is uploading and the modem's error counters stay flat, that is a queue rather than a fault, and it is treated as its own problem in the numbers that break video calls.

There is one more upstream consumer that hides well, and it is corporate. Microsoft's own overview of VPN split tunneling, read 28 September 2026, describes forced tunneling — the arrangement where "all connections from the remote user device are routed back into the on-premises network" — as a model that was sustainable while remote users were few and traffic volumes were low, and recommends steering Microsoft 365 traffic away from it. On a forced-tunnel VPN your camera feed does not go to the nearest media edge. It goes to your employer's datacentre first. That path is longer, it is encapsulated, and whether it is in place is a question for your IT department rather than for your provider. Ask it before you pay for a faster tier.

Measuring the upload you actually have

Four rules, and then the log.

Wire the laptop into a LAN port on the gateway and switch the Wi-Fi radio off at the operating system level. Quiet every sync client and backup job in the house, not just on the machine you are testing from. Disconnect the VPN for the baseline run, then reconnect and run it again, because the gap between those two results is the most useful figure in the file. And test in the window that matters: a weekday evening, and again inside your own meeting hours, because those are different congestion conditions and only one of them is the FCC's peak.

Then record more than a single upload figure. The columns worth having:

The full method, including why two tools and a pinned server are worth the trouble and how many runs make a log worth sending to anybody, is set out in the repeatable testing method. The upload-specific addition is the loaded-latency column, taken while the line is pushing rather than pulling.

Compare the result against your provider's published typical upload speed rather than against the tier name. Every US provider is required to display a broadband consumer label "with the content and in the format prescribed by the Commission" (47 CFR 8.1, read from the eCFR issue of 24 September 2026). The prescribed content sits in a figure rather than in the rule's text, so the field list comes from the order that adopted it: the Commission "requires providers to display their typical upload and download speeds and typical latency" (87 FR 76959, 16 December 2022, paragraph 27). One note on currency, because the eCFR flags an amendment at 91 FR 52260 published 13 August 2026: that order does trim the label, but only its revised definitions took effect on 14 September 2026. The instruction rewriting the label paragraphs themselves is marked "delayed indefinitely" pending a future Federal Register notice, so the label you open today is still the one described above. A measured upload well under the typical figure the company printed itself is a documented gap. A measured upload that matches it, on a plan whose typical upload was never enough for your household, is a different problem with a different answer.

Hours, not megabits, for the jobs that run overnight

Live calls are a capacity question. Bulk transfers are a time question, and the arithmetic is worth having in front of you before you decide the line is broken.

A gigabyte is 8,000 megabits, so one gigabyte over a perfectly clean 20 Mbps upstream takes 400 seconds. Nothing is perfectly clean, which makes the table below a floor rather than an estimate.

Read those as best cases with the line doing nothing else. The first initial backup of a laptop that has never been backed up is the row people hit without expecting to, and on a 5 Mbps upstream it is not an overnight job — it is most of a week of evenings, during which every call in the house competes with it.

Which points at the cheapest fix available. Throttling the sync client and scheduling the initial pass for hours nobody is working costs nothing, and most backup and cloud storage clients expose a bandwidth cap for precisely this reason. Set it below your measured upload rather than at some fraction of the advertised figure, and check it against your loaded latency: if the round trip stays near idle while the upload runs at the cap, the cap is low enough.

Sorting the three problems that all look like one

By this point the log usually says which of three situations you are in, and they have different answers.

Concurrent live demand exceeds the upstream. Two HD meetings plus a screen share genuinely wants around 8 to 10 Mbps upstream on the vendors' figures, and a line whose typical upload range starts at 2 or 6 Mbps cannot do that at 4 p.m. on a Tuesday. No support call fixes this. It is a capacity problem, and the options are a tier with a genuinely different upload figure, a different access technology, or fewer simultaneous cameras.

Bulk transfers colliding with calls. Upload sits near the label figure, latency is fine at idle and terrible while something syncs. This is scheduling and queue management, on your side of the demarcation point, and a technician visit will find nothing wrong.

The upload is well below what the company published. Wired, repeated, in both peak and off-peak windows, against the typical upload speed on the provider's own label. That is the case worth documenting properly, because it is the only one of the three where the provider is the party that has to answer.

Telling those apart takes a week and costs nothing but attention. Start it tonight: open your provider's label and write down the typical upload speed it claims, run one wired upload test with the VPN off and one with it on, and note the round-trip latency during each upload rather than only the throughput. Then put a recurring entry in the calendar for 8 p.m. on a weekday. Four rows in that file, taken in the right windows, will tell you more about your working life than the download number on the front of the bill ever has.