進数変換
Number Base Converter converts between binary, octal, decimal, hexadecimal and any base from 2 to 36, in your browser. Integers run through BigInt end to end rather than through a double, because parseInt silently returns 9007199254740992 for 9007199254740993 — and the values people convert are IDs, bitmasks and hashes, which is exactly the material that exceeds that limit.
このツールの画面は英語表記です。
Enter a number above or click “Try Example” to convert across binary, decimal, hex, and custom bases.
以下の解説は英語のみでご覧いただけます。
How does Number Base Converter work?
Base conversion looks like a one-liner and stops being one at two points: large integers and fractions.
parseInt loses digits, silently
parseInt("9007199254740993", 10) returns 9007199254740992. Nothing throws, nothing warns, and the last digit is simply gone — because a JavaScript number is a double and 253 is where consecutive integers stop being representable. The things people convert between bases are snowflake IDs, permission bitmasks, hashes and memory addresses, every one of which routinely exceeds that. So the integer path here is BigInt from parse to format and never round-trips through a double.
Fractions convert by repeated multiplication
BigInt has no fractional part, so the fraction is handled separately: multiply the fractional digits by the target base, take the carry as the next output digit, repeat. All the arithmetic stays on integers in the source base, so nothing passes through a float — which is why 0.1 in base 3 comes out as exactly 0.1 here rather than as 0.3333333333333333.
Some fractions do not terminate in the target base: 0.1 decimal is 0.0001100110011… in binary, repeating forever, which is the same fact behind 0.1 + 0.2 !== 0.3. Nothing can fix that, so the expansion is bounded at forty digits and stops.
A leading 0x that disagrees with the base is an error
Pasting 0x1f with base 10 selected almost certainly means you meant base 16. Treating 0 and x as digits would either fail confusingly or produce a wrong answer, so the mismatch is named. Digit separators — underscores and spaces — are accepted, because 1010_1010 is how people actually write a byte.
Two's complement is why -1 reads as ffffffff
A negative integer in memory is stored as its two's complement: invert the bits and add one. So -1 in 32 bits is ffffffff, and -2147483648 is 80000000. When a debugger shows you a huge positive hex value where you expected a small negative one, this is what happened. The panel shows the encoding at the narrowest width that holds the value.
Set bits, for a value used as a mask
A permissions integer is a set of flags, and the useful question is which are on. The bit positions are listed, counting from zero at the least significant bit, which is the convention every bit-shift operation uses.
Input
255 (base 10)
Converted
binary 1111 1111 octal 377 hexadecimal ff set bits 0, 1, 2, 3, 4, 5, 6, 7
What options and edge cases does Number Base Converter support?
| Parameter | Type | Default | Behaviour & edge cases |
|---|---|---|---|
| Base range | 2 to 36 | — | Digits are 0–9 then a–z, case-insensitive, which gives 36 symbols. Base 36 is the densest encoding that uses only alphanumerics. |
| Precision | arbitrary | BigInt | Integers of any length convert exactly. parseInt loses digits past 2^53 with no warning, which is the single most common bug in base converters. |
| Fractions | repeated multiplication | 40 digits max | Exact where the fraction terminates in the target base. Where it does not — 0.1 decimal in binary — the expansion is bounded rather than infinite. |
| Separators | _ and space | accepted | 1010_1010 and 1010 1010 both parse. Rejecting them would be pedantry; that is how people write a byte. |
| Prefixes | 0b 0o 0x | checked | Accepted when they agree with the selected base, and reported as an error when they do not — pasting 0x1f with base 10 selected is a mistake worth naming. |
| Grouping | boolean | on | Every 4 digits in binary, 3 in octal and decimal, 2 in hexadecimal — the groupings that match how each base is read. |
| Two's complement | 8/16/32/64-bit | narrowest fit | How a negative value is actually stored, which is why -1 appears as ffffffff in a debugger. |
| Bit width | signed and unsigned | reported | Which of int8 through uint64 can hold the value. A value that fits int32 but not int16 is the kind of thing worth knowing before choosing a column type. |
Frequently asked questions
Why do other converters give me a different answer for a long number?
Because they used parseInt or Number, which go through a double and lose precision past 2^53 — about 9.007 quadrillion. parseInt("9007199254740993") returns 9007199254740992, with no error. This tool uses BigInt throughout, so every digit survives. If you are converting a snowflake ID, a hash or a large bitmask, this is the difference that matters.
Why does 0.1 not convert cleanly to binary?
Because it cannot. One tenth is 0.0001100110011… in base 2, repeating forever, for the same reason one third is 0.333… in base 10: the denominator has a prime factor the base does not. This is the entire explanation for 0.1 + 0.2 !== 0.3 in every language with binary floating point. The expansion here stops at forty digits because it has to stop somewhere.
Why is -1 shown as ffffffff?
That is two's complement, which is how essentially every computer stores a negative integer: invert the bits of the magnitude and add one. It has the nice property that addition works identically for signed and unsigned values, which is why it won over the alternatives. When a debugger shows a suspiciously large positive hex value where you expected a small negative number, this is what you are looking at.
What is base 36 for?
Compact identifiers. Base 36 uses 0-9 and a-z, which is the largest alphabet that survives being case-folded, typed by a human and put in a URL without encoding. A timestamp in base 36 is about half the length it is in decimal. Base 62 is denser but case-sensitive, which makes it fragile anywhere that lowercases.
Can I convert a floating-point number's bit pattern?
Not directly — this converts the mathematical value, not the IEEE 754 encoding. Those are different questions: 0.5 as a value is 0.1 in binary, while 0.5 as a double is 3FE0000000000000 in hex. If you want the bit pattern, convert the hex of the encoded form as an integer.
Is my number uploaded?
No. It is arithmetic, running in your browser. Nothing about converting 255 to hexadecimal requires a server, and the numbers people convert are frequently internal identifiers they would rather not put in someone else's log.