Free Number Tools

Which converter for which job

Base conversion questions usually come from three places: a colour in a stylesheet, a permission bitmask in a shell, or a register dump in a debugger. #ff8800 is rgb(255, 136, 0). chmod 0755 reads as rwxr-xr-x because 7 is 111 and 5 is 101. Flags and masks want binary (a byte of 0x2A is 00101010), bytes and colours want hex, octal survives mainly in permissions.

Prefixes tell you the base, until they don't

Python 3, Go, Rust and JavaScript since ES6 all take 0x for hex, 0b for binary, 0o for octal. Older code does not. In C and in legacy JavaScript a bare leading zero means octal, so 010 is 8, while Python 3 rejects 010 rather than guessing. In JavaScript parseInt("ff") returns NaN and parseInt("ff", 16) returns 255, so a forgotten radix is a common source of silent wrong answers. Strip the prefix before pasting unless the tool states that it accepts one.

Signed values and the 53-bit ceiling

A converter that assumes unsigned input turns 0xFFFFFFFF into 4294967295. If that value came out of a C int32_t it means -1, and nothing in the digits says which you meant. The other trap is size: above 9007199254740991 (2^53 - 1) a JavaScript number loses precision, so a 64-bit hash like 0xDEADBEEFCAFEBABE comes back wrong in the low digits without BigInt. Round-trip the result and compare strings character by character.

Roman numerals, and why 3999 is the limit

Standard form allows subtraction in exactly six pairs: IV, IX, XL, XC, CD, CM. Everything else is additive, written largest first, so 1984 is MCMLXXXIV and 2026 is MMXXVI. There is no zero and no character above M, which puts the ceiling at MMMCMXCIX (3999). Higher values need a vinculum (an overbar meaning multiply by a thousand), which fonts and databases handle badly. Spreadsheets draw the line in the same place: Excel's ROMAN() returns #VALUE! for anything above 3999.

Clock faces printing IIII for four follow a typographic convention; do not copy it into data a parser will read. When parsing numerals typed by a person, normalise case, then reject broken sequences (IIII, VX, IL) rather than guessing.

Random numbers you can defend

Two questions decide the generator: must the result be unguessable, and must you be able to re-run it? Anything reproducible is guessable by whoever holds the seed.

Unguessable is not the same as random-looking

A browser's Math.random() is a fast PRNG (xorshift128+ in most engines) with no security guarantee, and its state can be recovered from a run of outputs. Use crypto.getRandomValues() for tokens, passwords, session identifiers and anything with money attached. Use a seeded generator, and record the seed, for test fixtures you will need to replay after a failure.

Bias creeps in at the last step

Taking a random byte and applying % 6 for a dice roll favours the low faces, because 256 is not divisible by 6. Discard bytes of 252 and above, then take the remainder. For shuffling use Fisher-Yates, not sort(() => Math.random() - 0.5), which gives measurably uneven orderings.

Common questions

Why does my hex to decimal result disagree with my debugger? Almost always signedness or width. The debugger knows the value is a signed 32-bit integer; a converter given bare digits does not.

What is the largest Roman numeral I can write? MMMCMXCIX, or 3999, in standard notation. Anything higher needs overbar notation, and there is no numeral for zero at all.

Are these random numbers good enough for a prize draw? The numbers are; the audit trail is not. crypto.getRandomValues() takes no seed, so nobody can re-run your draw afterwards and check it. If the result may be contested, publish the entrant list and the seed first, then draw with a seeded generator anyone can repeat. Regulated gambling needs certification no web page carries.

Does anything I paste get uploaded? No. Conversion runs in JavaScript on the page in front of you. Open the network tab and convert something; there is no request to watch.