Business
Internet speed test for small business
Test the busiest office workflows, isolate Wi-Fi from provider capacity, and turn each result pattern into a defensible network decision.
Peak-hour decision tablePOS and call continuityWired, Wi-Fi, and failover audit
Speed TestResults
Test your internet speed
Measure download, upload, and latency instantly—no installs.
Download
—
Upload
—
Latency
—
Actionable insights
See how your results stack up for streaming, gaming, and remote work.
Run again after tweaks to confirm Wi-Fi and device improvements.
Runs in your browser. No account or download required.
Setup checklist
Get faster, steadier results
Follow these focused steps, run a fresh speed test, and compare the numbers against your goals.
Map the office workload before judging one speed score
- Count concurrent work, not total employees. Record the busiest realistic overlap of video meetings, voice calls, payments, cloud sync, security cameras, and guest use.
- Separate capacity from continuity. A payment terminal may use little bandwidth but still needs a dependable route, DNS, and local network. A large backup needs capacity but can often be rescheduled.
- Identify the constrained direction. Meetings, cloud backup, and off-site camera viewing can compete for upload even when the download result looks excellent.
- Use platform documentation as an input, not a guarantee. Add the requirements of simultaneous endpoints, then validate the actual office during its busiest hour.
Decision table: translate workflows into test criteria
- Group video: Zoom lists about 2.6 Mbps upload and 1.8 Mbps download for one 720p group-video endpoint. Multiply only by the calls that can truly overlap, then leave room for other traffic. See Zoom's current meeting requirements.
- Business voice: Zoom documents roughly 60–100 Kbps per Zoom Phone call. The important test is whether calls remain clear while the upstream link is busy, not whether the office has a huge headline download number. See Zoom Phone QoS guidance.
- Point of sale: treat availability and local-network stability as the decision criteria. Square recommends USB or Ethernet connections where possible in its business networking guidance; it does not publish one universal POS Mbps target.
- Cloud backup and large files: decide the acceptable completion window, measure upload at peak and quiet times, and schedule noncritical transfers when they will not collide with calls.
- Guest Wi-Fi: pass only if a busy guest network cannot starve payment, voice, or staff traffic. Use isolation and rate limits when the managed network supports them.
Four-test office diagnostic
- 1. Quiet wired baseline: connect one capable laptop by Ethernet to the primary gateway or switch, pause scheduled transfers, and record download, upload, idle latency, and loaded latency.
- 2. Peak-hour wired test: repeat while normal business traffic is active. This comparison reveals shared-link congestion without mixing in Wi-Fi coverage.
- 3. Work-area Wi-Fi test: use the same device in the payment, meeting, and customer-facing areas. Keep the test endpoint fixed when possible so room-to-room comparisons stay meaningful.
- 4. Continuity test: verify the approved backup connection and documented failover steps before an outage—not during a customer queue.
- Repeat each important comparison at least twice. A single browser test is a snapshot, not a service-level certification.
Decision table: what each result pattern means
- Wired is healthy; Wi-Fi is poor: investigate access point placement, channel use, roaming, cabling, or client radios before buying a faster internet plan.
- Quiet is healthy; peak hour collapses: identify the concurrent upload, download, or guest workload and apply scheduling or traffic policy before upgrading capacity.
- Idle latency is fine; loaded latency jumps: the link becomes unresponsive under traffic. Pause the suspected transfer, retest, then evaluate queue management or more upstream capacity.
- Every wired test is weak:compare results with the typical speeds and latency on the provider's broadband label, check the gateway and cabling, then collect time-stamped evidence for the provider.
- Only one device or application fails: inspect that device, software, security inspection, or service status instead of treating it as proof of an office-wide bandwidth problem.
Continuity and change-control checklist
- Put payment terminals, call equipment, fixed workstations, and access points on wired connections where the hardware and site allow it.
- Keep guest traffic separate from business devices with the vendor-supported guest network or VLAN design; document which systems must still communicate locally.
- Record router, switch, and access-point firmware versions before changes. Back up supported configurations and schedule disruptive work outside business hours.
- Configure payment contingency only according to the processor's current rules. For example, review Square's offline-payment instructions and risks before relying on offline mode.
- Test failover, DNS resolution, calling, and payment workflows—not just raw Mbps—then record the owner and recovery steps.
Evidence to save before changing an internet plan
- Date, local time, device, connection type, test endpoint, and whether the office was quiet or busy.
- Download and upload capacity plus idle and loaded latency, jitter, unsuccessful probes, and the test confidence shown with the result.
- A paired wired and Wi-Fi result from the same device and time window.
- The provider's current broadband label. FCC labels are designed to show typical download, upload, and latency alongside price and plan terms; see the FCC consumer-label fact sheet.
- Application evidence: call statistics, payment-terminal connectivity reports, backup completion times, and provider incident or status records.
Scope, sources, and update record
- Updated July 24, 2026. The workflow thresholds above are tied to the visible official documentation; recommendations without a universal vendor threshold are presented as diagnostic decisions rather than invented Mbps guarantees.
- A browser result covers one device-to-endpoint path. It does not certify every SaaS destination, local switch, payment processor, or failover carrier.
- Recheck linked vendor requirements before procurement because software modes, codecs, hardware, and service policies can change.
- For the measurement protocol, confidence rules, privacy, and known limits, read the SwiftSpeedTest methodology.
Retest and log improvements
Run SwiftSpeedTest after each change. Note the download, upload, and latency shifts to lock in better performance.