Loading Number Base Converter…
Spaces, commas and underscores are ignored, so 1010 1101 is fine.
Enter a number to convert it into every base at once.
Any base from 2 to 36, shown as an extra row.
Everything is computed with BigInt rather than the browser’s ordinary numbers. parseInt and toString(2) both pass through a 64-bit float, so 9007199254740993 — one above 253 − 1 — comes back as 9007199254740992 and its last bit is lost. Here it converts to hexadecimal exactly: 20000000000001.
Type a value, say which base it is written in, and binary, octal, decimal and hexadecimal appear together, along with any other base from 2 to 36 you ask for. Grouping is ignored, so a pattern pasted as 1010 1101, a number copied as 1,024 and a literal written 1_000_000 all read correctly, and a 0x, 0b or 0o prefix is accepted when it agrees with the base selected — if it does not, the mismatch is pointed out rather than ignored.
When a digit is impossible the message says which one: entering 12 as binary answers that "2" is the 2nd digit and base 2 uses only 0-1. That is more useful than a blank result, because the usual cause is a value pasted from the wrong column.
The bit pattern is shown with bits grouped in fours, and the grouping is not decoration: four bits are exactly one hexadecimal digit, so the third group from the right is the third hex digit, and you can convert between the two by eye. Bit 0 is on the right, so a value with the low bit set is odd, and a permissions field with bit 3 set shows a 1 in the fourth position from the right.
This is what makes a bitmask readable. 173 is 1010 1101, so against a flag set where bit 0 is READ, bit 2 is WRITE and bit 5 is ADMIN, you can see all three are on without a calculator. Fix the width at 8, 16, 32 or 64 bits to compare two values with their leading zeros aligned, and a width too small for the value says how many bits are needed instead of truncating in silence.
Every ordinary number in JavaScript is a 64-bit float, which gives exact integers only up to 2^53 - 1, or 9007199254740991. One past that, 9007199254740993, cannot be represented at all: it rounds to 9007199254740992, and parseInt and toString(2) both go through that same representation, so a converter built on them starts producing quietly wrong digits well before 64 bits.
This tool uses BigInt from end to end, so nothing passes through a float. 9007199254740993 converts to hexadecimal as 20000000000001 — note the trailing 1, the bit a float-based conversion loses — and a full 64-bit mask of ffffffffffffffff comes back as 18446744073709551615 exactly. The screen says when a value has crossed the 2^53 line, past which any figure from a console, a spreadsheet or a JSON parser needs checking: database identifiers, snowflake IDs and 64-bit hashes all live up there.
Negative numbers are shown in two’s complement at whatever width is selected, because that is what a register actually holds: -1 in 8 bits is 1111 1111, and -7 is 1111 1001. The rule is that the pattern for a negative value is 2^width added to it, which is why the top bit ends up acting as a sign bit and why an 8-bit signed range runs from -128 to 127 rather than -127 to 127.
That asymmetry is real and the tool respects it: -128 fits in 8 bits, while -255 needs 16. In the decimal, octal and hexadecimal rows a negative value keeps an ordinary minus sign, since that is how it would be written in source code. Only integers are handled — 0.5 and 1.75 are refused rather than rounded, because binary fractions are a separate problem whose first trap is that 0.1 has no exact binary form.
Because one hex digit is exactly four bits, so eight hex digits map onto 32 bits with no arithmetic. That is why #ff8800 splits cleanly into three colour channels of one byte each, and why a memory address or a bitmask is far shorter in hex than in binary while still being readable bit by bit.
As octal, where each digit is three bits: read is 4, write is 2, execute is 1. So 6 is 110, meaning read and write, and 644 is rw-r--r--. Enter 644 with a base of 8 here and the bit pattern shows the nine permission bits directly.
It uses 0-9 then a-z, which is every character available in a case-insensitive identifier, so it packs a number into the fewest characters that survive being lowercased. Short link slugs and compact reference codes often use it, or base 32 where digits that look alike are dropped to avoid transcription errors.
No — integers only, by design. Converting a fraction to another base needs a decision about how many places to keep, and terminating in one base rarely means terminating in another: a tenth is 0.1 exactly in decimal and repeats forever in binary. Convert the integer part here and handle the fraction deliberately.