Base Conversion Tool
Convert between binary, octal, decimal, hexadecimal and custom number bases instantly
Input Base
What is Number Base Conversion?
Number base conversion is the process of changing a number from one numeral system to another. Common bases include binary (base-2), octal (base-8), decimal (base-10), and hexadecimal (base-16).
In computer science, binary is the most fundamental number system since all data inside computers is stored in binary. Hexadecimal is widely used for memory addresses and color values because it is more compact and readable than binary. Octal is commonly used in Unix file permissions and other contexts.
A base converter helps read or compare values across decimal, binary, octal, hexadecimal, or other numeral systems. Common cases include programming, bit masks, memory addresses, color values, protocols, teaching, and embedded development. The main caveats are sign handling, prefixes such as 0x, leading zeros, grouping, and the maximum integer size of the target system. A mathematically correct conversion may still differ from how a programming language stores signed or overflowing values.How to Use
How to use
- Enter the number you want to convert in the input field (e.g., 255, FF, 11111111)
- Select the base of your input number: binary, octal, decimal, hexadecimal, or a custom base
- The tool automatically converts the input to binary, octal, decimal, and hexadecimal results
- Click the "Copy" button next to any result to copy it to your clipboard
Conversion Tips
- Make sure the input digits are valid for the selected base; for example, binary only accepts 0 and 1, while hexadecimal accepts 0-9 and A-F.
- Large integers may exceed JavaScript's safe number range in some workflows, so verify critical engineering values with a dedicated arbitrary-precision tool.
Use Cases
Technical Principle
Base conversion is positional notation arithmetic. A digit d at position p in base b contributes d × bᵖ to the total value, and the value of an N-digit number is Σᵢ₌₀..N₋₁ dᵢ × b^(N-1-i). The decimal system is base 10, binary is base 2, octal is base 8, hexadecimal is base 16. Two algorithms do all the work: to convert from base b₁ to base 10, evaluate the polynomial (Horner's method is the standard in-place form: `value = value * b₁ + digit`); to convert from base 10 to base b₂, repeatedly divide by b₂ and collect the remainders, then reverse them. Both algorithms are O(N) per digit and O(1) in extra space, and they work for any base from 2 to 36 (digits '0'-'9' + 'A'-'Z' as 10-35). Most practical base-conversion work skips the intermediate decimal step and goes directly between bases that are powers of two. Binary ↔ octal groups 3 binary digits per octal digit (because 2³ = 8), and binary ↔ hex groups 4 binary digits per hex digit (2⁴ = 16). This is why 0xFF = 11111111₂, 0755 (octal, the Unix file mode) = 111101101₂ = 493 decimal. The page also handles base 32 (RFC 4648 §6, used in some authentication tokens) and base 36 (the traditional compact URL shortener alphabet '0'-'9' + 'A'-'Z'), where the conversion to binary is the only sensible way to go since 36 is not a power of 2. This page uses JavaScript's built-in parseInt(value, base) for parsing and (123).toString(base) for output. Both are limited to Number precision: an IEEE 754 binary64 has a 53-bit mantissa, so integer values larger than 2⁵³ - 1 = 9,007,199,254,740,991 lose precision. For example, Number.MAX_SAFE_INTEGER + 1 equals Number.MAX_SAFE_INTEGER + 2 — the two large values are not representable. For arbitrary-precision integer base conversion, BigInt is the modern path: parseInt-style logic in BigInt is straightforward, and BigInt.prototype.toString(base) handles any base from 2 to 36. Crypto libraries, UUID generators, and big-num math (BIP-32 HD wallets, RSA keys) all use BigInt for this reason. The same algorithm also handles signed numbers and floating-point, with caveats. In two's complement (the dominant signed representation for fixed-width integers, from the 1965 IBM System/360 design through every modern CPU), -1 is all-ones (0xFFFFFFFF for 32 bits, 0xFFFFFFFFFFFFFFFF for 64), and the highest bit is the sign bit. To convert a negative two's-complement integer to decimal, subtract 2ⁿ (where n is the bit width). For floating-point numbers, IEEE 754 binary64 stores sign (1 bit), exponent (11 bits, biased by 1023), and mantissa (52 bits, with an implicit leading 1). The decimal conversion of an arbitrary binary64 is therefore not exact — 0.1 in IEEE 754 is 0.1000000000000000055511151231257827021181583404541015625, which is why financial code uses integer cents or decimal libraries instead of float.
- Positional notation: a digit d at position p in base b contributes d × bᵖ. The full value of an N-digit number is Σᵢ dᵢ × b^(N-1-i). Horner's method evaluates this in O(N) time and O(1) space: `value = value * b + digit`.
- To convert from decimal to base b, repeatedly divide by b and collect the remainders; reading them in reverse gives the target representation. Algorithm is O(N) for an N-digit output.
- Direct binary ↔ hex conversion: each hex digit is exactly 4 binary digits, so 0xFF = 11111111₂. Binary ↔ octal: each octal digit is 3 binary digits, so 0755 = 111101101₂.
- Two's complement (used by every modern CPU for signed integers): the high bit is the sign, and negative numbers are encoded as 2ⁿ - |x|. -1 in 32-bit two's complement is 0xFFFFFFFF.
- IEEE 754 binary64 (JavaScript Number): 1 sign bit + 11-bit biased exponent (bias 1023) + 52-bit mantissa with implicit leading 1. Maximum safe integer is 2⁵³ - 1 = 9,007,199,254,740,991; values above this lose precision.
- parseInt(value, base) and Number.prototype.toString(base) work for bases 2-36 and use the 53-bit Number mantissa. For arbitrary precision, use BigInt('value', base) and BigInt.prototype.toString(base).
- Base 32 (RFC 4648 §6) and Base 36 ('0'-'9' + 'A'-'Z') need binary as the intermediate step because 32 and 36 are not powers of 2 — a digit does not correspond to a fixed number of bits.
- Edge case: integer division with remainder for negative bases or for negative numbers in two's complement needs sign handling; the page treats input as an unsigned absolute value and re-applies the sign to the final result.
Examples
Decimal to Hexadecimal
Input: 255 (decimal)
Output: FF (hexadecimal)
Note: commonly used in CSS color values, e.g. #FF0000 for redBinary to Decimal
Input: 11111111 (binary)
Output: 255 (decimal)
Note: maximum value of 8-bit binary, i.e. the largest unsigned byteHexadecimal to Binary
Input: 1A3F (hexadecimal)
Output: 1101000111111 (binary)
Note: every 4 binary digits correspond to 1 hexadecimal digitOctal to Hexadecimal
Input: 377 (octal)
Output: FF (hexadecimal)
Note: Unix permission 377 (rwxrwxrwx) equals hex FFCustom Base (Base-36)
Input: ZZ (base-36)
Output: 1295 (decimal)
Note: base-36 uses 0-9 and A-Z; ZZ is the largest 2-digit value in that systemFAQ
Which bases are supported?
Binary (base 2), octal (base 8), decimal (base 10), hexadecimal (base 16), and arbitrary custom bases from 2 to 36. Bases above 36 require an extended alphabet and are out of scope here.
How are letters used in higher bases?
Bases above 10 use letters: A=10, B=11, … F=15 in hex; A=10 through Z=35 in base 36. Both upper and lowercase work for input; output is uppercase by default.
How do I convert a negative or fractional number?
Negative integers work directly - the page stores them as JavaScript BigInt or signed integers internally. Fractional values (e.g. 0.5 in decimal → 0.1 in binary) are supported but limited to roughly 15 significant digits because of floating-point precision.
What's the difference between two's complement and signed magnitude?
Two's complement is how computers represent negative integers - the high bit means negative and the rest encodes the value plus an offset. Signed magnitude just flips a sign bit. The page typically displays signed magnitude (decimal-like sign), not the bit pattern. Use a programmer-mode calculator if you need to see two's complement.
Why does my hex result have different padding than another tool?
Hex values may or may not be left-padded to a byte/word boundary. 0xff and 0x000000FF are the same number, just displayed with different padding. The page does not auto-pad; add leading zeros manually if your context (e.g. fixed-width MAC address, IPv6 segment) requires them.
Are there limits on the number size?
JavaScript BigInt handles arbitrarily large integers, so converting between integer bases works for numbers of any practical length. Fractional conversion is limited by Number's 15-17 significant digits.
Can I convert IP addresses or colour codes here?
Indirectly: convert each byte separately. For dotted-quad IPs, convert each octet from decimal to hex; for #RRGGBB colour codes, split into three byte pairs. Dedicated IP and colour tools handle the parsing for you.