Number Base Converter

Binary, octal, decimal, and hexadecimal aren't fundamentally different systems — they're the same positional notation idea (each digit's position represents a power of the base) using different-sized digit alphabets. Binary has 2 symbols (0-1), octal has 8 (0-7), decimal has 10 (0-9), and hexadecimal has 16 (0-9 plus A-F for the extra six values). The number itself — the actual quantity — never changes across a conversion; only its symbolic representation does, the same way '12' and 'twelve' represent an identical quantity in different notations.

This is why converting between bases is really just re-expressing one underlying integer value, not performing a mathematical operation on it in any transformative sense.

| Base | Name | Digit alphabet | Common prefix |

| --- | --- | --- | --- |

| 2 | Binary | 0-1 | 0b |

| 8 | Octal | 0-7 | 0o |

| 10 | Decimal | 0-9 | (none) |

| 16 | Hexadecimal | 0-9, A-F | 0x |

Type your number in the input field.

Pick the source base: binary, octal, decimal, or hex.

All four conversions update instantly — copy any of them with one click.

JavaScript's standard number type can only represent integers exactly up to 2^53 (about 9 quadrillion) before it starts silently losing precision — beyond that point, distinct large integers can round to the same floating-point representation, and a converter built on ordinary numbers would produce subtly wrong results for large hex or binary values without any visible error. This matters more for a base converter than almost any other calculation, because the whole point of hex and binary in real development work is often representing large values precisely: memory addresses, hash outputs, cryptographic values, bit flags spanning 64 bits or more — exactly the range where ordinary JavaScript numbers start to fail silently.

This tool uses BigInt instead, JavaScript's arbitrary-precision integer type, so conversions stay exact regardless of how large the number is — there's no upper bound imposed by floating-point precision limits.

You can type a hex value as either 1A3F or 0x1A3F — the tool auto-detects the 0x, 0b, and 0o prefixes and strips them before conversion, so including or omitting them produces identical results. This matters because real-world hex and binary values are inconsistently prefixed across contexts: some languages and tools always show the prefix, others never do, and copy-pasting a value from code versus from documentation often means switching prefix conventions. Not having to manually strip a prefix before pasting saves a genuinely annoying manual step.

This converter is deliberately integer-only, and that's a scope decision rather than a limitation that crept in unintentionally. Converting a fractional number between bases correctly requires arbitrary-precision decimal arithmetic — the fractional part of a number doesn't always terminate cleanly when re-expressed in a different base (0.1 in decimal, for instance, has no exact finite binary representation, which is the classic source of floating-point rounding quirks in programming). Supporting that correctly is a meaningfully different and heavier problem than integer conversion, and it's a need that rarely comes up in the developer contexts this tool targets — reading memory addresses, working with bit flags, converting IDs — which are essentially always integer-based.

A leading minus sign is recognized and preserved consistently across all four output bases — negative decimal converts to a negative-signed hex or binary representation, not to a two's-complement bit pattern, which matters to know if you're expecting a specific negative-number encoding from a programming context rather than a plain signed value.

Digit validation is base-aware: entering a digit that doesn't belong to the selected source base — like a '9' while base 2 (binary) is selected — produces a specific error identifying exactly which digit and which base conflicted, rather than a generic parse failure. This catches the common mistake of forgetting to switch the source base selector after pasting in a different kind of number.

Forgetting to change the source base selector after pasting a different kind of number — pasting a decimal value while binary is still selected will trigger an invalid-digit error the moment a 2-9 digit appears.

Expecting a negative number to convert to two's-complement bit patterns — this tool preserves a plain leading minus sign across bases rather than encoding negative values the way fixed-width binary representations in code typically do.

Assuming very large hex or binary values might lose precision the way plain JavaScript numbers can — BigInt-based conversion avoids that specific failure mode entirely.

Trying to convert a decimal value with a fractional part — this tool is integer-only, and a fractional input isn't something it's built to handle.

Converting a hex memory address or color value into binary to inspect individual bit flags.

Checking a large decimal ID against its hexadecimal representation for a database or API lookup.

Converting between bases while debugging low-level code involving bitmasks or binary flags.

Verifying an octal file permission value (like 755) against its decimal or binary equivalent.

Q: Can it handle really big numbers?

A: Yes. The converter uses BigInt, so it works with integers of any size — well beyond JavaScript's 2^53 safe-integer limit.

Q: Do I need to remove the 0x prefix for hex?

A: No — the tool auto-detects 0x, 0b, and 0o prefixes. You can include them or omit them; either works.

Q: What about fractional numbers?

A: This tool handles integers only. Fractional base conversion requires arbitrary-precision decimal arithmetic, which is rarely needed for developer use cases.

Q: Are negative numbers supported?

A: Yes. A leading minus sign is preserved across all conversions.

Q: What if I enter an invalid digit?

A: You'll see a clear error like 'Invalid digit 9 for base 2'. The tool validates each digit against the source base.

Q: Why does 0x1A3F and 1A3F give the same result?

A: The tool strips recognized prefixes (0x, 0b, 0o) before parsing, so the prefix is optional notation rather than something that changes the underlying value being converted.

Try the Number Base Converter. Working with structured data instead? Check the JSON Formatter. Need a unique identifier or a hash? Try the UUID Generator or Hash Generator.