Developer Tool

Number Base Converter

Convert any number between binary, octal, decimal, hexadecimal, and every base up to 36, with the full division work and a two's complement signed view.

Systems programmers, network engineers, embedded developers, and students read and write numbers in more than one base every day: hex byte dumps in a debugger, binary masks in a datasheet, octal permissions in a shell, decimal values in an API. When to use it: Translating a register value from a logic analyzer, checking the decimal behind a hex error code, converting an IPv4 octet to binary for a subnet calculation, or walking a student through long division into hex. What it solves: Takes a value in any base from 2 to 36, validates every digit against that base, converts with exact BigInt arithmetic, shows the division remainders that produce the answer, and offers a two's complement panel for signed readings. Why it matters: One wrong digit or a JavaScript number that silently lost precision past 2\u2075\u00b3 can turn into a bug that only shows up in production. Everything here runs locally, so unreleased identifiers and internal addresses never leave the tab.

Value

From base

To base

Group digits in 4s

Result (target base)

Decimal value

Grouped result

Two's Complement View

Bits: 00000000 00000000 00000000 00000000
Unsigned: 0
Signed: 0

Conversion Steps

How Base Conversion Works

The converter first normalizes your input: whitespace is trimmed, a leading sign is recorded, and a 0x, 0b, or 0o prefix is stripped so the remaining characters can be validated as digits. Every digit is checked against the source base using the classic 0-9 then A-Z character set, and the first illegal character stops the conversion with a message that names both the character and the legal set.

Valid digits are accumulated into a BigInt using positional math: start at zero, multiply by the base, and add the digit value, repeating left to right. BigInt keeps every digit exact, so 64-bit constants such as FFFFFFFFFFFFFFFF convert without the rounding that hits plain floating-point numbers above 2\u2075\u00b3. Output works in reverse: repeated division by the target base collects remainders, and each remainder maps to one output digit.

The steps panel records every division with its quotient and remainder, labeled with the digit that remainder represents. When the source base is not the target base, the chain shows the value in decimal first, then the division loop. This is the same procedure a person follows on paper, so the output doubles as a worked example for learning or for checking a manual conversion.

Grouping inserts a space every four digits from the right, which makes long binary strings scannable in fours the way hex bytes pair up. It only affects presentation, never the value.

The two's complement panel takes the decimal value, wraps it modulo 2 to the power of the chosen width, and prints the fixed-width bit pattern plus both readings: the unsigned integer and the signed interpretation where the top bit is negative. That is exactly how a CPU, a network packet, or a C struct will interpret the same bits.

Before / After Examples

Example 1: Decimal to Hexadecimal with Steps

Before (Decimal input)

255   (base 10)

<!-- What is this in hex? -->

After (Hex result + division chain)

ff   (base 16)

255 ÷ 16 = 15 remainder 15 (digit "F")
15 ÷ 16 = 0  remainder 15 (digit "F")
Read remainders bottom-up: FF

Example 2: Binary Register Value to Hex

Before (Binary from a datasheet)

0b10110110

<!-- 8 status flags in a control register -->

After (Hex and decimal readings)

hex:      b6
decimal:  182
grouped:   1011 0110

<!-- Groups of 4 make the byte readable -->

Example 3: Signed 8-bit Reading

Before (Unsigned value from a log)

255   (base 10)
32-bit view: 00000000 00000000 00000000 11111111

<!-- Looks like a large positive number -->

After (8-bit two's complement)

bits:    11111111
unsigned: 255
signed:   -1

<!-- Same bits, different width, negative reading -->

Use Cases

Developer	Production	Workflow
Convert hex register values to binary when reading a datasheet	Decode hex error codes from production logs	Check homework division chains against a worked answer
Translate ASCII or Unicode code points from decimal to hex	Verify byte patterns in a network packet capture	Plan CIDR ranges by hand with octet-level binary
Read signed sensor readings using the two's complement panel	Compare checksums and CRC values written in hex	Document bit flags for an internal API specification
Convert base36 identifiers to decimal for database keys	Audit file permissions shown in octal against expected modes	Teach positional notation with live step-by-step output

Common Mistakes & Troubleshooting

Losing precision on values above 2\u2075\u00b3

JavaScript numbers are 64-bit floats, so 9007199254740993 can silently become 9007199254740992 during arithmetic. Crypto constants, snowflake IDs, and IPv6 halves all live in that range. This converter uses BigInt, but code you write with plain Number does not.

❌ (0xFFFFFFFFFFFFF9 + 8).toString(16)  // precision loss
✅ BigInt("0xFFFFFFFFFFFFF9") + 8n       // exact result

Forgetting which end of the byte string is least significant

Grouping displays digits from the right, matching positional value. When a protocol specifies little-endian byte order, the byte you see first on the wire is the least significant one, and reversing bytes during a manual conversion flips the number entirely.

❌ Assume printed hex order == wire order
✅ Check the spec for endianness before converting

Mixing up base 16 with base64 encoding

Hexadecimal is a base-16 numeral system that represents binary in 4-bit groups. Base64 is a text encoding that represents bytes in 6-bit groups using 64 characters. They solve different problems, and pasting base64 text into a number converter will fail digit validation.

❌ Treat "SGVsbG8=" as a base-16 number
✅ Hex for numeral conversion, Base64 Encoder for byte text

Dropping the sign when a protocol expects unsigned words

Writing -1 where the format stores an unsigned 16-bit field breaks parsing. The two's complement panel shows the wrap: for 16 bits, -1 corresponds to FFFF, and for 32 bits, FFFFFFFF. Convert with the target width in mind rather than pasting the signed decimal.

❌ Field expects u16, you write -1
✅ Convert with 16-bit width → FFFF

Picking the wrong source base and trusting a confident answer

Entering 1010 as base 10 gives 1010, while entering it as base 2 gives 10. The converter cannot guess your intent, which is why the digit-validity check exists. If a value contains A-F letters, the source base must be at least 16, and the tool will tell you which character failed.

❌ 1010 in base 10 "converted" to hex = 3F2
✅ Set the source base to 2 first, get 0xA

Best Practices

✓

Write literals with explicit prefixes

In code, 0x1F, 0b1001, and 0o777 state the base in the literal itself. Reviewers and compilers never have to guess, and accidental base confusion disappears.

✓

Switch to BigInt past 2\u2075\u00b3

Any identifier, address, or mask that can exceed 9007199254740991 should be parsed and stored as BigInt, not Number, in JavaScript code.

✓

Annotate width for signed values

When a hex value might be negative, record the width it was read from (int8, int16, int32). Without the width, FF is either 255 or -1 and both readings are defensible.

✓

Group binary in fours for manual review

Each hex digit is exactly four binary digits. Grouping 11001101 as 1100 1101 lets you read C and D directly instead of counting bits.

✓

Round-trip as a sanity check

Convert base 10 to base 16 and back for critical values. A round trip that returns the original number rules out a wrong source-base setting.

✓

Match the case your format requires

Some protocols want uppercase hex (0xCAFE), others lowercase (cafe). Most parsers accept both, but file paths, checksum strings, and golden test fixtures often do not.

✓

Keep one base end-to-end in a document

Mixing hex and decimal in the same table invites transcription errors. Pick one base per column and label it in the header.

✓

Preserve the division steps when teaching

The steps output mirrors the manual method, so copy it into notes or a lesson instead of only writing the final digits.

Frequently Asked Questions

What is the difference between binary, decimal, and hexadecimal? +

Binary (base 2) uses only the digits 0 and 1, decimal (base 10) uses digits 0 through 9, and hexadecimal (base 16) uses 0 through 9 plus letters A through F. The base tells you how many unique digits a positional number system uses, and each position represents a power of that base. Binary maps naturally onto bits in hardware, decimal matches how humans count, and hexadecimal is a compact way to write binary because every four bits become one hex digit.

How do you convert a decimal number to hexadecimal by hand? +

Divide the number by 16 repeatedly and record the remainder of each division. The first remainder is the least significant hex digit, and the last quotient under 16 is the most significant digit. Read the remainders in reverse order to get the result. For example, 255 divided by 16 gives 15 remainder 15, and 15 divided by 16 gives 0 remainder 15, so the digits are F then F, giving 0xFF. The steps panel in this tool shows that exact chain.

What does the 0x prefix mean in a number like 0x1F? +

The 0x prefix marks a hexadecimal literal in C, C++, Java, JavaScript, Rust, and most configuration formats. Variants exist: 0b marks binary, 0o marks octal, and some languages accept a trailing h for hex. This tool detects those prefixes automatically, so you can paste 0x1F with the source base set to 16 and it will be read correctly. If a tool or language does not recognize the prefix, strip it before parsing.

What is two's complement and why does the signed view matter? +

Two's complement is how computers store signed integers: the most significant bit acts as the sign bit, and negative values are represented as the bit pattern of 2⁻¹ minus the absolute value. For an 8-bit width, the value 255 and the value -1 share the same bit pattern 11111111, because 256 minus 1 equals 255. The signed panel shows both interpretations so you can tell whether a hex value from a register, log, or file is meant to be read as unsigned or signed.

Why do large numbers convert incorrectly in some calculators? +

JavaScript (and many calculators) store numbers as 64-bit floating point values, which means integers above 2⁵³ − 1, or 9007199254740991, lose precision because there is no longer a distinct representable value between consecutive integers. This tool uses BigInt internally, which keeps every digit exact for values of any size, including 64-bit and 128-bit constants used in cryptography and network addressing. If a conversion looks off by one in another tool, precision loss is the usual cause.

Which bases does this converter support? +

Any base from 2 to 36 is supported. Bases up to 10 use digits 0 through 9, and bases above 10 continue with letters: A is 10, B is 11, up to Z as 35. Common choices like binary (2), octal (8), decimal (10), and hexadecimal (16) are used constantly in systems work, while higher bases appear in base32 and base36 identifier schemes. The digit-validity check tells you exactly which characters are legal for the base you picked.

Does this tool send my input to a server? +

No. The conversion logic is plain TypeScript running in your page, with no fetch calls and no form submission. Your input, the intermediate steps, and the result all stay in the browser tab and disappear when you close it. That makes it safe to paste internal identifiers, financial figures, or unreleased configuration values that you would not put into a hosted converter.