Number base converter
| Decimal | Binary | Octal | Hex |
|---|---|---|---|
| 0 | 0 | 0 | 0 |
| 1 | 1 | 1 | 1 |
| 8 | 1000 | 10 | 8 |
| 10 | 1010 | 12 | A |
| 15 | 1111 | 17 | F |
| 16 | 10000 | 20 | 10 |
| 64 | 1000000 | 100 | 40 |
| 100 | 1100100 | 144 | 64 |
| 255 | 11111111 | 377 | FF |
| 256 | 100000000 | 400 | 100 |
| 1024 | 10000000000 | 2000 | 400 |
| 65535 | 1111111111111111 | 177777 | FFFF |
Base 36 uses all ten numerals and all twenty-six letters, which is as far as a case-insensitive alphanumeric alphabet goes. Base 62 exists by distinguishing upper and lower case, and Base64 adds two symbols on top, but those are encodings for binary data rather than positional number systems, which is why the general converter stops at 36.
A positional base writes a number with digits worth successive powers of that base. This converts between any two from 2 to 36 in either direction, with the common pairs one pick away: FF in base 16 is 255 in decimal, 11111111 in binary, 377 in octal and 73 in base 36.
How to convert between bases
Converting between two arbitrary bases is done by going through decimal, which is what this tool does internally. The exception is when one base is a power of the other, as in hex to binary or octal to binary, where direct digit substitution works and needs no arithmetic. That shortcut is why those particular pairs feel so much easier than, say, base 7 to base 13, and it is the whole reason hexadecimal exists in computing: one hex digit holds exactly four bits, so a register value or a memory dump can be read either way round without calculation.
Going from binary back up, the padding direction is the mistake worth avoiding. Bits carry value by position from the right, so a group of fewer than four must be padded on the left. 110110 padded on the left is 0011 0110, which is 36 in hex and 54 in decimal; padded on the right it would be D8, or 216, four times too large because every bit has been shoved two places up. The grouped binary row shows where the nibbles actually fell. Leading zeros are not printed on the way out, so pad the result yourself where a fixed width matters.
Octal is the same trick with three bits per digit, and it survives mainly in Unix file permissions, where that grouping is genuinely the clearest notation available. 755 is 111 101 101, full permissions for the owner and read and execute for everyone else, and in decimal it would be 493, which tells you nothing. The trap is the leading zero: in C a bare 0755 means octal, while Python 3 and strict-mode JavaScript reject it and want 0o755. Passing the decimal 755 where octal was expected sets 1363 instead, a permission set nobody intended.
Base 36 is where the compactness argument lives: 1234567890 becomes KF12OI, ten digits down to six, which is why short identifiers and URL slugs are often generated this way. The row labelled base 32 is a positional base in the same family, using 0–9 then A–V. It is not RFC 4648 Base32, and neither is it Base64. Those encode arbitrary bytes using a chosen alphabet, which is a different job from writing a number in a base.
Character codes are the same idea pointed at text instead of a number. Every character has a code point, and writing that number in a base is exactly what the rest of this page does — so ‘Hello’ in base 16 is 48 65 6C 6C 6F, and in base 10 it is 72 101 108 108 111. The codes are padded to a fixed width only where the base divides a byte evenly: two digits in hex, eight in binary, none in octal or decimal, because 8 and 10 do not. What it reads back are code points and not UTF-16 units, so an emoji survives the round trip as one code rather than two halves: 🎉 is 1F389, not D83C DF89. A code the base cannot hold is named rather than skipped.
One honest limit: the arithmetic runs in double-precision floating point, so values above 9007199254740991 stop being exact. Below that everything here is exact in every base. Fractions are refused rather than truncated, and a leading minus sign is understood.
What people use it for
- Working with an unusual base
- Reading a register or bitmask as bits
- Compressing a long bitmask into hex
- Reading a chmod value
- Producing a chmod value from a decimal number
- Following a hardware or register datasheet written in hex
- Generating short identifiers in base 36
- Converting between several bases at once
- Checking a conversion you did by hand
- Course work on number systems
- Turning a string into hex character codes
- Reading hex character codes back as text
Questions
Anything from 2 to 36. Base 36 uses 0–9 then A–Z.
Because that exhausts the case-insensitive alphanumeric digits. Higher bases need case sensitivity or extra symbols.
By going through decimal internally. Direct substitution works only when one base is a power of the OTHER — hex to binary, octal to binary, and base 9 to base 3 just as well, where 58 becomes 1222 by rewriting each digit as two. Two bases that are merely both powers of two, like 4 and 8, do not qualify.
1010. Each hex digit is exactly four bits.
11111111: eight bits, one byte, every one of them set. Read the other way, 11111111 is FF and 255 in decimal.
Because 16 equals 2 to the fourth power, so one hex digit holds precisely four bits with no remainder.
The left, always. Bits carry value by position from the right, so an incomplete leftmost group is filled with zeros: six bits are read as eight. 110110 padded left is 36 in hex; padded right it would be D8, four times the value.
No. Spaces, underscores and commas are ignored, so grouped binary can be pasted straight in.
Leading zeros are not printed. 0011 0110 comes back as 36, not 036. Pad it yourself if a fixed width matters.
493. As Unix permissions it is rwxr-xr-x.
Because each permission group is three bits, and three bits is exactly one octal digit. Hexadecimal replaced octal nearly everywhere else for the matching reason: a byte is eight bits, which divides evenly by four and not by three.
In C and its descendants it marks the number as octal, so 0755 is 493. Python 3 and strict-mode JavaScript reject the bare zero and want 0o755. The failure worth watching for is the other direction: pass the decimal 755 where octal was expected and you set 1363, an entirely different permission set.
The special bits, in front of the three permission groups: 4 is setuid, 2 is setgid and 1 is the sticky bit. 1777 is the sticky bit plus full permissions for everyone, which is how /tmp is set.
No. The digits are 0 to 7 only, which is why those are refused rather than read as something else.
No. This is a positional base using 0–9 then A–V. RFC 4648 Base32 encodes bytes with A–Z and 2–7. An encoding, not a number base.
Up to 9007199254740991 exactly. Above that, double-precision arithmetic starts rounding the last digits whatever base you use.
Compact identifiers: 1234567890 becomes the six characters KF12OI.
Yes, a leading minus sign is understood.
Choose character codes, leave the direction on text to codes, and paste the text. Each character comes back as its code point in hex: Hello is 48 65 6C 6C 6F, and the row underneath gives the same thing without spaces.
Same tab, direction set to codes to text. Paste 48 65 6C 6C 6F and you get Hello. Spaces, commas and underscores between the codes are all accepted.
Because they are 32 apart, which is a single bit — 0x20. That is why case used to be changed with one bitwise operation rather than a lookup: OR with 0x20 forces lowercase, AND with 0xDF forces upper, and XOR with 0x20 toggles — OR cannot toggle, because setting a bit that is already set does nothing. It only holds for the unaccented Latin letters.
Yes, and as one code each. é is E9 and 🎉 is 1F389, because it reads code points rather than the UTF-16 units an emoji is stored as. Anything above 7F has left ASCII and is a Unicode code point.
No. This writes one number per character in the base you choose. Base64 packs arbitrary bytes three at a time into four characters of its own alphabet, which is an encoding rather than a way of writing a number.