# Send ESP32 Sensor Data Over Wi-Fi > How to stream ESP32 sensor readings over Wi-Fi with a small TCP server sketch, and how to watch the live data on your computer without a USB cable. > > ESP32 · June 19, 2026 · by Alex Spataru · https://serial-studio.com/blog/esp32-send-sensor-data-wifi The ESP32's radio is the reason most people pick it, and yet a surprising number of projects still stream their sensor data through the USB cable. Usually that is because the serial monitor is the tool at hand, and sending data over Wi-Fi sounds like it needs a server, a protocol, and an evening of reading. It needs none of that. A plain TCP socket and the same comma-separated lines you already print are enough, and this post walks through the whole thing. ## The shape of the solution The simplest robust arrangement is to make the ESP32 a tiny **TCP server**. It sits on your network and waits; your computer connects to it and the board streams one line of values per sample down the socket. Two properties make this the right default: - The firmware never needs to know your computer's address. It just serves whoever connects. - TCP gives you ordering and delivery for free, so the stream on the receiving end is exactly the stream you sent. ## The sketch This is a complete, runnable example. It serves CSV over port 3333, and the only thing it measures is the board's own Wi-Fi signal strength and uptime, so you can test the plumbing before wiring a single sensor: ```cpp #include WiFiServer server(3333); void setup() { Serial.begin(115200); WiFi.begin("your-ssid", "your-password"); while (WiFi.status() != WL_CONNECTED) delay(250); Serial.println(WiFi.localIP()); // the address your computer connects to server.begin(); } void loop() { WiFiClient client = server.accept(); if (!client) return; client.println("RSSI,Uptime"); // a text-only first line names the channels while (client.connected()) { client.printf("%d,%lu\n", WiFi.RSSI(), millis() / 1000); delay(100); } } ``` Flash it, open the serial monitor once to read the IP address it prints, and the USB cable has done its last job. Replace the `client.printf` line with your real measurements when you are ready; the pattern stays one line per sample, values separated by commas. ## Reading it on the computer Any TCP client can consume this stream; `nc 192.168.1.42 3333` in a terminal proves it works. To see it as plots rather than scrolling text, Serial Studio's network driver (part of the free edition, like its serial and Bluetooth LE drivers) connects as a TCP client: choose the **Network** source, enter the board's IP address and port 3333, pick *Quick Plot (Comma Separated Values)*, and connect. Every value in the line becomes a live trace, and the text-only header line the sketch sends on connection names the channels, so you get *RSSI* and *Uptime* instead of *Channel 1* and *Channel 2*. Because the header goes out at the moment your computer connects, it is never missed. That small detail is a nice property of the server arrangement: every new connection gets a fresh, self-describing stream. ## When UDP fits better TCP retransmits until data arrives, which is what you want for a log but not always for a high-rate live feed, where a stalled retransmit means watching stale data. For send-and-forget streaming, UDP is the alternative: the board fires datagrams at your computer's address and never looks back. ```cpp #include WiFiUDP udp; void sendSample(float a, float b) { udp.beginPacket("192.168.1.20", 9000); // your computer's IP and port udp.printf("%.2f,%.2f\n", a, b); udp.endPacket(); } ``` The trade is explicit: the firmware now hardcodes a destination, and a dropped packet is simply gone. On the receiving side, select UDP as the socket type and set the local port to 9000. For most bench projects TCP is the better first choice; reach for UDP when rate matters more than completeness. ## Wireless without a network If there is no Wi-Fi where the project lives, the ESP32 has one more radio: Bluetooth Low Energy. The same free edition reads BLE characteristics directly, and the bundled [BLE Battery example](https://serial-studio.com/examples#BLE%20Battery) is a working starting point. The pattern survives the transport change, which is the deeper point of all of this: how the bytes travel is a detail. One line of values per sample is the contract, and everything downstream of it, plots, gauges, recording, stays the same whether the link is a cable, a socket, or a radio. [Serial Studio Isn't Just for Serial Ports](https://serial-studio.com/blog/not-just-serial-ports) explores that idea across all ten drivers. ## Frequently asked questions ### Do the ESP32 and the computer have to be on the same network? They need a route to each other, and being on the same Wi-Fi network is the simple way to get one. Across networks (or from the internet) you would need port forwarding or a VPN, and at that point a broker-based protocol like [MQTT](https://serial-studio.com/blog/what-is-mqtt) is usually the saner architecture. ### How do I find the board's IP address later, without the USB cable? Give it a static lease in your router's DHCP settings, which is a one-time fix. Your router's client list also shows it. If you prefer the firmware to handle it, print the IP to the TCP stream itself as a startup line, or use mDNS so the board answers at a fixed name. ### How fast can I stream over Wi-Fi? Far faster than the serial-cable habit suggests; even a conservative sketch sending a line every 10 ms moves data at rates a 115200-baud UART cannot match, and the radio has headroom beyond that. In practice the sensible limit is set by your sensor's real sample rate and by Wi-Fi's occasional latency spikes, which TCP absorbs by buffering. ### Does streaming over Wi-Fi drain the battery? The radio is the hungriest part of the chip, so yes, a continuous stream costs real power, typically on the order of 100 mA and more while transmitting. Battery projects usually batch readings and sleep between transmissions rather than holding a live socket open. For always-on live telemetry, plan on external power.