Rapidtable

Think of a number as a way of recording how many of each denomination you have, like counting coins. In decimal you have 1s, 10s, 100s, and 1000s — each column is ten times the one to its right. In binary the denominations are 1, 2, 4, 8, 16, 32 — each column is twice the next. When a bit is 1 that denomination contributes to the total; when it is 0 it does not. The decimal number 13 becomes 1101 in binary because 8 + 4 + 0 + 1 = 13.

Hexadecimal is shorthand for binary. Because 16 is exactly 2 to the power of 4, every hex digit maps perfectly to a 4-bit nibble. This is why hex dominates memory addresses, color codes, and CPU opcodes — it is binary without the visual clutter. The hex value 3F expands directly to binary 0011 1111 with no arithmetic required. Octal, base 8, uses the same principle with 3-bit groups, and historically appeared in Unix permissions and early PDP architectures.

When you enter a value, the tool calls JavaScript parseInt() with the source base as the radix, converting to a native integer in one step. It then calls toString() with each target radix to produce the output. Every result is exact — there is no approximation. The only precision loss possible is if you enter a number larger than JavaScript can represent as a safe integer (above 2 to the 53rd power), which is far beyond the 32-bit range this tool flags as a boundary.

Use this tool when you need to cross-reference a value across multiple representations simultaneously. Common situations: reading or writing CPU register values in a datasheet, verifying bitmasks in embedded C or assembly, decoding hex color codes into their RGB components, checking Unix file permissions written in octal, or confirming that a protocol value you are hard-coding matches the binary pattern described in a spec.

This tool is also useful when learning. If you are new to number bases, seeing 255 equal to FF equal to 11111111 equal to 377 side by side builds intuition faster than any textbook explanation. The bit length output helps you understand why two hex digits always represent a byte, or why three octal digits can always represent nine bits.

This tool is not appropriate for floating-point numbers, signed integers with two's complement representation, or arbitrary-precision arithmetic beyond 32 bits. If you need IEEE 754 float decomposition, two's complement encoding for negative numbers, or BCD (binary-coded decimal) conversions, a dedicated tool built for those formats will give you more reliable results. Entering a decimal fraction here will silently truncate the fractional part.

Mixing up source and target base is the most common error. If your input is actually hex but you leave the selector on decimal, the tool parses letters as invalid characters and shows a warning. Always set the input base to match what you copied from your source — a register dump, a color picker, or a permission string. The output bases are fixed and always show all four representations simultaneously.

Ignoring bit width when it matters causes subtle bugs. A value of 5 in natural binary is 101 — three bits. In an 8-bit register it is 00000101. If you are writing a bitmask, combining values with bitwise OR, or parsing a protocol field, the position of each bit depends on the full fixed-width representation. Forgetting to pad means you silently misread which bits are set. Use the 8-bit or 16-bit padding option any time you are working with a fixed-width register or field.

Treating hex letters as case-sensitive is an error in context, not in math. 0xFF and 0XFF and 0xff are all 255 in any language. The tool accepts both cases on input. Its output uses uppercase A-F, which is the convention in Intel datasheets and most C toolchains. If your target system requires lowercase, just lowercase the result string — the numeric value is identical.

Base conversion is positional arithmetic. A number N written in base B as digits d_n d_{n-1} ... d_1 d_0 has decimal value equal to the sum of each digit multiplied by B raised to its position index. For binary 1011: 1x8 + 0x4 + 1x2 + 1x1 = 11. To go the other direction — decimal to binary — repeatedly divide by 2 and record remainders from last to first. 11 divided by 2 is 5 remainder 1; 5 / 2 is 2 r 1; 2 / 2 is 1 r 0; 1 / 2 is 0 r 1. Reading remainders bottom to top: 1011.

Hex conversion exploits the fact that 16 = 2^4. Group binary bits into sets of four from the right, pad the leftmost group with leading zeros if needed, then substitute each group for its hex digit. Binary 10110111 groups as 1011 0111, which is B7 in hex. Reversing it: replace each hex digit with its 4-bit binary equivalent and concatenate. This shortcuts all the arithmetic.

Octal works the same way but groups binary in threes (8 = 2^3). Binary 10110111 groups as 010 110 111, which is 267 in octal. The direct decimal-to-hex and decimal-to-octal paths use repeated division by 16 or 8 and collect remainders, identical in structure to the binary method. The tool handles all paths via the radix parameter in JavaScript parseInt and toString, which are themselves implemented using these exact algorithms.

The tool uses JavaScript parseInt() which, for bases 2 through 36, is spec-compliant and exact for values within the safe integer range (2^53 - 1). One edge case worth knowing: parseInt ignores trailing non-digit characters rather than erroring. If your input string contains a space or a prefix like 0x, the tool strips and validates before parsing to prevent silent misreads. For values above 2^32 the math is still correct but no standard CPU register size maps to it, which is why the 32-bit boundary warning exists. If you are working with 64-bit pointers or hashes, switch to BigInt-aware tooling and treat this tool as a sanity check only for the lower 32 bits.