An SMS carries a fixed payload. Anything longer than that payload has to travel as several messages that the receiving handset stitches back together, and the mechanism for doing so is concatenation. The reader sees one message; the network moved several.
How does the handset know to join them?
Each part carries a header saying which message it belongs to and where it sits in the order.
That header is the User Data Header, defined in 3GPP TS 23.040, and it holds a reference number shared by every part, the total number of parts, and this part's position. A handset collecting parts with the same reference number can order them and show one message. The specification is published only as a PDF, so this page describes it rather than quoting it.
The header lives inside the payload rather than beside it, which is the whole reason the per-part capacity drops. Bird's character limits guide gives the arithmetic:
Each multipart segment reserves a few bytes for a reassembly header, called the User Data Header. This reduces the capacity from 160 to 153 for GSM-7, and from 70 to 67 for UCS-2.
Why does a 161-character message cost two segments and not one and a bit?
Because segments are whole messages, and the split changes the budget for the whole body.
The guide works the example:
A 161-character GSM-7 message takes 2 segments (
ceil(161 / 153) = 2). The split divides the encoded body across both segments, with 153 characters available in each.
Note what happens at the boundary. At 160 characters you are inside a single segment. At 161 you are not, and the moment a message needs splitting every part pays the header, so the capacity you are dividing into is 153 per part rather than 160. One character over the line costs a whole extra message, and the second segment is mostly empty.
The same cliff exists in UCS-2 at 70 characters, where it bites harder because the budget was smaller to begin with. What is GSM-7 vs UCS-2 encoding covers which body lands in which.
What happens if a part goes missing?
The handset is left holding an incomplete message, and behaviour varies.
The parts are independent messages as far as the network is concerned. They can take different routes, arrive out of order, or not arrive at all. A handset that has some parts but not all of them has no way to render the whole, and what it does next is a handset decision rather than a specified one: some wait, some eventually display the fragments they have.
This is worth knowing because it is a real failure mode that looks like a content bug. A recipient reporting a message that "arrived cut in half" or "came in two pieces out of order" is describing a delivery problem, not a formatting one. It also argues for keeping messages that matter inside one segment where you can, particularly one-time passcodes, where a fragment is useless.
Is there a limit on how many parts?
Yes, and Bird's is explicit rather than discovered:
Bird accepts up to 12 segments per message. That translates to:
- GSM-7: 1,836 characters (12 x 153)
- UCS-2: 804 characters (12 x 67)
with a refusal rather than a silent trim:
A body that exceeds 12 segments is rejected with a
422error. Bird never truncates a message silently.
That is the right trade. A truncated message is worse than a rejected one, because the sender learns nothing and the recipient gets something misleading.
How do I see what actually happened?
Read the count back from the response rather than estimating it.
Every SMS response carries a segments object with the count, the encoding chosen and the character total, so you can check what the platform calculated instead of reimplementing the rules. What is an SMS segment covers what that count means for billing, and the character limits guide has the field.