Number Base Converter

What a number base actually is

A base (or radix) is simply how many distinct digit symbols a place-value system uses, and therefore what each position is worth. In base 10 the number 255 means 2×10² + 5×10¹ + 5×10⁰. The same quantity written in base 16 is FF — 15×16 + 15 — and in base 2 it is 1111 1111. Nothing about the amount changes; only the alphabet and the size of each place do. A single number, four faces:

The 0x, 0b and 0o prefixes are how most programming languages mark a literal's base in source code — this converter shows the bare digits, so you add whichever prefix your language expects. Type a value on the left, pick the base to read it in, and every other base is rewritten on the right as you type. New to this? The guide Number Bases Explained builds positional notation, binary, hex and two's-complement up from first principles with a fully worked example.

The two conversion algorithms

Every base conversion is really two moves: parse the input into a single quantity, then format that quantity in the target base. Parsing (any base → value) is a left-to-right multiply-and-add: start at 0, and for each digit do value = value × base + digit. Formatting (value → any base) is the mirror image — repeatedly divide by the base and read the remainders from last to first. Here is decimal 13 becoming binary, step by step:

You do not have to take that on faith for your own number: open Show the steps under the results and the tool prints the same working for whatever you typed — every division with its quotient and remainder, the multiply-and-add pass that read your input if it was not decimal, and the bit-regrouping shortcut when both bases are powers of two. Very long numbers produce a lot of rows (a 40-digit decimal takes about 133 divisions to write in binary), so the trace shows the first 36 and the last 4 and tells you exactly how many it left out — the answer above it is always complete.

Hexadecimal uses exactly the same loop with a divisor of 16 and remainders 0–15 written 0–9 then A–F: 255 ÷ 16 = 15 r 15, and 15 is F, so 255 becomes FF. Going the other way, 1A hex = 1×16 + 10 = 26. Because hex maps exactly four bits to one digit and octal maps exactly three, converting between binary, octal and hex needs no arithmetic at all — you just regroup the bits: 1111 1111 → nibbles F F, or triplets 011 111 111 → 3 7 7.

Worked in full: 156 → binary by long division

A longer example with every division written out. Divide by 2 until the quotient hits 0, keeping each remainder:

Read the remainders from the last step back to the first: 10011100. The catch everyone hits once: the first remainder is the last digit you write. Sanity-check by adding the place values of the 1-bits: 128 + 16 + 8 + 4 = 156. ✓

Hex ↔ binary: the nibble trick, worked

Hex to binary needs no division at all — each hex digit is a 4-bit group (a nibble). Expand 0x2F5C one digit at a time:

Concatenate in order: 0010 1111 0101 1100 — that is 0x2F5C (decimal 12 124) as 16 bits. Going binary → hex, group the bits in fours starting from the right, padding the leftmost group with zeros. For 1101011 (decimal 107): pad to 0110 1011, then read each nibble — 0110 = 6, 1011 = 11 = B — giving 0x6B. Grouping from the left instead is the classic mistake: it silently shifts every nibble and gives a wrong answer.

Reference table: the same values in four bases

Keep this handy for reading byte dumps and bitmasks. Notice the round numbers: powers of two are a single 1-bit in binary, and FF, FFFF, FFFFFFFF are the largest values that fit in 1, 2 and 4 bytes.

Where each base earns its keep

Hex (base 16) is the default shorthand for raw bytes because two hex digits are exactly one byte. You meet it in CSS colors (#5B6CFF is R=91, G=108, B=255), memory addresses in a debugger, MAC addresses, UUIDs, and hex dumps of binary files. Octal (base 8) survives mainly in Unix file permissions: chmod 755 reads as three octal digits, one per rwx group, where 7 = 111 = read+write+execute and 5 = 101 = read+execute. Binary (base 2) is where bitmasks and flags live — testing flags & 0b0100 checks a single bit, and a permissions or feature-toggle integer is just a row of on/off bits. Decimal is for humans; almost everything else is for machines that ultimately store bits.

Signed numbers and two's-complement

This tool shows negatives in signed-magnitude form — a leading minus, so −255 reads as −FF. That is the honest, width-independent view. Hardware and most languages instead use two's-complement at a fixed width, where the top bit carries a negative weight. To find −6 in an 8-bit two's-complement byte: write +6, flip every bit, then add 1.

The same bit pattern 1111 1010 is 250 if the byte is unsigned and −6 if it is signed — the bits alone never tell you which. That ambiguity is exactly why two's-complement means nothing until you fix a width and a signedness. The fixed-width panel above does exactly that: choose 8/16/32/64-bit and signed or unsigned, and it prints the value's two's-complement pattern together with both readings, so you can watch −1 become 0xFF at 8-bit and 0xFFFFFFFF at 32-bit. Every bit in the panel is itself a clickable toggle — flip bit 7 of a zero byte in Signed mode and the value jumps straight to −128, the fastest way to feel why the top bit carries negative weight. A value too big for the width is flagged rather than quietly truncated. The bitwise calculator beside it runs AND / OR / XOR / NOT, left/right shifts and left/right rotates at that same width using exact BigInt math, so even 64-bit operations are correct to the last bit. Shifts discard the bits that fall off the end; rotates feed them back in at the other end, which is why 0x80 ROL 1 is 0x01 at 8 bits but 0x80 << 1 is 0x00.

Why BigInt matters here

Plain JavaScript numbers are 64-bit floating point, which represent integers exactly only up to 2⁵³ − 1 (9 007 199 254 740 991). Beyond that, the familiar parseInt/toString route silently corrupts the low digits — parseInt("9007199254740993") already comes back as 9007199254740992. This converter instead parses and formats with native BigInt, which holds integers of unbounded size precisely. That is what lets a 256-bit hex hash, a 50-digit decimal, or a very long binary string round-trip digit-for-digit with no loss. The stat tiles report the bit length (bits in the magnitude), the byte count (bits rounded up to whole bytes), and the number of decimal digits, so you can size a field or a buffer at a glance. Digit grouping is cosmetic — binary and hex group in fours, decimal and octal in threes — so toggle it off to paste an unbroken string into code.

How a float stores a number (and what the inspector shows)

Two's-complement answers "how is an integer laid out in a register". IEEE‑754 answers the same question for values with a fractional part, and it does it with three fields packed into one word: a sign bit, a biased exponent, and a mantissa (the fraction). A 32-bit float splits as 1 + 8 + 23 bits with exponent bias 127; a 64-bit double splits as 1 + 11 + 52 with bias 1023. The two 16-bit layouts the inspector also decodes make the trade-off explicit: IEEE binary16 (half) is 1 + 5 + 10 with bias 15, so it holds about 3 decimal digits and tops out at 65 504, while bfloat16 keeps binary32's 8-bit exponent and bias 127 and truncates the mantissa to 7 bits — a float's full range (up to ~3.4e38) with barely 2 decimal digits of precision, which is why it is the one that drops into a training loop without rescaling. For an ordinary (normal) value the number is (−1)^sign × 1.mantissa × 2^(exponent − bias) — the leading 1 is implied, never stored, which buys one extra bit of precision for free.

Worked example, −1.5 as a double. The sign bit is 1. In binary 1.5 is 1.1, already normalised, so the unbiased exponent is 0 and the stored exponent field is 0 + 1023 = 1023 = 01111111111. The mantissa is the part after the implied leading 1, so it is a single 1 followed by 51 zeros. Concatenate the three fields and you get 0xBFF8000000000000 — paste that into the inspector's input and it decodes straight back to −1.5.

The interesting cases are the ones the fields cannot express normally, and the inspector labels each with a badge. An exponent field of all zeros means the implied leading 1 is dropped: that is a subnormal (mantissa non-zero) or zero (mantissa zero, and the sign bit still applies — which is why -0 exists and prints as -0). Subnormals are what let a double degrade gracefully towards zero instead of falling off a cliff: the smallest positive double is 0x0000000000000001 = 2⁻¹⁰⁷⁴ ≈ 4.94e−324, but by then only one bit of precision is left. An exponent field of all ones is the other reserved end: mantissa zero means Infinity (0x7FF0000000000000), and any non-zero mantissa means NaN — which is why there are 2⁵³ − 2 distinct NaN bit patterns and why NaN !== NaN.

The column the inspector adds that a language REPL will not give you is the exact stored decimal. Because a finite float is always an integer times a power of two, its decimal expansion is finite — but it can be long: 0.1 needs 55 decimal places, and 2⁻¹⁰⁷⁴ needs 1074. Runtimes print the shortest decimal that round-trips back to the same bits (that is the Ryū/Grisu rule behind console.log(0.1) printing 0.1), so the digits you normally see are a convenience, not the value. This page rebuilds mantissa × 2^exponent with BigInt and prints every digit, which is the quickest way to settle a "why is my total off by 0.000000000000001" argument. If you need decimal arithmetic that behaves the way money does, the fix is not a different converter — it is a decimal type (BigDecimal, Python's decimal, or integer cents).

How this compares to your OS calculator

Windows Calculator's programmer mode and macOS Calculator's programmer view (⌘3) are genuinely good at this job, and both work offline. Windows Calculator shows hex, decimal, octal and binary simultaneously, lets you toggle individual bits on a clickable bit keypad, offers QWORD/DWORD/WORD/BYTE widths, and does AND/OR/XOR/NOT plus shifts and rotates. macOS Calculator's programmer view gives hex, decimal and octal readouts over a clickable 64-bit display with the same core bitwise operations. If you only ever need widths up to 64 bits and the four canonical bases, they are excellent tools — keep using them.

This page differs in three concrete ways. It is not capped at 64 bits: BigInt math means a 256-bit hash or a 60-digit decimal converts exactly, where a desktop calculator overflows. It covers every base from 2 to 36, not just binary/octal/decimal/hex — and 2 to 62 once case-sensitive digits are on — so base-32 identifiers, base-36 IDs and base62 short-IDs all convert directly. And a conversion here is a copyable URL, so you can paste the exact input and result into a chat, an issue, or a code review. The clickable bit keypad that used to be a desktop-only advantage is now here too: every bit of the chosen 8/16/32/64-bit width in the fixed-width panel is a toggle button, so you can flip bit 31 and watch the sign change, just as in Windows Calculator. Bit rotates are here too: the bitwise panel's A ROL B and A ROR B chips rotate within the selected 8/16/32/64-bit width, so no bit is lost — 0x80 ROL 1 at 8 bits is 0x01, and because the amount is folded modulo the width, a rotate by the full width is the identity. The desktop apps still win where they always did — keyboard-first number entry, and being one keystroke away with no browser open — so if that is your workflow, keep using them. This page also works on a phone or a locked-down machine where installing anything is not an option.

Common mistakes

Reading a leading zero as octal. In C, Go, and older JavaScript, 0377 is octal 255, not decimal 377 — a stray leading zero silently changes the value. Modern languages prefer the explicit 0o prefix to kill that ambiguity. Mixing signed-magnitude and two's-complement. Expecting −1 to look like FF (byte), FFFF (word) or a leading minus depends entirely on width and signedness; decide those first. Uppercase vs lowercase hex. FF and ff are the same value, but a case-sensitive string compare or a checksum over the text will call them different — normalise before comparing. Off-by-one on bit width. An 8-bit field holds 0–255, not 0–256; the count of values is 2⁸ but the maximum is 2⁸ − 1. Assuming float precision. Converting a number bigger than 2⁵³ with parseInt/Number quietly drops low digits — use BigInt (as this tool does) for anything hash- or ID-sized.

Honest limits

The converter accepts a radix point, and the fractional expansion is exact arithmetic on a rational. The digits after the point are held as the fraction numerator / base^places and multiplied by the target base one digit at a time, so nothing is ever routed through a float. How many fractional digits get printed is your call: the Fractional digits control offers 40 (the default), 200 and 1000, and it re-derives every row the moment you change it. At every one of those settings the digits shown are an exact prefix, never a rounded value, and the row says how many were left out — that guarantee comes from the arithmetic, not from the size of the window, so the last digit at 1000 is as exact as the first at 40. Raising the setting does not simply buy more digits, because the cycle length is settled before any digit is emitted: where the whole cycle fits inside the budget it is printed once under an overline instead of being expanded to the limit — a complete answer, and usually far shorter than the number of digits you asked for. 0.123 decimal in binary is a 40-digit prefix at the default and, at 200, the complete expansion — 3 non-repeating bits and all 100 cycle digits under one overline, with nothing left out at all. The control is bounded by the wall clock rather than by taste. Emitting a fractional digit costs one multiply and one division by the denominator, so the walk costs roughly digits × bits of the denominator units of work — measured on this build at a little over a million of those units per millisecond, and near-linear all the way from a 100-digit fraction to a 50 000-digit one. All five rows at 1000 digits take about a millisecond for a value like 3.14159265358979, and a few milliseconds for one with a hundred digits after the point. A request dearer than about 40 ms a row — which at the top preset means roughly 18 000 digits after the point — is refused, with that arithmetic spelled out, rather than started; a tab that never comes back is a worse failure than a tool that says no. One honest caveat on that guard: reading a pasted number with tens of thousands of digits into an exact rational in the first place is quadratic and costs the same at every setting, so it is slow before the precision control is involved at all, and the refusal does not claim otherwise. The verdict is not windowed at all. Whether an expansion terminates or repeats, and how long its cycle is, is settled before a single digit is emitted: reduce the fraction, and for each prime p that divides the target base take ceil(e/c), where e is that prime’s exponent in the denominator and c its exponent in the base — the largest of those is the number of non-repeating digits. Divide those primes out; if what remains is 1 the expansion terminates, and otherwise the cycle length is the multiplicative order of the base modulo that leftover. So 0.123 decimal in binary is reported as repeating · 3 non-repeating digits, then a 100-digit cycle — the cycle closes at digit 103, outside the 40-digit default but inside the 200 setting, and the tool names it exactly either way. 3.14159265358979 in binary is likewise not a mystery: it is 314159265358979/10¹⁴, which gives 14 non-repeating bits and then a cycle 4,882,812,500 digits long. That is the honest residue — a period can be far too long to print, so we report its length instead of expanding it. One bound survives: past a 4096-bit denominator the tool declines to compute the cycle length and says the cycle is too long to measure rather than guessing; the terminating-or-repeating verdict is still exact there. And note what such a value is: typing 3.14159265358979 enters a rational, not π. A genuinely irrational number has no repeating expansion in any integer base, and no tool can show you more than a prefix of it. Fixed-width, two's-complement, the bitwise panel and the bit-length stats stay integer-only and blank out while a point is present; the float inspector accepts a fractional value but answers a different question — it decodes how a machine float encodes that value in 16, 32 or 64 bits, not what 3.5 looks like in base 7. The float panel covers four layouts — the IEEE‑754 binary16, binary32 and binary64 formats plus bfloat16, which is not in the standard but is what much ML tooling stores — and stops there: x87's 80-bit extended format and the IEEE decimal formats (decimal32/64/128) are genuinely not supported. The main multi-base view uses signed-magnitude (a leading minus); fixed-width two's-complement lives in its own panel above, where a width and signedness are chosen explicitly. And the maximum base is whatever the digit alphabet can spell. Read case-insensitively — the default — that ceiling is 36: 0–9 A–Z is the widest alphabet in which FF and ff must mean the same number. Tick Case-sensitive digits and letter case becomes a distinct symbol, giving 62 and unlocking bases 37–62 — including the base62 that short-URL and short-ID schemes use. The ordering implemented is the GMP one, 0–9 = 0–9, A–Z = 10–35, a–z = 36–61, and the page prints that mapping while the mode is on. It is not the only base62 in the wild: some libraries order lowercase before uppercase (0–9 a–z A–Z), and the same string then means a different number — 1z is 1×62 + 61 = 123 here but 1×62 + 35 = 97 there. Check your library's alphabet before trusting a cross-system round-trip. Base64 is absent on purpose and is not a gap: +/ (or -_ in the URL-safe variant) is an alphabet for encoding byte streams in 6-bit chunks with padding rules, not a positional numeral system with a digit ordering, so “this number in Base64” is not a well-posed question and the tool will not fake an answer to it.

FAQ

How do I convert decimal to hex by hand?

Divide by 16, write down every remainder, and read the remainders from the last division back to the first. For 156: 156 ÷ 16 = 9 r 12, and 12 is C; then 9 ÷ 16 = 0 r 9. Read bottom-up: 9C. Open Show the steps in the result panel and the tool writes that same working out for whatever number you typed — plus the multiply-and-add pass it uses to read a non-decimal input, and the bit-regrouping shortcut when the input and output bases are both powers of two. A trace longer than 40 rows shows the first 36 and the last 4 and says how many steps were elided; the answer itself is never truncated.

How do I convert decimal to hexadecimal?

Set the input base to Decimal, type your number (for example 255), and read the Hex row — it updates to FF as you type. Under the hood the tool repeatedly divides the value by 16 and maps each remainder 0–15 to the digits 0–9 and A–F, so 255 = 15×16 + 15 = FF. Because every conversion runs on JavaScript BigInt, a 40-digit decimal converts to hex with no rounding, unlike a naïve parseInt route.

How do I convert decimal to binary?

Choose Decimal as the input base, enter the number, and the Binary row shows the base-2 form grouped in nibbles of four bits for readability. The value 13 becomes 1101, which is 8 + 4 + 0 + 1. The bit length stat tells you how many bits the number needs — 13 needs 4 bits, and 255 needs 8 bits (one byte). Untick Group digits if you need an unbroken string to paste into code.

Does this lose precision on very large numbers?

No. Every value is parsed and formatted with native BigInt arithmetic, which represents arbitrarily large integers exactly. A regular JavaScript number (a double) only holds integers precisely up to 2⁵³ − 1, about 9 quadrillion; past that, digits silently change. This converter has no such ceiling, so a 256-bit hexadecimal hash or a 60-digit decimal converts digit-for-digit correctly.

Why do programmers use hexadecimal instead of binary or decimal?

Because one hex digit is exactly four bits, hex is binary at a readable density: a 32-bit value is 8 hex characters instead of 32 binary ones, and a byte is always exactly two hex digits. Decimal has no such alignment — you cannot look at 3 735 928 559 and see its bytes, but the same value as 0xDEADBEEF shows all four at a glance (DE AD BE EF). That is why memory addresses, CSS colors, MAC addresses and hash digests are conventionally written in hex.

What does 'base 2 to 36' mean, why 36, and how do I get base 62?

A base (or radix) is how many distinct digits a place-value system uses: base 2 uses 0–1, base 10 uses 0–9, base 16 adds A–F. Thirty-six is the ceiling only while digits are read case-insensitively: the ten digits 0–9 plus the twenty-six letters A–Z give 36 symbols, and that is the widest alphanumeric radix in which FF and ff have to mean the same number. Case-insensitivity is a choice, and here it is yours — tick Case-sensitive digits and upper and lower case become different digits, which gives 62 symbols and unlocks bases 37 to 62, the base62 that short-URL and short-ID systems actually use. The ordering implemented is the GMP one: 0–9 are digits 0–9, A–Z are 10–35, a–z are 36–61, so Z is digit 35 and z is digit 61. That ordering is not universal — some libraries put lowercase first (0–9 a–z A–Z), which gives a different number for the same string — so the page prints the active mapping while the mode is on, and you should check your own library's alphabet before trusting a cross-system round-trip. Set the Custom base field to anything from 2 to 36, or 2 to 62 with case sensitivity on, to convert to and from it live. Base64 is deliberately not offered: its +/ characters are an alphabet for encoding byte streams in 6-bit chunks with padding, not a positional numeral system with a digit ordering, so “this number in Base64” has no single right answer and the tool will not invent one.

What happens if I type a digit that is invalid for the base?

You get a clear inline message naming the offending character and the digits that are legal: type 2 while the input base is Binary and it reads '2' is not a valid binary digit (allowed: 0–1). Nothing crashes and the tool never calls eval; the input is parsed one digit at a time against the allowed alphabet for the chosen base, so an illegal digit is rejected safely instead of producing a wrong answer.

Can it handle negative numbers and show two's-complement?

Yes to both. The main converter shows negatives in signed-magnitude form — a leading minus carried through every base, so −255 reads as −FF in hex and −11111111 in binary. For fixed-width two's-complement, use the fixed-width panel above: pick 8/16/32/64-bit and signed or unsigned, and it shows the exact bit pattern plus what it means under each reading. The same byte 11111010 is 250 unsigned but −6 signed — the bits alone never say which, so two's-complement only has meaning once you declare a width and a signedness, which the panel makes you choose explicitly. Every bit in that panel is also a clickable toggle: flip any bit and the value is rewritten in every base under your chosen signedness. A value that will not fit the chosen width is flagged, not silently wrapped.

What is the difference between a logical and an arithmetic right shift?

Both move bits toward the least-significant end; they differ only in what fills the vacated high bits. A logical right shift (>>>) always fills with zeros, treating the value as unsigned — so at 8 bits 0b10000000 (128) shifted right by 1 gives 0b01000000 (64). An arithmetic right shift (>>) copies the sign bit inward, so a two's-complement negative stays negative — the same byte read as signed is −128, and −128 shifted right by 1 gives 0b11000000, which is −64. The bitwise panel offers both and labels which is which, because the difference matters exactly when the top bit is set.

Why are Unix file permissions written in octal like 755?

Because each octal digit is exactly three bits, and Unix groups permissions in threes: read, write, execute for owner, group and others. So 755 means owner 7 = 111 = read+write+execute, group and others 5 = 101 = read+execute. Type 755 with input base Octal here and the Binary row shows 111101101, the nine permission bits in order. Octal survives in modern computing almost entirely because of this three-bits-per-digit fit.

What is base 36 used for in practice?

Compact, case-insensitive alphanumeric IDs. With digits 0–9 and A–Z, six base-36 characters cover 36⁶ = 2 176 782 336 values — over two billion in six characters that survive URLs, filenames and case-insensitive systems unchanged. JavaScript supports it natively via toString(36) and parseInt(str, 36), and Reddit's public post IDs are base-36 strings. Base 62 packs tighter — six base-62 characters cover 62⁶ = 56 800 235 584 values, 26 times as many — but it needs case sensitivity, which breaks the moment an ID passes through a case-insensitive filesystem or gets read aloud. That is a trade-off, not a limit of this page: tick Case-sensitive digits and the Custom base field goes up to 62.

Can this converter handle a decimal point?

Yes. Type 3.5, 0.1 or ff.8 and every row converts both halves. The integer part goes through the same BigInt path it always did; the digits after the point are held as the exact fraction numerator ÷ base^places and multiplied by the target base one digit at a time, so no floating-point number is involved anywhere. Each row then labels what actually happened. 3.5 decimal is 11.1 in binary — terminating. 3.5 decimal in base 5 is 3.222… — repeating, because the halving factor 2 divides no power of 5, and the row shows it as 3.(2) with the 2 overlined. 0.1 decimal in binary is 0.0(0011). 8.4 decimal in base 5 is 13.2, terminating. Where a cycle is longer than the digits printed the row still names it exactly — 0.123 decimal in binary reports 3 non-repeating digits, then a 100-digit cycle, because the label comes from arithmetic on the denominator rather than from the digits on screen — and the digits shown are an exact prefix rather than a rounding, at every precision setting.

How many digits after the point can it print?

As many as you ask for, within a stated budget. The Fractional digits control offers 40, 200 and 1000; 40 is the default, so a page you have not touched prints exactly what it always printed. The choice is live — every row re-derives the instant you pick a preset, there is no Generate button. Because the cycle length is computed from the denominator before any digit is emitted, a bigger budget frequently buys a complete answer rather than simply more digits: any expansion whose whole cycle fits is printed once under an overline, which is usually far shorter than the digits you asked for. 0.1 in base 7 converted to base 3 is 0.(010212) at every setting, because its cycle is only six digits long; 0.123 decimal in binary is a 40-digit prefix at the default but its complete 103-digit expansion at 200. When the cycle genuinely does not fit — 3.14159265358979 in binary repeats with a period of 4,882,812,500 — you get an exact prefix of the requested length and a row that still states the true cycle length. Nothing is ever rounded to make it fit. The ceiling is wall clock, not preference: a request whose expansion would cost more than about 40 ms per row (roughly 18,000 digits after the point at the top preset) is refused with the reason printed, because a frozen tab is a worse failure than a refusal.

Why doesn't 0.1 convert cleanly to binary?

A fraction terminates in a base only if its reduced denominator divides a power of that base. 1/10 has denominator 10 = 2 × 5, and the factor 5 shares nothing with 2, so in binary 0.1 is the infinite repeat 0.0(0011) — one 0, then 0011 forever. Type 0.1 into the converter above with input base Decimal and the Binary row shows exactly that, overlined and flagged as repeating with a 4-digit cycle. The tool proves the repeat rather than guessing it: it tracks the exact rational remainder after every digit, and when a remainder it has already seen comes round again, the digits from that point must repeat. A 64-bit float cannot store an infinite repeat, so it cuts the mantissa off and actually holds 0.100000000000000005551…, which is why 0.1 + 0.2 evaluates to 0.30000000000000004 in most languages. The IEEE‑754 float bit inspector on this page shows that second half: type 0.1 there and it gives the sign, exponent and mantissa bits actually stored, plus the full exact decimal those bits mean.

Why does 0.1 show as 0.1000000000000000055511151231257827021181583404541015625?

Because that is the exact value a 64-bit double holds when you write 0.1 — the bit pattern 0x3FB999999999999A, which means the integer 3 602 879 701 896 397 divided by 2⁵⁵. Every finite binary float is an integer times a power of two, so it always has a finite decimal expansion; this one runs to 55 decimal places. Languages do not print all of it — they print the shortest decimal that round-trips back to the same bits, which is 0.1. The float inspector expands the true stored value with BigInt instead of rounding, so you can see which digits are real and which are printing convenience. At 32-bit width the same literal stores as 0x3DCCCCCD = 0.100000001490116119384765625, a different number entirely — which is why a value can shift when it moves between a float and a double.

What is the largest integer JavaScript can safely represent?

With a plain Number, 2⁵³ − 1 = 9 007 199 254 740 991 (Number.MAX_SAFE_INTEGER). Beyond it, doubles have gaps between representable integers: 9007199254740993 cannot be stored and silently becomes 9007199254740992. BigInt has no such ceiling — it grows to whatever fits in memory — which is why this converter uses BigInt for every parse and format, and why a 256-bit hash converts digit-for-digit.

What is −5 in 8-bit two's-complement?

11111011, which is 0xFB. The recipe: write +5 as a byte (00000101), invert every bit (11111010), add 1 (11111011). Check it by giving the top bit its negative weight: −128 + 64 + 32 + 16 + 8 + 2 + 1 = −5. The same byte read as unsigned is 251, which is 256 − 5 — two's-complement is literally "count backwards from 2⁸". Reproduce it live in the fixed-width panel above: type −5, pick 8-bit and Signed.

Why does "invert and add 1" produce the negative?

Inverting every bit of an n-bit value x gives (2ⁿ − 1) − x, because each bit position flips to its complement. Adding 1 makes it 2ⁿ − x — exactly the wrap-around representation of −x modulo 2ⁿ. That is why x plus its two's-complement always sums to 2ⁿ, which overflows to 0 in n bits: 00000101 + 11111011 = 1 00000000, and the ninth bit falls off the end of the byte.