Converting integers between binary, octal, decimal, and custom bases

An integer is the same quantity no matter how you write it. Binary (0b11111111), octal (0o377), decimal (255), and hexadecimal (0xFF) are different radices (bases)—rules for grouping place values—not different numbers. Developers convert bases constantly: bitmasks, file modes, color channels as integers, protocol fields, and short IDs that use digits beyond 9.

This guide explains place-value math, the usual digit alphabet through base 36, language prefixes, and the difference between integer hex and hex as a byte dump. For hands-on conversion with BigInt precision in the browser, use the Radix & Base Converter.

Place value in one minute

In base b, each digit position is a power of b. Reading left to right (most significant digit first):

value = dₙ·bⁿ + dₙ₋₁·bⁿ⁻¹ + … + d₁·b¹ + d₀·b⁰

Each digit d must satisfy 0 ≤ d < b. In base 10, 255 means 2·10² + 5·10¹ + 5·10⁰. In base 16, FF means 15·16¹ + 15·16⁰ = 255. Same value; different grouping.

Base	Name	Digits (common)	Example for 255
2	Binary	0–1	11111111
8	Octal	0–7	377
10	Decimal	0–9	255
16	Hexadecimal	0–9, A–F	FF
36	Base 36	0–9, A–Z	73

Bases above 10 need letters. By convention (and in JavaScript BigInt / Number parsing), A = 10, B = 11, …, Z = 35. Case is usually ignored when parsing; tools often let you emit uppercase or lowercase for readability.

Why these bases show up in software

Binary (base 2)

Hardware and bitmasks live in bits. Flags like “read | write | execute”, feature toggles packed into an integer, and network masks (see Subnet math and CIDR explained) are easiest to reason about in binary—even if you store the value as decimal or hex in config.

Octal (base 8)

Unix file modes (chmod 755) are octal: each digit is three bits (owner/group/other permissions). You rarely need octal elsewhere, but when a doc says “mode 0644,” it means base 8, not decimal 644.

Decimal (base 10)

Humans and most APIs default to decimal. Prefer decimal in UI copy and logs unless the domain is inherently bit-oriented.

Hexadecimal (base 16)

Four bits map cleanly to one hex digit, so hex is compact for addresses, color integers (0xFF5500), machine code, and many protocol fields. Note: integer 0xFF (255) is not the same concept as a UTF-8 hex dump of the character “ÿ” or a two-byte sequence—see Hex encoding: UTF-8 bytes explained.

Custom bases (11–36)

Short codes, some license-key alphabets, and “base36 IDs” use digits past F. Base 36 uses the full 0–9A–Z set. Bases above 36 need a custom alphabet; most general converters (including LocalTools) stop at 36, matching common language libraries.

Language prefixes: 0b, 0o, 0x

Many languages accept literal prefixes so the parser knows the base without a separate argument:

Prefix	Base	Example	Decimal
0b / 0B	2	0b11111111	255
0o / 0O	8	0o377	255
0x / 0X	16	0xFF	255
(none)	10	255	255

Underscores (0b1111_1111) and spaces are often allowed in source for readability. A converter that strips _ and whitespace before parsing matches how you paste from editors and docs.

Pitfall: The prefix only makes sense when the source base matches. Pasting 0xFF while the tool is set to base 10 should fail or mis-parse unless the UI specially detects prefixes. LocalTools’ Radix & Base Converter strips 0x / 0b / 0o when the selected input base is 16, 2, or 8 respectively.

How conversion actually works

You do not convert “digit by digit” between arbitrary bases. The reliable algorithm is:

1. Parse the input string in the source base → an exact integer (ideally a BigInt, not a float).
2. Format that integer in the target base by repeated division: remainder → next least-significant digit, quotient → continue until zero.

That two-step approach avoids errors when going from base 7 to base 13 (or any pair). Floating-point Number in JavaScript is unsafe above Number.MAX_SAFE_INTEGER (2⁵³ − 1); for large IDs and crypto-sized integers, BigInt (or another arbitrary-precision type) keeps every digit exact.

Fractions (e.g. 0.1 in decimal vs binary) are a different problem: terminating in one base may be repeating in another. Integer converters correctly refuse fractional input—do not expect them to round or truncate decimals.

Worked example: 0xFF → binary, octal, decimal

Start with hex FF (base 16):

• Parse: 15·16 + 15 = 255 (decimal).
• Binary: 255 = 11111111₂ (eight ones).
• Octal: 255 ÷ 8 = 31 rem 7; 31 ÷ 8 = 3 rem 7; 3 ÷ 8 = 0 rem 3 → 377₈.

So 0xFF = 0b11111111 = 0o377 = 255. Round-tripping any of those strings back through the same integer should recover the others.

Another quick check—file mode 755 octal:

• Digits 7, 5, 5 → 7·8² + 5·8¹ + 5·8⁰ = 448 + 40 + 5 = 493 decimal.
• Binary: often written in three bit groups for permissions: 111 101 101.

Integer hex vs byte hex (don’t mix them)

	Integer in hex	Bytes as hex
Meaning	One whole number	A sequence of 8-bit values
Example	0xFF → 255	48 65 6c 6c 6f → UTF-8 for Hello
Length	Arbitrary digit count	Even count of hex digits (two per byte)
Tooling	Radix converter	Hex encoder/decoder

Writing the integer 255 as hex (FF) is radix conversion. Encoding the text "255" or a binary buffer is encoding bytes. Same digit characters, different jobs—mixing them causes off-by-one and endianness confusion in protocols.

Common pitfalls

• Invalid digits for the base: 9 is illegal in octal; G is illegal in hex; 2 is illegal in binary. Good tools report which character failed.
• Leading zeros: 0x00FF and 0xFF are the same integer; leading zeros are formatting, not value (except when a fixed width is part of a protocol layout—then you are in byte/field territory again).
• Signed values: A leading - is a sign on the integer, not a digit. Two’s-complement bit patterns for negative numbers are a separate representation used in machine words; plain radix conversion of -255 prints a minus and the magnitude in the target base.
• Assuming hex hides secrets: Changing base is reversible and not encryption. For privacy of sensitive numbers, prefer local tools (why local-only matters) and never paste production secrets into untrusted online converters.
• Base 64 confusion: “Base64” is an encoding of byte sequences, not integer radix-64 with a standard digit alphabet in the same sense as bases 2–36. Do not feed Base64 strings into a radix converter expecting a single integer.

Try it locally

The Radix & Base Converter runs entirely in your browser:

• Paste an integer and set the input base (2–36).
• Read binary, octal, decimal, and hex plus an optional extra output base.
• Use 0x / 0b / 0o, underscores, and spaces where they match the selected base; toggle uppercase A–Z for bases above 10.
• Conversion uses JavaScript BigInt, so large integers stay exact—nothing is uploaded.

For UTF-8 dumps and spaced hex bytes, use the Hex Encoder & Decoder instead. For bitmask-oriented network prefixes, see the Subnet Calculator.

Related reading

• Hex encoding: UTF-8 bytes explained — hex as a view of bytes, not as an integer radix alone.
• Subnet math and CIDR explained — binary place values applied to IPv4 prefixes.
• Why “local only” matters for developer tools — why keeping conversions on-device matters for sensitive values.