Contact

OCT2DEC in Google Sheets: Decode Base-Eight Data and Signed Boundaries

Engineering Intermediate Google Sheets

Interpret octal text in Google Sheets, verify numeric-input conversion and reproduce thirty-bit signed boundaries with explicit positional arithmetic.

Verification status: See the evidence and test scope described in this guide. How formula examples are checked

Quick answer: OCT2DEC(signed_octal_number) interprets base-eight digits and returns a decimal quantity. Google’s signed format is thirty-bit two’s complement, with positive endpoint 3777777777 and negative endpoint 4000000000.

Availability and version history

  • Introduced: first introduction date is not established by the reviewed official history; no desktop release number is inferred.
  • Availability: documented in the rolling Google Sheets service; these examples use the web worksheet workflow.
  • Checked: October 14, 2026; official OCT2DEC reference. Documentation and independent models, with no native Sheets execution or wider client certification.

Syntax and accepted digits

=OCT2DEC(signed_octal_number)

Google describes the input as a signed thirty-bit octal string. Only digits 0–7 are valid; an outside digit causes documented #NUM! behavior. Each octal position corresponds to three binary bits, so ten octal digits span the thirty-bit format.

A valid numeric input is converted to its matching string. Google’s example makes numeric 177 and text “177” both produce 127. That is base-eight interpretation of the digits, not ordinary decimal use of the quantity 177.

The short reference does not specify every prefix, whitespace, excessive-length or error-precedence case. These examples use explicit plain representations and do not borrow a more detailed contract from another spreadsheet.

Example 1: decode a base-eight import

Set A2:A7 to Plain text and enter these strings. In B2 enter =OCT2DEC(A2) and fill down.

Octal input Expected decimal
11 9
27 23
64 52
157 111
640 416
007 7

For 157, the positional calculation is 1×64+5×8+7=111. For 640, it is 6×64+4×8=416. The last row shows that leading zeros preserve a field width without changing its numeric value.

A valid numeric input follows the documented conversion pattern: =OCT2DEC(157) has independently expected result 111. For clarity in an imported file, keep digit representations as text and decoded quantities as numbers in a separate column.

The original string 007 may be meaningful to an external format. Once decoded to decimal 7, its original three-character width cannot be recovered unless you retain the source or record that width separately.

Example 2: inspect signed thirty-bit values

Formula Expected decimal
=OCT2DEC("777") 511
=OCT2DEC("3777777777") 536870911
=OCT2DEC("4000000000") -536870912
=OCT2DEC("7777777770") -8
=OCT2DEC("7777777777") -1

For a negative full-width value, subtract 2^30, or 1073741824, from its unsigned positional value. The string 7777777770 has unsigned value 1073741816, so its signed value is −8.

The short string 777 is positive 511. A leading high-valued octal digit does not automatically make every short input negative. At ten digits, an initial 4 through 7 sets the highest of the thirty bits.

If a source file defines another signed width, interpret that schema separately. The same digit sequence can have a different meaning under a different width convention; the function cannot infer which external layout the author intended.

Advanced example: independently expand a three-digit field

Enter 157, 640 and 007 in D2:D4 as Plain text. In E2 enter and fill down:

=VALUE(LEFT(D2,1))*64+VALUE(MID(D2,2,1))*8+VALUE(RIGHT(D2,1))

Expected results are 111, 416 and 7. In F2 use =OCT2DEC(D2) and fill down; the results agree.

The helper formula is an explicit three-digit positional model. It is not a general parser for arbitrary lengths or signed full-width inputs. LEFT, MID, RIGHT and VALUE make the arithmetic inspectable without hiding field boundaries.

Advanced example: compare representations of the same quantity

Octal 157, binary 1101111 and hexadecimal 6F all represent decimal 111:

=OCT2DEC("157")
=BIN2DEC("1101111")
=HEX2DEC("6F")

Each formula has independently expected result 111. Binary weights 64+32+8+4+2+1 total 111; hexadecimal 6×16+15 also totals 111.

The cross-check uses a value inside all three converters’ positive ranges. BIN2DEC uses a much narrower signed format than OCT2DEC, so the same cross-check cannot be generalized to every octal input without checking that range.

Invalid digits and safe interpretation

=OCT2DEC("198") contains digits 9 and 8 and follows Google’s documented #NUM! rule. Do not silently replace the error with zero, because zero is a legitimate decoded value and would hide the invalid record.

Ordinary decimal 157 and decoded octal 157 differ: one is 157 and the other 111. Label columns with their base and retain original strings when exact imports must be audited. A visually numeric field is not automatically a decimal measurement.

Native coercion beyond the explicitly documented valid-number conversion, longer inputs, prefixes and malformed-data error ordering remain untested. The expected values above come from exact positional arithmetic and the stated signed format.

References and verification

Examples use fictional data, English function names and comma separators. Expected outputs are independent mathematical calculations or explicitly documented rules, not native Sheets captures. Check the spreadsheet locale when reproducing punctuation-sensitive formulas.