Contact

Zoho Sheet HEX2OCT Function: Hexadecimal to Octal with Examples

Number Conversion Intermediate Zoho Sheet

Convert hexadecimal values to octal in Zoho Sheet with exact datasets, place-value checks, documented limits and practical examples.

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

HEX2OCT converts a hexadecimal representation into octal. For the positive integer 42, the source numeral is 2A and the converted result is 52. The base changes; the represented quantity does not. Use a width argument when a receiving report needs leading zeroes.

Syntax and availability

HEX2OCT(hexadecimal_number; [num_of_digits])

Zoho’s official HEX2OCT entry was checked on October 15, 2026. It describes the rolling web service. The first supported release and last functioning version are unknown; current documentation is separate from those historical endpoints. Mobile/offline parity is unverified. Results below are independent integer calculations, not native Zoho execution.

The required source contains at most ten characters, using only 0–9 and A–F. Hexadecimal input is documented as case-insensitive: A and a have the same meaning. Quote literal hexadecimal strings, for example “FF”. The checked entry does not fully specify signed interpretation of maximum-width values; these examples use small positive values and make no unsigned or two’s-complement promise at that boundary.

The second argument chooses the output width. When the representation is shorter, Zoho pads its left side with zeroes; an insufficient width is an error, not permission to cut off significant digits. Use positive integer widths here. Fractional widths, blank inputs and Boolean coercion are not verified.

Square brackets mark an optional argument and are not typed into a formula. Omitting width gives the unpadded representation in the ordinary positive examples. Follow your workbook’s locale separator; these formulas use semicolons.

Visible official control

Zoho explicitly gives =HEX2OCT("FF";12) with result 000000000377. That is direct evidence for a twelve-character output in this product; do not import another application’s ten-place restriction. Other vendor examples refer to cells whose inputs are not visible in the extracted help; the complete worksheet below supplies its own inputs rather than inventing those hidden cells.

Complete reproducible worksheet

Create Conversions with Source in A1, Decimal_check in B1, Converted in C1, and Padded in D1. Enter the following values in A2:B7. Set column A to text before entering hexadecimal strings so digit-looking codes remain source text; do not include the display quotes in the cell contents. Column B is an independent explanatory value, not an argument to the conversion formula.

Row A: source B: decimal check C: expected D: expected width 5
2 1 1 1 00001
3 7 7 7 00007
4 F 15 17 00017
5 2A 42 52 00052
6 3F 63 77 00077
7 FF 255 377 00377

Enter C2 =HEX2OCT(A2) and fill through C7. Fill D2 =HEX2OCT(A2;5) through D7. The zeroes in D belong to the representation, not to a larger numeric value.

In a copy change A5 from 2A to 2B and update its explanatory B5 to 43. C5 becomes 53 and D5 becomes 00053. Other records remain unchanged. This gives a one-unit sensitivity check with a fully specified input.

Advanced: reconcile two positive code representations

Put the text 1A3 in G2 and =HEX2OCT(G2;4) in H2. The expected string is 0643. The hexadecimal input represents 1×256+10×16+3=419. Independently, the octal digits give 6×64+4×8+3=419.

The same value has binary representation 110100011. Grouping those bits in threes gives 110,100,011, or 6,4,3; grouping from the right in fours gives 1,1010,0011, or 1,A,3. This is why converting between hex and octal is more than replacing each character with a different character.

Change G2 to 1A4 in a copy. H2 becomes 0644, representing 420. For an independent smaller record, =HEX2OCT("A5";4) is 0245, representing 165. Keep the original code alongside the converted code when auditing an import. The conversion preserves the specified numeric value, but it does not preserve an identifier’s original capitalization or original leading-zero count.

Errors and troubleshooting

The documented #NUM! cases include an output that needs more places than the requested width, and width zero or negative. For example, =HEX2OCT("FF";1) cannot hold 377 in one position. Increasing the width preserves the whole representation; shortening the source value would change the data.

An invalid source digit also produces the documented #NUM! error; HEX2OCT("G") is an invalid-digit control. Do not remove an error merely to make a report appear complete: retain the raw value and investigate the format or width rule.

The shared help glossary mentions name, type and reference errors without defining a complete coercion matrix for this function. Check the source base, legal characters, cell type and literal quotation before investigating more complex formulas. Do not add 0x, 0b or other programming-language prefixes unless a product reference explicitly permits them.

Keep conversion and arithmetic separate. A nondecimal display can look like a decimal number, yet ordinary subtraction on that display need not measure the intended change. Preserve raw identifiers, document the source’s sign and width convention, and verify exported leading zeroes in the receiving system. Matching function names across spreadsheet products do not establish identical limits or behavior.