How the encoding works
The text is first encoded as UTF-8, which turns the string into a sequence of bytes. Each of those bytes is then written in base 8 and padded on the left with zeros to exactly three digits. The results are joined with single spaces. That is the whole transformation, and it is deliberately the most conventional one.
Three digits is not arbitrary. A byte holds values from 0 to 255, which in octal runs from 000 to 377, so three digits is exactly enough and never more. Padding every value to the same width means the output can be split back apart without ambiguity and lines up neatly when you read it, which matters when you are eyeballing a byte sequence for something out of place.
The word "Hello" encodes to 110 145 154 154 157. The word "Hi" is 110 151. Working those back is easy: octal 110 is decimal 72, which is the letter H in ASCII, and octal 151 is decimal 105, which is the letter i.
- Text is encoded as UTF-8 first, then each byte is written in octal
- Every value is padded to three digits, from 000 to 377
- "Hello" becomes 110 145 154 154 157
Bytes, not characters, and why that matters
This encodes bytes rather than code points, and the distinction shows up the moment you leave plain ASCII. Every ASCII character is a single byte, so English text produces one octal value per character and the two ideas look the same. They are not.
An accented Latin letter takes two bytes in UTF-8, so a single é produces two octal values, 303 251. An emoji takes four, so one smiling face produces four values, 360 237 230 200. Most characters in Chinese, Japanese, Korean, and many other scripts take three bytes each. If you are counting the output expecting one group per visible character, non-ASCII input will surprise you.
This is the correct behavior rather than a shortcoming. Octal escapes in C, in shell scripts, and in most file formats are byte escapes, so byte-level output is what those destinations actually consume. A code-point-oriented encoding would produce values above 377 that no octal byte escape can represent.
Where octal still shows up
Octal is much less common than hexadecimal today, but it has not disappeared. Unix file permissions are the most familiar survivor: the 755 and 644 in a chmod command are octal, with each digit packing the read, write, and execute bits for one class of user into a single number from 0 to 7.
The other regular sighting is in escape sequences. C, C++, and several shells accept a backslash followed by up to three octal digits as a byte literal, which is why a three-digit zero-padded form is the convenient one to produce. Some older network protocols, embedded systems, and legacy file formats also express bytes in octal for historical reasons.
For most modern work, hexadecimal is the better choice: it maps cleanly onto four-bit nibbles, is shorter, and is what nearly every debugger, hex editor, and specification uses. Reach for octal when the destination specifically asks for it, and use hex the rest of the time.
- Unix file permissions such as 755 and 644 are octal
- C and shell escape sequences accept up to three octal digits per byte
- For general byte work, hexadecimal is usually the better choice