Web Serial Terminal
A read/write serial console in the browser. Sends only what you type.
How this talks to your device
You pick a port from the browser's chooser, choose a baud rate and line ending, and the terminal opens a read loop. Incoming bytes are rendered as text or hex, and unprintable bytes appear as escape sequences rather than being quietly dropped — that matters because a wrong baud rate does not produce silence. The port opens happily at any rate and delivers nonsense at the wrong one, so a screen full of escapes is the signature of a baud mismatch, and a terminal that hid them would make it look like a broken device instead. Nothing is transmitted until you type it and press Enter: no probe strings, no auto-detection, no handshake. Sending unsolicited bytes at unknown hardware is exactly how a well-meaning terminal puts a board into a bootloader or triggers a command nobody intended.
What the results mean
- Baud rate
- How fast bits are clocked on the wire. Both ends must agree; there is no negotiation. 9600 and 115200 cover most devices, and Arduino sketches usually pick one of them in setup().
- Line ending
- What is appended when you press Enter. Devices differ, and many parse a command only when the ending they expect arrives — which is why a device that seems to ignore you often just wants CRLF instead of LF.
- Escaped bytes like \xfe
- Bytes that are not printable text. A handful is normal for a binary protocol; a screen full of them at readable intervals almost always means the baud rate is wrong.
- Hex view
- Every byte as two hex digits. The right view for a binary protocol, and the fastest way to see framing bytes, checksums and padding that the text view turns into noise.
Common problems and fixes
- The port will not open
- Something else already has it. The Arduino IDE's serial monitor is the usual culprit, and only one application can hold a port at a time. Close the other one and try again.
- Data arrives as escaped bytes rather than text
- The baud rate is wrong. Try 115200 and 9600 first — between them they cover most devices. The port opening successfully tells you nothing about whether the rate is right.
- The device does not respond to anything you send
- Change the line ending. Many devices only act on a command when they see the terminator they expect, and a device that appears to ignore you is often waiting for CRLF while receiving LF.
- The board is not listed in the chooser
- Check the cable before anything else. A large proportion of USB cables carry power only, and a charge-only cable produces a board whose light comes on and which never appears as a port.
Frequently asked questions
Is this as capable as a desktop terminal?
For reading and writing, yes. Web Serial exposes baud rate, data bits, stop bits, parity and flow control, and the read and write paths are the same ones a native terminal uses. What it does not have is scripting, macros, session logging to disk and the ability to reconnect automatically — if you live in a serial terminal, a native one is still the better tool.
Why does it not detect the baud rate automatically?
Because auto-detection means transmitting. The usual technique is to send something and see whether the reply parses, and sending arbitrary bytes at hardware whose command set you do not know is how a board ends up reflashed or a machine ends up in a service mode. Trying 115200 and then 9600 by hand takes ten seconds and risks nothing.
Can this flash firmware to my board?
No. Flashing needs the bootloader's own protocol and a reset sequence, and this deliberately sends only what you type. Web Serial can support flashing — several browser-based flashers exist — but that is a purpose-built tool for a specific chip rather than something a general terminal should attempt.
Is anything I type sent anywhere?
No. The bytes go from your browser to the serial port directly, and what comes back is rendered in the page. Nothing is uploaded or logged, and closing the tab releases the port — which also means another application can use it again.