Octal to Decimal Converter

Octal (base 8) is the one number system outside decimal that every Unix developer meets daily, even when they never thinks about it. Every file permission printed by ls -l, every mode accepted by chmod, and every octal escape sequence in a string literal is written in a base where each digit is three binary bits. This tool converts any octal string you paste into its decimal equivalent (with binary and hex alongside it) using strict input validation, an optional 0o prefix, tolerance for whitespace inside the value, and a 22-digit ceiling that matches JavaScript's Number.MAX_SAFE_INTEGER.

The motivating use case is reading the output of ls -l and stat: 0644, 0755, 0777, and the rest. Octal numbers back into three permission bits (read=4, write=2, execute=1) for owner, group, and world, which is why three octal digits pack the full permission tuple into nine bits, the lowest nine bits of a file's mode word. Beyond permissions, octal appears in C source as a legacy literal syntax (0123 means 83 decimal, not 123), in older assembly languages, in airline ACARS messages, and in any 3-bit-aligned binary dump. Decimal is what humans count in; hex is what computers print for byte-aligned values; octal is what shows up when a value naturally breaks into groups of three bits.

How to Use

1. Paste an octal value into the input box. Allowed characters are 0-7. The leading 0o or 0O prefix is optional; leading zeros are ignored; whitespace inside the value is removed automatically.
2. Click Convert (or press Enter). The decimal value appears immediately, alongside the canonical octal (0o prefix), the binary representation, the hexadecimal representation, and the bit length.
3. Use the table for cross-checks: 0644 octal must give 420 decimal, which must round-trip back to 644 octal, and 420 decimal must equal the unsigned interpretation of the permission bits for -rw-r--r--.
4. For values larger than 22 octal digits, the tool refuses with a clear message, twenty-two 7's is 0o777777777777777777777, the boundary of JavaScript's safe-integer range. For larger values use a BigInt-based tool.
5. The strict input check rejects any digit 8 or 9 (common typos when copying from a permission listing that you mistakenly read as decimal). A bare integer that contains 8 or 9 triggers "Invalid octal" rather than producing a wrong answer.

The Formula

The conversion is a single parseInt call against base 8, followed by three toString calls to express the same integer in binary, hex, and (canonicalised) octal:

decimal        = parseInt(octal_clean, 8)
binary         = decimal.toString(2)
hex            = decimal.toString(16).toUpperCase()
octal_canonical = decimal.toString(8)
bits           = binary.length

The parseInt(string, radix=8) operation is defined by ECMA-262 Section 21.1.3.18. It strips a leading 0o or 0O automatically (in modern engines that accept the prefix), ignores leading whitespace, accepts an optional sign, and stops parsing at the first character that is not a valid digit in the given radix. For octal, the valid digits are 0-7; the first non-octal character terminates the parse. So parseInt("7559", 8) returns 493 and silently ignores the 9, this tool replaces that behaviour with strict validation by pre-checking the input against the regex /^[0-7]+$/ before parsing, so a stray 8 or 9 produces a visible error instead of a wrong decimal result.

The maximum input is 22 octal digits. Twenty-two octal digits encode 22 × 3 = 66 binary bits, but the relevant boundary is Number.MAX_SAFE_INTEGER = 2^53 − 1 = 9007199254740991, which in octal is 0o777777777777777777777 (twenty-two 7s). Beyond that boundary, integer precision is lost: 0o777777777777777777777 + 1 and 0o777777777777777777777 + 2 both parse to the same JavaScript Number. The tool caps at 22 octal digits so that the displayed decimal value is always a faithful representation of the input.

The reverse direction (decimal to octal) is the same integer with .toString(8), prefixed with 0o for visibility. Because toString(8) drops leading zeros, the canonical form has no padding, 0o0755 and 0o755 represent the same value 493 and the tool shows 0o755.

Worked Examples

1. Unix directory permissions: 0o755 → 493. The classic Linux directory mode. The leading zero is ignored; 7 in the owner position means read+write+execute (4+2+1=7), 5 in the group position means read+execute (4+0+1=5), and 5 in the world position means read+execute. So 0755 decodes to "owner can do anything, everyone else can read and traverse", exactly what you want for ~/public_html or any shared drop folder. Converting 0755 to decimal gives 493, which in binary is 111101101 and in hex is 0x1ED. The 9-bit binary representation shows the three permission nibbles directly: 111 101 101.

2. File permissions: 0o644 → 420. The default file mode for files you create with umask 022. 6 means read+write (4+2+6), 4 means read-only (4), so the owner can edit the file but the group and the world can only read. Converting 0644 to decimal gives 420, which is 110100100 in binary and 0x1A4 in hex. The bit pattern makes it visually obvious that the owner has the two extra write bits set: 110 100 100 versus the more permissive 111 101 101 from the previous example.

3. Permissive mode: 0o777 → 511. The most permissive Unix mode: everyone can read, write, and execute. This is rarely appropriate for production files but is fine for /tmp and shared scratch directories on a single-user machine. 0777 in decimal is 511, in binary is 111111111 (nine ones), and in hex is 0x1FF. The all-ones binary is a quick visual flag that the mode is fully open, use this to spot accidentally permissive files in a directory listing.

4. A round 64-bit-aligned value: 0o100 → 64. The decimal value 64 is 2^6 and is conveniently the start of the printable ASCII range (octal 040 is space, 041 is !, 041 octal is the first character after space). The octal 0100 decodes to decimal 64, which is 1000000 in binary and 0x40 in hex. This example shows that small power-of-two values translate cleanly across all four representations and is a useful sanity check when you are learning the bases.

5. A larger example: 0o1234567 → 342,391. Seven-digit octal fits comfortably in 21 binary bits and is a useful test for the converter because every digit is different. Working it out by hand: 1·8^6 + 2·8^5 + 3·8^4 + 4·8^3 + 5·8^2 + 6·8 + 7 = 262144 + 65536 + 12288 + 2048 + 320 + 48 + 7 = 342,391. In binary it is 101001011010001110111 (21 bits) and in hex it is 0x53977. The bit pattern breaks neatly into three-bit octal groups: 101 001 011 010 001 110 111, and those groups read back as 5 1 3 2 1 6 7, which is 0o5132167, not the original 0o1234567, because reversing digit order changes the value. This is the most common mistake when eyeballing octal-to-binary: the grouping direction matters and you cannot read digits right-to-left.

Where It Shows Up

Octal shows up wherever a value naturally breaks into three-bit groups. The dominant modern context is Unix file permissions: chmod 0644 file.txt and ls -l output both use octal because every digit maps cleanly to a read/write/execute triplet. C source code uses octal literals for legacy reasons: int mask = 0123; declares an integer with value 83 decimal, not 123, the leading zero tells the C compiler "interpret the following digits as base 8". Modern C still supports this for backwards compatibility, but most codebases forbid it because of the ambiguity with decimal (0123 vs 123 confusion is a famous source of off-by-eight-times bugs). Assembly languages on the PDP-11, the DEC VAX, and the Motorola 68000 used octal natively in their syntax; this is part of why octal persisted in Unix even after most architectures moved to byte-addressable hex. The Unix od (octal dump) command still defaults to octal output (od -c file shows characters, od -b shows octal bytes), making octal familiar to anyone who has used Unix dump utilities. Avionics protocols, older telecom framing formats, and some legacy IBM mainframes (where X'FF' is hex but bare 777 is octal) also use octal. The takeaway: anyone editing Unix permissions, debugging legacy C, or reading an od dump will read octal regularly, and converting "what does this octal number say in decimal" is the most common small-calculator task that does not fit cleanly into a hex converter.

Common Mistakes

1. Reading Unix permissions as decimal. 0755 and 755 look the same to a reader who is not paying attention to context, and they ARE the same value, but 0849 (if you ever saw that in a listing) is a permission that does not exist because 8 and 9 are not valid octal digits. The tool's strict input validation catches this immediately. If you see 0849 in an ls -l output, the listing is corrupt.

2. Confusing C leading-zero octal with decimal. In a C source file, int x = 0123; declares x = 83, not 123. The leading 0 is a base marker. This is the single most expensive typo in C history and a frequent source of off-by-factor-of-eight bugs. C++14 deprecated leading-zero octal literals (use 0o123 instead) and C++17 removed them in some compiler modes. Java and JavaScript treat 0123 as decimal 123, not octal, which is the more modern convention. The tool's 0o123 input is unambiguous and works in every language that supports the prefix.

3. Treating parseInt as strict. The native parseInt("099", 8) returns 0 and warns (because in many implementations it is parsed as base-8-after-leading-zero but the leading-zero rule is environment-dependent in JavaScript, historically parseInt("099") was parsed as octal in some browsers and as decimal in others, leading to ES5 mandating the explicit radix). This tool's regex pre-check is unambiguous regardless of browser quirks: if the string contains anything outside 0-7, it is rejected before parsing.

4. Mixing octal and hex conventions. Because both octal and hex use the same 0 prefix to mark a non-decimal literal, they are easy to confuse when copying code between languages or older toolchains. Motorola 68000 assembly used $FF for hex and 123 for octal; x86 assembly uses 123h for hex and 123o (sometimes) for octal; C uses 0xFF for hex and 0o123 (or legacy 0123) for octal. The tool accepts the 0o form so a pasted value is unambiguous.

5. Going beyond the 64-bit safe range. Twenty-two octal digits is the limit. The boundary 0o777777777777777777777 equals Number.MAX_SAFE_INTEGER = 9007199254740991. If you try to convert 0o1000000000000000000000 (twenty-three 7's plus one), you will get a decimal value but lose precision in the least significant digits. For values beyond this, use a tool that uses BigInt internally, JavaScript's Number cannot represent every 64-bit value exactly.

Frequently Asked Questions

Q: Why does 0755 mean full permissions for the owner but not for everyone else? A: Unix file permissions use octal because each digit maps to three bits (read=4, write=2, execute=1). The first digit is the owner, the second is the group, the third is the world. So 0755 decodes as 7 for owner (4+2+1, all permissions), 5 for group (4+0+1, read and execute, no write), and 5 for world (same as group). To change a file's permissions, you write chmod 0644 file.txt, the leading zero is optional but a common convention. Paste any Unix mode into the converter above and you will see the decimal, binary, and hex representations: 0o755 gives 493, 0o644 gives 420, 0o777 gives 511.

Q: What does 0o mean at the start of an octal number? A: The 0o (zero-oh) prefix is the modern way to mark a base-8 numeric literal. It was added to Python 2.6, standardised by ECMAScript 6 (ES2015), and adopted by Ruby, Swift, Rust, and modern C++17. The 0 marks the literal as numeric rather than an identifier, and the o (or O) marks the radix as octal. Before the 0o prefix became universal, C used a bare leading zero (0123) and confusingly shared the prefix with hex (0x123), this two-prefix convention is the source of countless bugs and the reason modern languages standardised on the explicit 0o form. The converter accepts both 0o and bare octal input.

Q: How do I convert decimal to octal? A: Use the general-purpose Number Base Converter on this site, pick decimal as the source base and octal as the target base. The math is decimal.toString(8), prefixed with 0o for clarity. For example, 493.toString(8) returns "755", so the canonical form is 0o755. The reverse direction, octal to decimal, is what this tool does: parseInt("755", 8) returns 493. Note that 493 and 0493 and 000755 and 755 all represent the same value; the converter ignores leading zeros, which is correct semantically but may surprise you if you expected fixed-width formatting for byte dumps.

Q: Why is the maximum input 22 octal digits? A: Twenty-two octal digits encode 66 binary bits, but the relevant boundary is JavaScript's safe-integer range. Number.MAX_SAFE_INTEGER = 9007199254740991, which in octal is 0o777777777777777777777 (twenty-two 7s). Beyond this boundary, JavaScript's Number type cannot represent every integer exactly because Number is a double-precision float with only 53 bits of mantissa precision. The tool caps at 22 octal digits so that the displayed decimal value is always a faithful representation of the input. For values in the 64-bit unsigned range (0 to 0o1777777777777777777777, twenty-three 1s at the top of a 64-bit field, but 22 oct digits is the safe boundary) or 128-bit values (SHA-256 hashes, IPv6 addresses), use a tool that uses BigInt internally rather than Number.

Q: Can this converter handle negative numbers? A: Not directly. The input is parsed as a non-negative integer in the unsigned range 0 to 0o777777777777777777777. If you need to interpret an octal value as a signed integer (two's-complement), the conversion depends on the bit width: a 16-bit signed octal 0o177777 represents -1, a 32-bit signed octal 0o37777777777 represents -1, and a 64-bit signed octal 0o1777777777777777777777 represents -1. To get the signed value, compute value - 2^n where n is the bit width. For 9-bit permissions (the common case), 0o777 is 511 unsigned and −1 if you somehow treated it as a 9-bit signed field, but the file mode interpretation is always unsigned.

Q: Is this converter suitable for cryptographic or security-sensitive work? A: This is a display utility, not a cryptographic primitive. The octal-to-decimal conversion is exact and deterministic for all values in the supported range, so it is fine for reading file permission dumps from ls -l, octal literals in your own source code, assembly code you are studying, and other non-secret data. It is not appropriate for converting secret keys, password hashes, or HMAC outputs in a context where an attacker might observe the conversion, those should use a vetted cryptographic library on a trusted machine with the secrets handled in memory only. The tool runs entirely in your browser and does not transmit your input anywhere.

Q: Can the Octal to Decimal Converter, 0o ⇄ Dec + Binary + Hex (Unix Perm Helper) be used for professional or commercial purposes?erm Helper) be used for professional or commercial purposes? A: Yes, the Octal to Decimal Converter, 0o ⇄ Dec + Binary + Hex (Unix Perm Helper) provides mathematically correct results that are suitable for professional, commercial, and educational use. For high-stakes applications (system administration on production servers, security audit reports, regulatory disclosure of file permission sets), verify the mode interpretations with the platform's chmod and stat documentation. The formulas used are well-established and validated against reference standards (POSIX chmod specification, ECMA-262 parseInt, IEEE 754 double-precision representation).

How often are the Octal to Decimal Converter, 0o ⇄ Dec + Binary + Hex (Unix Perm Helper) formulas updated? ⇄ Dec + Binary + Hex (Unix Perm Helper) formulas updated? A: The formulas are based on established mathematical and standards-track references and rarely require updates. When standards change (new POSIX revisions, revised IEEE 754 boundary documentation, updates to the JavaScript number-precision spec), this calculator is updated to reflect the current authoritative source. For the Octal to Decimal Converter, 0o ⇄ Dec + Binary + Hex (Unix Perm Helper), Each calculator's references section lists the specific sources used.

References

• POSIX.1-2018 (IEEE Std 1003.1-2018), Shell & Utilities volume, chmod specification, defines the octal permission mode digits 0-7 and the read (4), write (2), execute (1) bit weights, plus the symbolic mode grammar.
• ECMA-262, ECMAScript Language Specification, Section 21.1.3.18 parseInt(string, radix), defines the parsing semantics for radix-based integer conversion in JavaScript and every other ECMA-262-compliant runtime; this is the function the tool uses internally.
• IEEE 754, Standard for Floating-Point Arithmetic, defines the 64-bit double-precision representation used by JavaScript's Number type, including the MAX_SAFE_INTEGER = 2^53 - 1 = 0o777777777777777777777 boundary that caps the tool's input length.
• ISO/IEC 9899, C Programming Language Standard, Section 7.8.2.3 strtoul, defines the parsing semantics for leading-zero octal literals in C, which parseInt(s, 8) mimics for plain digit strings.
• The C Programming Language, Kernighan & Ritchie, Appendix B (peripheral documentation on older Unix conventions), the historical context for why Unix chmod uses octal and why the PDP-11's three-bit addressing mode influenced the choice.
• RFC 20, ASCII Format for Network Interchange, IETF, defines the 7-bit character set that this tool's 0o100 → 64 → '@' example references when reading printable-ASCII octal character dumps.