2026-10-18 · 8 min read
- numbers
- hex
- binary
Flashman's number-bases tool converts one decimal integer to binary, octal, and lowercase hex. The implementation trims the field, calls parseInt with radix 10, and, when that call returns a finite number, prints toString(2), toString(8), and toString(16). There is no hex input, no binary input, and no prefix parser.
parseInt reads an optional sign and then decimal digits. It stops at the first other character and keeps what it already accepted. Only a result that is not a finite number becomes the Invalid decimal message. A short parse of a longer string still looks successful.
Put the prefix and the fraction in the notes
42.9 becomes 42. The tool does not round the .9. 10.0 becomes 10. 1e2 becomes 1, because the exponent marker ends the scan. 1_000 becomes 1. 42abc becomes 42. A unit, a thousands separator, or a leftover word is not an error.
0x10 becomes 0, and 0b1010 becomes 0. The letters stop the scan on the first character after the zero. 08 becomes 8, not octal 10, because the radix is 10. Spaces and a leading plus are fine: +42 and a padded 42 both become 42. To convert the hex quantity 10, type the decimal 16. To convert a bit pattern, expand it to decimal yourself and type that.
- Type 255, not 0xFF and not #ff.
- Drop the fractional part before you paste.
- Drop underscores, commas, and unit suffixes.
- Re-read the hex line if the result is 0 and the text was not 0.
A minus sign is not two's complement
-42 prints -101010, -52, and -2a. The sign is a prefix on all three strings. The binary column is not a fixed-width two's-complement encoding, and the hex column is not a register dump. Bit positions only mean what a datasheet says when the value is non-negative and you have chosen a width.
255 prints ff. 10 prints a, not 0a. The tool does not pad to a byte or a word. If you are about to drop the hex into a color channel or a protocol field, add the leading zero yourself when the unpadded form is shorter than the field.
Stay inside exact integers
Integers from 0 through 9007199254740991 are exact JavaScript numbers. That last value prints hex 1fffffffffffff and is a safe integer. 9007199254740993 is not exact: parseInt produces 9007199254740992, the hex column is 20000000000000, and nothing on the page says the digits changed. The same rounding happens if that integer was a JSON number before you copied it.
Do not use this box for a 64-bit identifier, a hash, or a full bitmask wider than 53 bits. Split the value into bytes, or keep it as hex text the whole way. The binary column of a rounded number is a convincing wrong answer.
Check a byte before you build a color
A color channel is an integer from 0 to 255. 255 prints ff and 0 prints 0. The number-bases tool will not turn those two digits into a six-digit color, and the color tool will not parse a lone ff. Build the six-digit hex from three checked channels, then use the color tool on that hex.
Diff the decimal text you typed against the integer implied by the hex line. Use the JSON formatter when the number came from a payload that may already have rounded it. The conversion note should include the original text, because the output columns do not retain the suffix that was ignored.