Education
Internet speed test for remote learning
Check the connection from the student's real study space, compare it with current platform requirements, and isolate Wi-Fi, congestion, device, or service problems.
Official Zoom and Meet referencesRoom-level comparisonClass-time recovery checklist
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.
Use platform needs—not a made-up universal school threshold
- Zoom currently lists about 2.6 Mbps upload and 1.8 Mbps download for one 720p group-video endpoint. See Zoom's meeting system requirements.
- Google advises remote users with a slow connection to verify at least 3.2 Mbps upload and download for Meet and to limit other household internet activity during a video conference. See Google's remote-work connectivity guidance.
- Treat those values as application references for one endpoint, not a guarantee for an entire home. Two simultaneous classes, cloud sync, streaming, and other calls share the same connection.
- Throughput alone is incomplete. A class can still freeze when Wi-Fi is weak, latency becomes unstable under load, probes fail, or the device is CPU-constrained.
- Updated July 24, 2026. The page now distinguishes documented platform requirements from SwiftSpeedTest diagnostic guidance.
Decision table: plan for the actual school day
- One Zoom group class at 720p:compare the result with Zoom's documented 2.6 Mbps up and 1.8 Mbps down for that endpoint, then check loaded responsiveness.
- One Google Meet class:use Google's 3.2 Mbps in both directions as the documented connection check, then validate from the student's actual study room.
- Two simultaneous classes: add the documented needs of both active endpoints and test while both study locations are in use. Do not assume a quiet single-device result represents that overlap.
- Class plus assignment upload: prioritize upload and loaded latency. Schedule large cloud sync or media submissions outside live instruction when possible.
- Recorded lessons only: download consistency matters more than camera upload, but platform resolution, other household traffic, and Wi-Fi still determine the real requirement.
Five-step class-readiness test
- Use the student laptop or tablet in the exact room and connection used for class. Connect power and close unrelated applications.
- Run a quiet-room baseline and save download, upload, idle latency, loaded latency, jitter, unsuccessful probes, and result confidence.
- Repeat at the actual class time while normal household use is present. This exposes contention that an early-morning test can miss.
- If the room result is weak, repeat with the same device near the router and then over Ethernet when supported. Keep the test endpoint fixed when possible.
- Join the platform's test meeting or diagnostics after the browser test. Confirm camera, microphone, speakers, permissions, and the platform-specific connection.
Decision table: interpret the result before changing plans
- Near-router is good; study room is poor: the likely issue is Wi-Fi coverage, interference, or placement—not the purchased internet tier.
- Ethernet is good; every Wi-Fi test is poor: review access-point location, band, channel selection, client compatibility, and mesh backhaul before buying more ISP bandwidth.
- Quiet is good; class time is poor: identify overlapping uploads, calls, streams, or updates. Pause one workload at a time and retest to find the constraint.
- Mbps is adequate; loaded latency or failed probes are high: the connection is becoming unresponsive under use. Reduce competing traffic, test Ethernet, and evaluate router queue management.
- Browser results are healthy; the class app still fails: inspect the platform status, application diagnostics, device load, camera and microphone permissions, VPN, firewall, and security inspection.
Class-time reliability checklist
- Prefer Ethernet when the study setup supports it; otherwise use the strongest stable Wi-Fi band available to that device.
- Place the student where signal is reliable and keep the access point in open air. Do not change channels or radio settings in the middle of an important class.
- Pause operating-system updates, game downloads, photo backup, and large cloud sync during live lessons.
- Use headphones or a headset to reduce echo and confirm camera, microphone, charger, and login before class.
- Document an approved backup: alternate room, Ethernet cable, school dial-in option, or a permitted mobile connection with enough data. Test it before it is needed.
When a class still freezes
- First capture the time, room, connection type, platform, meeting mode, and whether another household workload was active.
- Zoom's official Network Connectivity Tool can test latency, packet loss, jitter, and Zoom reachability when supported. See Zoom's diagnostic instructions.
- Send school or IT support both the browser result and the platform diagnostic. They measure different paths and together provide stronger evidence.
- If multiple wired tests remain below the provider's disclosed typical speeds, save time-stamped results and contact the provider with the plan details.
- Avoid promising that a single router reboot fixed the issue. Retest under the same class-time conditions to verify the change.
Scope and evidence limits
- Official bandwidth values can change with resolution, meeting mode, platform adaptation, and software updates. Recheck the linked requirements before making a plan decision.
- SwiftSpeedTest measures one browser-to-endpoint path. It cannot certify a school platform, teacher connection, institution network, camera, microphone, or device performance.
- The best evidence is a repeated same-device comparison from the study room, near the router, and—when possible—Ethernet, followed by the platform's own diagnostic.
- Review the SwiftSpeedTest methodology for measurement details, confidence signals, privacy, and known limitations.
Retest and log improvements
Run SwiftSpeedTest after each change. Note the download, upload, and latency shifts to lock in better performance.