CodeToolProCodeToolPro
GitHub
Converters·7 min read

Number Base Converter Guide: Binary, Hex, Octal & Decimal

CodeToolPro Team·

Number Base Converter Guide: Binary, Hex, Octal & Decimal

Every developer eventually stares at a value like 0xCAFEBABE, a file mode of 755, or a bitmask printed as 11001010 and has to translate it into something human-readable. A number base converter does that instantly and in every direction at once. Try it with our Number Base Converter — type a value into any of the four fields and the other three update live.

This guide covers what a base actually is, why developers keep bouncing between radix 2, 8, 10 and 16, what happened when I ran real values through the tool, and the conversion bugs that quietly corrupt data in production code.

What Is a Number Base?

A base (or radix) is how many distinct digits a positional numbering system uses. The value itself never changes — only its written representation does.

BaseNameDigits3,405,691,582 written in it
2Binary0–111001010111111101011101010111110
8Octal0–731277535276
10Decimal0–93405691582
16Hexadecimal0–9, A–FCAFEBABE

Base conversion is lossless for integers. 0xFF, 255, 0o377 and 0b11111111 are not four similar numbers — they are one number with four spellings.

Hexadecimal earns its popularity from a clean mapping: one hex digit is exactly four bits, so any hex string splits into nibbles with no arithmetic. Octal has the same property with three bits, which is why Unix file permissions still use it decades later.

Why Developers Switch Between Bases

Four situations account for almost all real-world conversions:

  1. Bitmasks and flags — binary makes it obvious which bits are set. 0b1111 1111 0000 is readable; 4080 is not.
  2. Memory, colors and hashes — hex dumps, #3B82F6 color literals, and SHA digests are all hex because bytes map to pairs of hex digits.
  3. Unix permissions — chmod 755 is octal, where each digit is a three-bit rwx triple.
  4. Protocol and wire formats — magic numbers, opcodes and endianness debugging are almost always specified in hex.

Hands-on: Tested with the Tool

I ran the following through Number Base Converter. The tool opens with 42 already loaded and the Format number switch turned on, so grouping separators appear immediately.

Test 1 — the default value. With 42 in the Decimal field, the other three fields read:

FieldValue
Decimal42
Hexadecimal2A
Octal52
Binary10 1010

Test 2 — typing into the Hexadecimal field. I cleared it and typed CAFEBABE. All three other fields recomputed instantly:

Decimal:     3,405,691,582
Hexadecimal: CAFE BABE
Octal:       31 277 535 276
Binary:      1100 1010 1111 1110 1011 1010 1011 1110

Note the grouping rules the tool applies: decimal uses commas every three digits, hexadecimal and binary use spaces every four, octal uses spaces every three. Flipping Format number to Off returns the raw strings (3405691582, CAFEBABE, 31277535276, 11001010111111101011101010111110).

Test 3 — pasting a pre-grouped binary string. I pasted 1111 1111 0000 into the Binary field. The spaces were stripped before parsing and the result was Decimal 4,080, Hexadecimal FF0, Octal 7 760. Grouped values you copy out of the tool can be pasted straight back in.

Test 4 — a value larger than a JavaScript number. I typed 18446744073709551615 (2⁶⁴ − 1) into Decimal and got Hexadecimal FFFF FFFF FFFF FFFF and 64 binary ones — exact, with no rounding. The tool parses with BigInt, so 64-bit IDs and hashes survive intact.

Test 5 — invalid characters. Typing G into the Hexadecimal field, 8 into Octal, 2 into Binary, or - into Decimal produced no change at all: the input is validated per base and rejected keystrokes are ignored rather than silently coerced. Lowercase hex is accepted (cafe parses to 51966) and output is normalised to uppercase.

Test 6 — Unix permissions. Typing 755 into the Octal field gave Decimal 493 and Binary 1 1110 1101 — the 111 101 101 rwx triples, just regrouped into nibbles. For the permission view specifically, the Unix Permissions Calculator is the better tool.

Doing It in Code: JavaScript and Python

Both languages convert with built-ins. Every output below is from an actual run.

const n = 3405691582n;              // BigInt literal

n.toString(16).toUpperCase();       // "CAFEBABE"
n.toString(8);                      // "31277535276"
n.toString(2);                      // "11001010111111101011101010111110"

BigInt("0xCAFEBABE");               // 3405691582n
BigInt("0o755");                    // 493n
BigInt("0b11111111");               // 255n

// Group hex into nibble pairs, like the tool's Format switch
const group = (s, size, sep) => {
  const head = ((s.length - 1) % size) + 1;
  const out = [s.slice(0, head)];
  for (let i = head; i < s.length; i += size) out.push(s.slice(i, i + size));
  return out.join(sep);
};
group(n.toString(2), 4, " ");       // "1100 1010 1111 1110 1011 1010 1011 1110"

n = 0xCAFEBABE                      # 3405691582

format(n, "X")                      # 'CAFEBABE'
format(n, "o")                      # '31277535276'
format(n, "b")                      # '11001010111111101011101010111110'
format(n, "_X")                     # 'CAFE_BABE'  (built-in grouping)
format(255, "#010b")                # '0b11111111' (zero-padded)

int("CAFEBABE", 16)                 # 3405691582
int("755", 8)                       # 493
int("0b11111111", 0)                # 255  (base 0 = infer from prefix)

Python integers are arbitrary precision by default, so format(2**64 - 1, "X") returns FFFFFFFFFFFFFFFF with no extra work. JavaScript needs BigInt for the same guarantee.

Common Pitfalls

parseInt stops at the first invalid character instead of failing. parseInt("CAFEG", 16) returns 51966 — it silently parsed CAFE and dropped the rest. Number("CAFEG") returns NaN, which is at least detectable. Python is strict: int("CAFEG", 16) raises ValueError.

parseInt with an explicit base can still be wrong. parseInt("08", 8) returns 0, because 8 is not a valid octal digit and only the leading 0 is consumed. Python raises ValueError for the same input.

Leading zeros no longer mean octal. Number("0755") is 755 in JS, and int("0755") is 755 in Python. Parse permission strings with an explicit base 8 or you will be off by a factor of roughly 1.5.

Doubles lose precision above 2⁵³ − 1. Number("18446744073709551615") evaluates to 18446744073709552000 — wrong by 1,385. Snowflake IDs, 64-bit hashes and database bigints must be handled as BigInt or strings, never as plain JS numbers. This is exactly why the converter parses with BigInt internally.

Signedness is not part of the representation. FFFFFFFF is 4,294,967,295 as an unsigned 32-bit value and −1 as a signed one. A base converter shows the unsigned reading; deciding the interpretation is still your job.

Related Tools

If you arrived here from color work rather than bit twiddling, our HEX vs RGB comparison covers hexadecimal in the context of CSS colors, and the Color Converter handles those conversions directly.

When to Use This Tool Instead of Code

Reach for Number Base Converter when the conversion is a one-off in the middle of another task: decoding a magic number from a hex dump, checking which bits a feature flag sets, sanity-checking a permission value in a code review, or confirming that a 64-bit ID round-trips correctly. Opening a REPL and squinting at ungrouped output takes longer than typing the value into a field — and the grouped display catches transposed digits that a solid 32-character string hides.

Write code instead when the conversion happens more than once: parsing a protocol, formatting log output, or validating user input all need the error handling and test coverage that only real code provides. A converter is a debugging instrument, not a replacement for your parsing layer.