Number Base Converter — Binary, Octal, Decimal, Hex, Any Base 2 to 36

Type a number in any base from 2 to 36 and read it back in any other, with the bit width, the byte count and the smallest standard integer that holds it. Integers above 9,007,199,254,740,991 are refused rather than rounded, and a digit the base does not have is refused rather than guessed.

Last updated 30 Sep 2026

Any base 2 to 36, in and out

Text in, text out — the exact integer or nothing

ValueRead in the base chosen below. Case does not matter, spaces are ignored, and a leading minus sign is allowed. Digits run 0 to 9 then A to Z, so base 16 uses 0 to F and base 36 uses 0 to Z.

From baseThe base the value above is written in.

To baseThe base the answer is written in. Change this and the headline changes; the value itself never does.

FFExample

255 entered in base 10, converted to base 16. The headline shows the converted digits and the secondaries carry the same value in decimal, in bits and in bytes.

Positional notation, both ways

value = ∑ d_i × bⁱ (digit d_i at position i, counting from 0 at the right)
digits out: repeatedly divide by the target base and keep the remainders, last first
bits = ⌊log₂ v⌋ + 1 bytes = ⌈bits ÷ 8⌉ exact-integer limit = 2⁵³ − 1

b: the base, or radix — any whole number from 2 to 36 here. The cap is 36 because the digit alphabet is 0 to 9 followed by A to Z, which is 36 symbols
d_i: the digit at position i, with a value from 0 to b minus 1. A symbol whose value is b or more is not a digit of that base at all, and is refused
v: the value itself — a single exact integer that both the input digits and the output digits describe. Converting bases changes the writing, never the number
2⁵³ − 1: 9,007,199,254,740,991: the largest integer a binary64 double holds exactly, because its significand is 53 bits

Worked example

255 entered in base 10, converted to base 16. The headline shows the converted digits and the secondaries carry the same value in decimal, in bits and in bytes.
255 in base 10 is 2×10² + 5×10¹ + 5×10⁰ = 200 + 50 + 5, so the value is two hundred and fifty-five
Out to base 16: 255 ÷ 16 = 15 remainder 15. 15 ÷ 16 = 0 remainder 15. Remainders last first: 15, 15 — and digit 15 is written F, so FF
Out to base 2 the same value is 11111111, and out to base 8 it is 377. All four strings — 255, FF, 377, 11111111 — are the same number
Bits: 2⁸ = 256 is above 255 and 2⁷ = 128 is not, so the top set bit is bit 7 and the width is 8 bits — one byte, which is exactly two hex digits
255 is therefore the largest unsigned 8-bit value, and the smallest standard integer width that holds it is 8. It leaves 45 of the 53 exactly-representable bits unused

The same values in the four bases people actually ask about

Every row was produced by the same conversion the calculator above runs, then checked against an independent big-integer conversion; the binary column for the last row is 53 ones. The three columns that are powers of two — 2, 8 and 16 — line up with binary in fixed groups: one octal digit is exactly three bits and one hex digit is exactly four, which is why those two bases and no others are used to write bit patterns by hand. Base 10 has no such relationship with base 2, which is the whole reason a converter is needed at all.
Decimal	Binary (base 2)	Octal (base 8)	Hexadecimal (base 16)	Bits	What it is
0	0	0	0	1	zero — one digit in every base
7	111	7	7	3	largest single octal digit
8	1000	10	8	4	first value needing two octal digits
10	1010	12	A	4	where hexadecimal stops looking like decimal
15	1111	17	F	4	largest single hex digit — one nibble
16	10000	20	10	5	one more than a nibble
63	111111	77	3F	6	largest value in two octal digits
64	1000000	100	40	7	2 to the 6th
100	1100100	144	64	7	the trap: hex 64 is decimal 100
127	1111111	177	7F	7	largest signed 8-bit value
128	10000000	200	80	8	smallest negative signed byte, as a bit pattern
255	11111111	377	FF	8	largest unsigned byte — two hex digits
256	100000000	400	100	9	needs a second byte
511	111111111	777	1FF	9	largest value in three octal digits
4095	111111111111	7777	FFF	12	three hex digits — a CSS shorthand colour
65535	1111111111111111	177777	FFFF	16	largest unsigned 16-bit value
16777215	111111111111111111111111	77777777	FFFFFF	24	largest 24-bit colour — white
4294967295	11111111111111111111111111111111	37777777777	FFFFFFFF	32	largest unsigned 32-bit value
9007199254740991	11111111111111111111111111111111111111111111111111111	377777777777777777	1FFFFFFFFFFFFF	53	2 to the 53rd minus 1 — the last integer this page can hold exactly

What fits where, and why 64-bit is only half true here

Both range columns are computed, not quoted: unsigned is 2 to the power of the width minus 1, and signed two’s complement runs from minus 2 to the power of width minus one, up to 2 to the power of width minus one, minus one. The last row is the honest limit of this page. A double holds integers exactly up to 2 to the 53rd minus 1, so the top eleven bits of a 64-bit integer are out of reach: the calculator refuses such a value outright instead of printing a rounded bit pattern. If you need the full 64 bits, you need a tool built on big integers, and this is not one.
Width	Unsigned range	Signed two’s-complement range	Hex digits	Fully supported here?
8 bits (1 byte)	0 to 255	-128 to 127	2	yes
16 bits (2 bytes)	0 to 65,535	-32,768 to 32,767	4	yes
24 bits (3 bytes)	0 to 16,777,215	-8,388,608 to 8,388,607	6	yes
32 bits (4 bytes)	0 to 4,294,967,295	-2,147,483,648 to 2,147,483,647	8	yes
53 bits	0 to 9,007,199,254,740,991	-9,007,199,254,740,991 to 9,007,199,254,740,991	14 (top digit 1 only)	yes — this is the real ceiling
64 bits (8 bytes)	0 to 18,446,744,073,709,551,615	-9,223,372,036,854,775,808 to 9,223,372,036,854,775,807	16	no — only the bottom 53 bits

One number, many spellings

Changing base changes the spelling of a number, not the number. 255, FF, 377 and 11111111 are four ways of writing the same quantity, in bases 10, 16, 8 and 2. Positional notation is the only idea involved: each digit carries its face value multiplied by the base raised to the digit’s position, counting from zero at the right. Going the other way you divide by the target base repeatedly and read the remainders backwards. That is the whole algorithm, and it works for every base from 2 to 36 without a special case.

Why 36 and not more. The digit alphabet here is 0 to 9 followed by A to Z, which is thirty-six symbols, so base 36 is where you run out of letters. Base 16 uses the first six letters and stops at F. Base 32 in the sense used by this page means the first thirty-two of those symbols, which is not the same thing as RFC 4648 Base32 encoding: that scheme uses A to Z then 2 to 7 and encodes bytes, not integers, so its output looks nothing like what you get here. Base 64 encoding is likewise not base 64 arithmetic.

Bases 2, 8 and 16 are the ones that matter for bit patterns, and it is not arbitrary. Eight is two cubed and sixteen is two to the fourth, so one octal digit is exactly three binary digits and one hexadecimal digit is exactly four. That makes converting between them a matter of regrouping digits with no arithmetic at all: split a binary string into groups of four from the right and you have read off the hex. One byte is eight bits, so it is always exactly two hex digits, which is why hex dumps are laid out the way they are, and why Unix file permissions — three independent three-bit fields — are written in octal. Decimal has no such relationship with binary, which is the whole reason this page exists.

Where this page stops, and why it stops rather than rounding. The arithmetic is done in IEEE 754 binary64 floating point, whose significand is 53 bits. That makes 9,007,199,254,740,991 — two to the fifty-third, minus one — the largest integer it can hold exactly. Above that, consecutive integers stop being distinguishable: two to the fifty-third and the integer after it are the same double. A converter that carried on would print a binary or hexadecimal string that looked completely authoritative and was quietly wrong in its low bits, and there is no way for a reader to tell. So the parser refuses those values outright and the calculator says so. That also means the page cannot fully serve 64-bit integers: it covers the bottom 53 bits of them and nothing above.

What is refused, and what is merely tidied. A symbol the base does not contain is not a small mistake to be worked around — a 2 in a binary number or a 9 in an octal one means the value was not what you thought it was, so nothing is shown. Case is ignored, spaces are ignored, a leading minus sign is accepted, and a leading 0b, 0o or 0x is stripped so that pasting a literal out of source code works. Leading zeros are harmless. Fractions are not supported: this converts whole numbers only, because a fraction that terminates in one base usually does not terminate in another, and a page that silently truncated 0.1 would be worse than one that declines.

Frequently asked questions

How do I convert binary to hexadecimal by hand?

Split the binary string into groups of four digits starting from the right, padding the leftmost group with zeros, and replace each group with its hex digit. 11111111 becomes 1111 1111, which is F F, so FF. It works because sixteen is two to the fourth, so one hex digit holds exactly four bits with nothing left over. Octal is the same trick with groups of three, because eight is two cubed. Going from binary to decimal has no shortcut like this and needs actual arithmetic, which is why hex and octal — and not decimal — are what people use to write bit patterns down.

Why does this calculator refuse very large numbers instead of converting them?

Because it cannot convert them correctly, and a wrong answer in hexadecimal looks exactly as confident as a right one. The arithmetic runs in IEEE 754 binary64 doubles, whose significand is 53 bits, so the largest integer held exactly is 9,007,199,254,740,991. Feed in one more and the value stored is no longer the value you typed, so every digit of the output below the top 53 bits would be fiction. The parser checks the magnitude and returns nothing instead. If you need full 64-bit or arbitrary-precision conversion, you need a tool built on big integers: Python’s int, a bc session, or your language’s BigInt type.

What happens if I type a digit the base does not have?

The calculator stops and tells you, rather than guessing. A 2 in a binary number, a 9 in an octal one or a G in a hexadecimal one is not a typo that can be repaired — it means the number is not written in the base you said it was, and any answer would be invented. Base N contains only the first N symbols of the sequence 0 to 9 then A to Z, so base 2 has 0 and 1, base 8 has 0 to 7, base 16 has 0 to F, and base 36 has 0 to Z. Case is not part of it: a and A are the same digit.

Is base 32 here the same as Base32 encoding, or base 64 the same as Base64?

No, and they are not comparable things. This page does base 32 arithmetic: a positional number system whose digits are 0 to 9 then A to V. RFC 4648 Base32 is a binary-to-text encoding whose alphabet is A to Z then 2 to 7, which maps five bits to one character and pads with the equals sign — it encodes a byte string, not an integer, and the same number comes out looking completely different. Base64 encoding is the same kind of thing with a 64-character alphabet, and this page does not offer base 64 arithmetic at all, because the digit alphabet 0 to 9 then A to Z runs out at 36.

Why is the largest unsigned byte 255 and the largest signed byte 127?

Eight bits give two to the eighth, or 256, distinct patterns. Read as unsigned they are 0 to 255. Read as signed two’s complement, the top bit is spent on the sign, so the positives are 0 to 127 and the patterns with the top bit set are the negatives, minus 128 to minus 1 — which is why the range is not symmetric and why there is one more negative value than positive. This page converts a number, not a bit pattern of a chosen width, so a negative value keeps its minus sign and the bit width shown is the width of its magnitude. Two’s complement is a property of a fixed-width container, not of the number.

Do leading zeros or a 0x prefix matter?

Leading zeros are ignored, as they are in arithmetic: 007 in base 8 is 7. A leading 0b, 0o or 0x is stripped so that a literal pasted straight out of source code converts, which is convenient in bases 2, 8 and 16 where those prefixes mean what they normally mean. Be aware that the stripping is not currently conditional on the base you chose, so in bases where B, O or X is itself a digit — B is a digit from base 12 up, O from base 25 up, X from base 34 up — a value that genuinely begins 0B, 0O or 0X can be mangled. Until that is fixed, drop the leading zero in those bases: write BEEF rather than 0BEEF.

Related calculators

References

ECMA-262, ECMAScript Language Specification: Number.prototype.toString(radix) accepts a radix from 2 to 36 inclusive and throws outside that range, and Number.MAX_SAFE_INTEGER is defined as 2⁵³ − 1 = 9,007,199,254,740,991 — the largest integer n for which both n and n + 1 are exactly representable. Cited by clause from knowledge; the specification was NOT fetched in this session, because no outbound network access was available. Both facts were instead verified directly against the engine that runs this page: every base from 2 to 36 round-trips exactly over 700,890 distinct integers spanning 0 to 2⁵³ − 1, and of the 105,000 integers from 2⁵³ to 2⁵³ + 3,000 written out in all 35 bases, zero were accepted.
IEEE 754-2019, Standard for Floating-Point Arithmetic: the binary64 format carries a 53-bit significand — 52 bits stored plus one implicit leading bit — and that width is what makes 2⁵³ − 1 the ceiling for exactly representable integers. The standard is paywalled and was NOT read; the significand width is stated here from the format definition, and its consequence was measured rather than quoted, by confirming that 9,007,199,254,740,991 is accepted, that 9,007,199,254,740,992 is refused, and that 2⁵³ + 1 collapses onto 2⁵³ when stored in a double.
RFC 4648, The Base16, Base32, and Base64 Data Encodings (IETF, October 2006). Cited only to mark the distinction this page keeps making: Base32 there is a binary-to-text encoding over the alphabet A to Z then 2 to 7, five bits per character, padded with the equals sign — not a positional number system. Not fetched in this session; used for the name and alphabet only, and no table from it is reproduced.
Every numeric cell in both tables above, and every figure in the worked example, was computed twice and only kept when the two agreed: once through this plugin’s own conversion functions and once through an independent arbitrary-precision conversion, for all 35 bases. The bit-width and digit-count formulas the calculator uses were checked the same way — the bit width over 700,890 distinct integers and the digit count over 24,531,150 integer-and-base pairs, with no disagreement.

Unit definitions vary by region and manufacturer. Where a spread exists we show it. For food safety, follow your national authority's current guidance. Full disclaimer at calcengines.com/disclaimer/