Number base converter
- 57 tools
- No watermark
- No daily limit
Type a number and see it in binary, octal, decimal and hexadecimal at the same time, plus any base from 2 to 36. Everything is worked out with exact integer arithmetic, so a sixty-four bit value keeps every digit: paste FFFFFFFFFFFFFFFF into most converters and the answer comes back as 18446744073709552000, which is not the number and carries no warning. The part after the point is converted digit by digit rather than through a float, so 0.1 in base ten reaches base three with everything it is entitled to, and a fraction that repeats is labelled instead of quietly rounded.
Where each base is used, and why
Four bases account for nearly everything, and each is in use for a concrete reason rather than by convention.
| Base | Digits | Where you meet it | Why that base |
|---|---|---|---|
| 2, binary | 0 1 | Permissions bits, hardware registers, bitmasks, network prefixes | A wire is on or off. Everything else is an abbreviation of this. |
| 8, octal | 0 to 7 | chmod 755, and little else now |
Three bits per digit, which is exactly the read, write and execute triple. Octal survives where things come in threes. |
| 16, hexadecimal | 0 to 9, A to F | Colours, memory addresses, hashes, byte dumps, Unicode code points | Four bits per digit, so exactly two digits per byte, always. A byte is never half a character wide. |
| 10, decimal | 0 to 9 | Everywhere else | People have ten fingers. There is no better reason and there never was. |
The higher bases exist for compactness. Base 36 uses every digit and every
letter, which makes it the densest base you can write with an ordinary keyboard
and no case sensitivity, and it is why short URL codes and some order numbers
are base 36. Base 32 and base 58 go further by dropping the characters people
mistype: base 58, used by Bitcoin addresses, has no 0,
O, I or l, on the grounds that an address
read aloud down a telephone should survive the trip.
Prefixes
A written number often announces its own base. 0x means
hexadecimal, 0b means binary and 0o means octal, in
almost every programming language written since C. A bare leading zero meant
octal in older C and in some shells, which has caused real bugs: a zip code or a
time written 08 was read as octal and rejected, because 8 is not an
octal digit. This converter reads the modern prefixes and tells you when one
contradicts the base you picked, rather than guessing which of you is right.
Binary that is text rather than a number
This is the mistake worth knowing about, because nothing warns you when you make it.
A run of ones and zeros can be two completely different things:
- A number written in base two.
1001000is seventy-two. That is what this converter is for. - Text encoded as bytes. The same
01001000 01101001is the wordHi, written as two eight-bit groups.
Paste the second kind into a base converter and you get an answer. It is a
real answer to a real question and it is not the question you were asking: it
will hand you 18537 rather than Hi, without complaining, because
the input is a perfectly valid base-two number.
The tell is grouping and length. Text is written in groups of eight, or as a single unbroken run whose length divides by eight. A number is written however it came out, with no particular length, and usually with no leading zero. If your ones and zeros arrived from a puzzle, a game or a homework sheet, they are text far more often than they are a number.
For that, use the classic ciphers page, which has a binary converter that works on text and reads the bytes as UTF-8, so Thai and emoji survive the round trip exactly. It also handles the other things that turn up in the same puzzles: A1Z26, where a letter is its position in the alphabet, and the Caesar, Atbash and Vigenère shifts.
Come back here when what you have really is a number, which is the case for permissions bits, register values, colour codes and network masks.
Why the arithmetic is exact, and what breaks without it
Most converters on the web do the job with the language's own number type, which in JavaScript is a 64-bit float. That holds integers exactly up to 253, or 9,007,199,254,740,992, and above that it starts rounding to whatever value it can represent.
The consequence is easy to see and easy to miss:
| Input, hexadecimal | Correct decimal | What a float gives |
|---|---|---|
FFFFFFFFFFFFFFFF |
18,446,744,073,709,551,615 | 18,446,744,073,709,552,000 |
1FFFFFFFFFFFFF |
9,007,199,254,740,991 | 9,007,199,254,740,991 — still exact, this is the boundary |
The first row is a 64-bit value with every bit set, which is the commonest large number anybody converts: a maximum unsigned integer, a full bitmask, a file offset. The float answer is wrong in the last four digits and carries no warning at all, which is the part that matters. A wrong answer that announces itself is an inconvenience; a wrong answer that looks right is a bug you ship. This page uses exact integer arithmetic with no upper limit, so the digits you get are the digits there are.
Fractions
The part after the point is converted digit by digit rather than through a float, for the same reason. In base three, one tenth repeats forever, exactly as one third repeats forever in base ten. There is no correct way to write it in a finite number of digits, so the honest options are to cut it off and say so, or to round it and stay quiet. This page cuts it off and says so, at whatever length you set.
Frequently asked questions
Is my number sent anywhere?
No. The conversion happens in this tab as you type. The site’s security policy sets connect-src ‘none’, so the browser blocks network requests from these pages, meaning it could not be sent even if the code tried.
Why does this exist when JavaScript has parseInt?
Because parseInt stops being correct at about nine quadrillion and does not say so. Ask it for FFFFFFFFFFFFFFFF and it returns 18446744073709552000; the answer is 18446744073709551615. The difference is 385, arriving silently, in the one case a person converting hexadecimal is most likely to have in front of them. Everything here uses arbitrary-precision integers, so there is no size at which it starts guessing.
Why is 0.1 in binary not exact?
For the same reason a third is not exact in decimal: the base has no way to write it. A tenth is 0.0001100110011… in base two, repeating forever, which is also why adding 0.1 and 0.2 in most programming languages gives 0.30000000000000004. This page tells you when a fraction repeats rather than rounding it off and letting you think it terminated.
What is the signed reading underneath?
The same bits mean two different numbers depending on whether whatever produced them treated the top bit as a sign. 0xFFFFFFFF is 4,294,967,295 as an unsigned value and -1 as a signed one, and which is correct depends entirely on the program that wrote it. Both are shown because a hex dump does not say which you are looking at.
Can I paste 0x, 0b or spaces?
Yes. Prefixes are accepted when they agree with the base you chose and refused when they do not, because reading 0xFF as a decimal number would silently produce nonsense. Spaces, commas and underscores are ignored wherever they appear, so a value grouped for readability pastes straight in.
Why does the base stop at 36?
Because there are ten digits and twenty-six letters, and after that there is no agreement about what the next symbol should be. Base 64 exists and is a different thing entirely: it encodes bytes rather than writing a number, which is what the Base64 tool on this site is for.