How much baud rate error is too much? The real number is 5.26%, not 2%

There is no clock line. That single fact is where every baud rate argument comes from, and it is why "close enough" is a question with an actual number for an answer.

On SPI or I2C, one side sends a clock and the other follows it. However far the two chips drift apart, they stay in step, because one of them is telling the other when to look. UART has no such wire. The receiver sees one falling edge — the start bit — and from that moment it is counting on its own, using its own crystal, guessing when each of the next bits will be in the middle of the wire.

So the question is not whether the two ends disagree. They always disagree. The question is how far they can disagree before the guess lands in the wrong place.

The receiver is not reading the line, it is sampling it

An ATmega328P — the chip on an Arduino Uno — runs its receiver sixteen times faster than the baud rate. At 9600 baud it ticks 153,600 times a second, sixteen ticks per bit. When it sees the line fall, it starts counting ticks, and at ticks 8, 9 and 10 of each bit it takes three samples and uses whichever value it saw twice.

That is worth sitting with, because it explains everything that follows. The receiver is not watching the wire continuously. It looks three times per bit, near what it believes is the middle, and it believes that based on nothing but its own clock and how long ago the start bit arrived.

Sampling at the middle is the whole safety margin. The receiver can be wrong by almost half a bit-time in either direction and still land somewhere inside the correct bit. Half a bit-time is the entire budget. Everything below is arithmetic about how fast you spend it.

The error accumulates, and that changes the answer

Here is the part that most explanations skip.

The receiver does not re-sync on every bit. It syncs once, on the falling edge of the start bit, and then counts. So a 1% timing error does not mean each bit is 1% off. It means the first bit is off by 1% of one bit-time, the second by 1% of two bit-times, the fifth by 1% of five, and so on. The error compounds across the frame.

In a standard 8N1 frame there are ten slots: one start bit, eight data bits, one stop bit. The receiver aims for the centre of each, so the last slot's target is 9.5 bit-times after the edge it synced on. That is the slot with the most accumulated error, by a long way.

Failure happens when accumulated drift exceeds half a bit-time:

0.5 bit-time  /  9.5 bit-times  =  0.0526  =  5.26%

5.26%. That is the real ceiling for 8N1, and it is not a rule of thumb — it falls out of the frame's own geometry. NXP's application note AN10333 gives approximately 5% for the same frame, from the same reasoning.

You can watch it happen rather than take my word for it. The sampling simulator draws where the receiver actually looks as you drag the error up. Below about 5% every tick lands inside its own slot. Push past it and the failure appears — and it appears at the right-hand end, never the left.

Why the stop bit is always the casualty

Because drift grows with every bit-time counted from the edge, the far end of the frame is always the first thing to break. And the far end of an 8N1 frame is the stop bit.

This is not a detail — it is why serial fails the way it does. The receiver knows what the stop bit must be. It must be high; that is the definition. So when drift finally pushes the sample off the end, the receiver looks for a high bit, finds something else, and raises a frame error. It does not hand you a silently corrupted byte. It tells you the frame was malformed.

Push the error higher and the failure walks leftward into the data bits. But it never begins there. Any tool that shows you a mismatch corrupting a middle bit first has the model wrong.

So where does 2% come from?

It is an engineering convention, and a good one. It is not a specification, and no datasheet will tell you that 2% is a limit.

5.26% is the point of total failure. It assumes a clean edge, no noise, no temperature drift, and it is the combined error of both ends — if your transmitter is 3% fast and your receiver 3% slow, you are at 6% and already over. Designing to 2% means the link still works when a part warms up, when the supply sags, when the cable is longer than it should be. It is margin, deliberately.

The honest summary: 5.26% is where it breaks, 2% is where you should aim. Anyone quoting 2% as the specification is repeating a convention as though it were physics, and anyone quoting 5% as a design target has spent the whole budget before the first cold morning.

What your Arduino is actually running at

None of this matters unless you know your real error, and here most people assume it is zero. It is not. The ATmega328P generates its baud clock by dividing 16 MHz by an integer, and 16 MHz does not divide evenly into most baud rates.

On a 16 MHz board, running the numbers the Arduino core actually uses:

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%

Look at 57600. It is ten times worse than 38400, which is a higher rate — that is not what anyone expects. The reason is a hardcoded exception in the Arduino core: for 57600 on a 16 MHz board only, it switches the USART out of double-speed mode, for compatibility with a bootloader shipped on boards from over a decade ago. That one branch is why 57600 has a reputation for being flaky on an Uno.

And 9600 at +0.16%? That is the same in both register modes, which is a large part of why it became the default that everything ships with. It is not that 9600 is fast enough for anything. It is that 9600 is accurate on the widest range of hardware. The longer version of that story — a teleprinter, a chain of doublings and one crystal that divides exactly into every standard rate — is in why 9600 is the default baud rate.

What this means when something is actually broken

If your Serial Monitor is showing garbage, the odds are overwhelming that this article is not your problem. A 2% error does not produce garbage; it produces a link that works. Garbage means the two ends are set to different numbers — 9600 against 38400 is not a tolerance question, it is a 300% error — and the fix is to make them match. That is covered in garbage characters in the Serial Monitor, which also carries the real factory baud table per module.

Tolerance becomes the answer in a narrower and more frustrating case: the rates are matched, it mostly works, and you get an occasional corrupted character or a frame error under load or when the board is warm. That is the signature of a link running near its budget. The fixes are to move to a rate with lower divider error, to add a crystal if you are on an internal oscillator, or to slow down — 9600 exists for a reason.

The short version

• There is no clock line, so the receiver counts bit-times from one falling edge.
• It samples near the middle of each bit, so the budget is half a bit-time.
• Error accumulates across the frame, so the last slot spends the budget first.
• For 8N1 that gives 5.26% total, both ends combined. Longer frames tolerate less.
• The last slot is the stop bit, so the failure is a frame error, not a silent flip.
• 2% is the design convention, and that margin is what keeps a link working when warm.

Drag the slider in the sampling simulator until it breaks. The number it breaks at is not an opinion, and watching where it breaks is the part that makes the rest of serial make sense.