Online PDU Decoder for SUBMIT, DELIVER and STATUS-REPORT
Paste a PDU and read it field by field: service centre, address, encoding, timestamp, concatenation and the decoded text. When a field is broken, the decoder names it instead of returning a blank page.
Decode a PDU in the browser
The box starts with the SMS-SUBMIT frame produced by the encoder. Paste any frame, press Decode, and read the fields below it.
PDU decoder
OfflineDecoded fields
Text, timestamps and the concatenation reference are shown exactly as the frame carries them. The decoder never rewrites the input.
Nothing is uploaded. The frame is read by JavaScript in this page, so a PDU from a private message store stays on your machine.
Text mode vs PDU mode
The same message looks different depending on which mode captured it.
| What you see | Text mode output | PDU mode output |
|---|---|---|
| Message body | Readable characters | Hex octets; the text is packed or big-endian encoded |
| Encoding | Chosen by the modem | Explicit in the data coding scheme octet |
| Long messages | The modem hides the split | The UDH shows the reference, the part number and the total |
| Timestamps | Local formatting, if shown at all | The service centre timestamp with its time zone octet |
| Delivery reports | Summarised | Full status report frame with two timestamps and a status octet |
Text mode reads a message the way a person would. PDU mode reads it the way the network stores it. When something fails, the second view is the one that tells you which field is wrong.
SMS-DELIVER field structure
A delivered message arrives without a destination or a validity period, and carries a timestamp instead.
| Field | Octets | Meaning |
|---|---|---|
| SCA | 1 + n | Service centre that handled the message; 00 means the frame omits it |
| First octet | 1 | Message type, more-messages flag and user-data header flag |
| Originator | 2 + n | Sender address, with 91 for an international number |
| PID | 1 | Protocol identifier |
| DCS | 1 | Alphabet, class and compression bits |
| SCTS | 7 | Service centre timestamp: year, month, day, hour, minute, second and time zone |
| UDL | 1 | Septet count for GSM-7, octet count for UCS-2 |
| UD | n | Optional UDH plus the text |
The timestamp is not a Unix value. Each date field is decimal digits stored in swapped nibbles, and the last octet carries the offset from UTC in quarter-hours.
STATUS-REPORT fields
A status report replaces the user data with two timestamps and a result code.
| Field | Octets | Meaning |
|---|---|---|
| First octet | 1 | Message type 02, plus the status-report-qualifier flag if set |
| MR | 1 | The message reference the handset returned when it sent the message |
| Recipient | 2 + n | The number the message was sent to |
| SCTS | 7 | When the service centre received the message |
| Discharge time | 7 | When the service centre delivered it, in the same timestamp format |
| Status | 1 | 00–1F delivered; 20–3F temporary error, still trying; 40–5F permanent error; 60–7F temporary error, given up |
A status report has no user data. If the frame is longer than these fields, the extra octets are reported as a warning rather than decoded.
Where messages fail to decode
Most failures are copy errors, not broken messages. The decoder names the field it could not read.
| Input | Message shown | What went wrong |
|---|---|---|
| 00110009812143 | The address is shorter than its declared length. | Destination length says 9 digits, but only two octets follow. |
| 0011A | Hex length is odd (5 nibbles). A PDU must contain whole bytes. | A character was lost while copying, so the last byte is incomplete. |
| 004100098121436587F9000006070003010201 | UDH length 7 exceeds the user data. | The user-data header length octet claims more bytes than the frame carries. |
The decoder also rejects a frame whose service centre length runs past the end of the input, an address that ends early, a truncated timestamp and an SMS-COMMAND frame, which is a different message type. An 8-bit data coding scheme is shown as a binary length rather than fake text. Unknown extension characters and a stray escape code are dropped with a warning instead of turning the whole message into noise.
These three inputs are part of the same regression file as the encoder. Each expected error is stored as a substring, so a wording change in the decoder cannot silently pass.
Need an automated solution?
Use this page to inspect one frame. Use SMS Deliverer to handle the traffic.
The Windows application decodes incoming messages, reassembles multipart frames, stores the sender and the timestamp, and keeps delivery reports against the original send. The same parser is used by the desktop interface and the local HTTP API, so a message looks identical wherever you read it.
Start with the GSM modem guide for the hardware, the desktop software page for the receiving features, or the PDU encoder to build a frame for a test.
Supported frames
- SMS-SUBMIT, including concatenated parts
- SMS-DELIVER with timestamp and originator
- SMS-STATUS-REPORT with both timestamps
- GSM-7, extension characters and UCS-2
- 8-bit UDH, 16-bit reference and port addressing
Reviewed 2026-11. SMS-COMMAND frames are rejected by design; they are not message traffic.
Questions buyers ask
Why does the decoder say the service centre is not in the PDU?
A leading 00 means the frame has no service centre address, so the handset or modem uses the one stored on the SIM. The rest of the frame still decodes normally.
Can it decode a delivery report and a multipart message?
Yes. SMS-STATUS-REPORT frames show both timestamps and the status octet. For multipart messages the UDH is read and the part shows its reference, its sequence number and the total.
Why is part of my message shown as binary content?
The data coding scheme in that frame declares 8-bit data rather than text. The decoder reports the octet count instead of inventing characters that are not there.
Does the decoder send my PDU anywhere?
No. Parsing happens in this browser. The page also works offline, which matters when the message contains private numbers or content.