Convert number bases in one go
Type a number into any field and the other bases follow instantly: binary, octal, decimal, hexadecimal, plus any custom base from 2 to 36. The maths runs on BigInt, so large values stay exact. Below that you get the bit view, the two's complement pattern and the matching character.
How do you convert from one base to another?
Every digit position is a power of the base. Binary 1011 means 1·2³ + 0·2² + 1·2¹ + 1·2⁰ = 11. The other way round you divide repeatedly by the target base and read the remainders bottom up: 11 ÷ 2 = 5 remainder 1, 5 ÷ 2 = 2 remainder 1, 2 ÷ 2 = 1 remainder 0, 1 ÷ 2 = 0 remainder 1, giving 1011. That is exactly what happens behind the fields, for every base up to 36, where the letters a to z carry on counting after the digits.
Why do large numbers stay exact here?
Because the tool uses BigInt throughout. An ordinary JavaScript number is a 64-bit IEEE 754 float and represents integers exactly only up to Number.MAX_SAFE_INTEGER = 9,007,199,254,740,991, that is 2⁵³ − 1. Above that it rounds, and it does so silently: as floats, 2⁸⁰ and 2⁸⁰ − 1 are the same value. Many online converters inherit that flaw and return a wrong decimal for a 20-digit hex input. Here the conversion is pure digit arithmetic with no float step in between, so every value comes back unchanged.
What is two's complement, and why a separate view?
Processors have no minus sign. They store integers as fixed-width bit patterns and keep a negative value x as 2ⁿ + x. In eight bits, −1 becomes 11111111 and −128 becomes 10000000. The top bit then carries the sign, and one and the same adder circuit works for positive and negative values, which is why this representation has been the standard for decades. Since C++20 the language standard even requires signed integers to use two's complement; before that, ones' complement and sign-and-magnitude were still formally allowed.
To be honest about it: the four fields at the top calculate with a real sign and unlimited size, so −10 is simply −1010 there. Two's complement is an additional fixed-width view, not a different calculation. If the value does not fit into the chosen width, the tool says so instead of quietly truncating. With n bits the range is −2ⁿ⁻¹ to 2ⁿ⁻¹ − 1, so −128 to 127 in eight bits.
Why group bits into fours or eights?
Because nobody can read 11001010111111101011101010111110, while 1100 1010 1111 1110 1011 1010 1011 1110 is fine. Four bits are exactly one hex digit, so the groups map straight to hex: 1100 becomes c, 1010 becomes a. Groups of eight are one byte, which helps when you are looking at memory contents or network masks. The bit view always shows the magnitude; the sign sits in front of it, and two's complement gets its own section.
What is the character display for?
It reads the value as a Unicode code point, the way a character table does. 65 is A, 97 is a, 10 is the control character LF, 8364 (hex 20AC) is the euro sign. That helps when debugging byte dumps, escape sequences and protocol data. Unicode runs from 0 to 1,114,111 (hex 10FFFF); above that there is no code point, and the range D800 to DFFF is reserved for UTF-16 encoding and stands for no character. Both cases are named rather than guessed.
Do my values stay private?
Yes. Parsing, converting and formatting all happen in your browser, no request leaves the page and it works offline. That is not a formality: what people convert here is usually memory addresses, permission masks, serial numbers, checksums or key fragments from a live system. Values like that do not belong in someone else's server log, and here they never get there.