Why is 9600 the default baud rate? A crystal, a teleprinter, and a lot of doubling

9600 is a strange number to find everywhere. It is not round in decimal. It is not a power of two. It is roughly a thousandth of what a modern link can do, and yet it is the factory default on virtually every Bluetooth module, GPS receiver, serial LCD and USB-to-serial adapter you can buy today.

It is not arbitrary, and it is not inertia alone. There are two real reasons, and one of them is a specific crystal you can still buy.

It starts with a teleprinter

Baud rates predate computers. The unit is named for Émile Baudot, and the early numbers came from mechanical printing telegraphs — machines with motors and cams, where the rate was set by physical gearing.

The classic Teletype Model 33 ran at 110 baud. That looks like a peculiar number until you notice what it was doing: the machine used eleven bit-times per character — one start bit, eight data bits, and two stop bits, because the mechanism needed the extra time to finish printing. 110 divided by 11 is exactly 10 characters per second, which is the number the engineers actually cared about.

So the first standard rate was chosen to make a mechanical constraint come out round. Nothing about it is electrical.

Then everything doubled

After that the sequence is simple: 75, 150, 300, 600, 1200, 2400, 4800, 9600, 19200, 38400, 57600, 115200.

Each is double the one before. That is not aesthetics — it is how the hardware works. Generating a baud rate means dividing a clock down, and a binary counter halves a frequency essentially for free. Every doubling of the rate is one fewer division stage from the same source. A chip that can produce 1200 can produce 2400 and 4800 with no extra parts.

So the ladder of familiar rates is really a ladder of divider stages, and the numbers look odd in decimal only because they are tidy in binary.

The crystal that made them exact

Here is the part that actually settles it.

A UART divides its input clock to produce the baud rate, and that division is by an integer. If the arithmetic does not come out whole, you round, and rounding means your actual rate is not the rate you asked for. Every bit of that error eats the timing budget.

So the industry made a crystal specifically for the job: 1.8432 MHz. It appears on countless serial boards and in countless UART datasheets, and this is why:

Rate	1.8432 MHz ÷ 16 ÷ rate	Exact?
300	384	yes
1200	96	yes
2400	48	yes
4800	24	yes
9600	12	yes
19200	6	yes
38400	3	yes
57600	2	yes
115200	1	yes

Every standard rate from 300 to 115200 divides exactly — zero error, not "close enough". The crystal was chosen so that the entire ladder falls out of one part with no remainder. That is not luck; 1.8432 MHz is 115200 × 16, and every other rate is a power-of-two division of it.

Once hardware like that is cheap and everywhere, the rates it produces perfectly become the rates everyone uses, and the two facts hold each other up for decades.

Your Arduino does not have that crystal

An Arduino Uno runs at 16 MHz, chosen for the CPU, not for the UART. And 16 MHz does not divide evenly into the baud ladder at all:

Rate	16 MHz ÷ 16 ÷ rate	Exact?
9600	104.167	no
38400	26.042	no
115200	8.681	no

So every rate on an Arduino is approximate. The divider is truncated to an integer and the real rate is whatever that integer produces. Running the numbers the Arduino core actually uses on a 16 MHz board:

Requested	Actual	Error
9600	9615.4	+0.16%
19200	19230.8	+0.16%
38400	38461.5	+0.16%
57600	58823.5	+2.12%
115200	117647.1	+2.12%

0.16% is nothing — the budget is around 5%, as how much baud error is too much works through. But notice that 57600 is thirteen times worse than the faster 38400. That is a hardcoded exception in the Arduino core, which drops 57600 out of double-speed mode at 16 MHz for compatibility with an old bootloader, and it is why 57600 has a reputation for being unreliable on an Uno.

This is the practical reason to care about crystal frequencies at all. A board built around a 1.8432 MHz oscillator, or a multiple of it such as 7.3728 MHz or 14.7456 MHz, hits every standard rate dead on. A board built around a round decimal number like 16 MHz never does. Neither is a mistake — the Arduino's 16 MHz was picked for instruction throughput, and 0.16% is comfortably inside budget — but it means "9600 baud" on an Uno has always meant 9615.4.

So why 9600 and not 4800 or 19200?

Because 9600 sits at the top of the range that essentially everything can produce accurately, and that is a different property from being fast.

A module manufacturer picking a factory default does not know what will be on the other end. It might be a 16 MHz Arduino, an 8 MHz board running from an internal RC oscillator, a Raspberry Pi, or a USB adapter. The rate has to be one that all of them can hit closely enough, first time, with no configuration. Go faster and the divider errors grow on the weakest hardware. Go slower and you are throwing away throughput for no gain in reliability.

9600 is the compromise point — and it has been the compromise point for so long that it is now self-sustaining. Modules default to 9600 because tools default to 9600 because modules default to 9600.

Should you still use it?

For an Arduino Bluetooth link, 9600 is a perfectly good choice and often the right one. It is what HC-05, HC-06 and HM-10 modules ship at for data, which means it is the rate that needs no setup — and it is far more than enough for sensor readings or a phone sending drive commands.

Move faster when you have a real reason: streaming sensor data, or a display that redraws often. When you do, prefer 38400 on a 16 MHz Arduino over 57600. It is faster and more accurate, which is not the trade anyone expects.

What matters more than the number is that both ends carry the same one. There is no negotiation on the wire — set them differently and you get garbage, every time. You can watch exactly how that garbage is produced in the baud mismatch playground: type a character, set the two rates apart, and see precisely which bytes arrive wrong and which vanish entirely.

If that is happening to you right now, garbage characters in the Serial Monitor has the real factory baud table per module, including the one that catches everyone — an HC-05 in AT command mode is usually 38400, not 9600.