Hex to decimal, and everything else those bytes mean

Multiply each digit by 16 raised to its position, counting from zero on the right, and add the results. For 0x2F3 that is 2×256 + 15×16 + 3×1 = 512 + 240 + 3 = 755. The digits above 9 are the only thing to memorise — A is 10, B 11, C 12, D 13, E 14, F 15 — and the doubling trick helps for round values: 0x100 is 256, 0x1000 is 4096, and each extra zero multiplies by 16.

Because they hand it to parseInt or Number, and both produce a 64-bit float that cannot represent integers above 9,007,199,254,740,991 exactly. parseInt("1FFFFFFFFFFFFFFF", 16) answers 2305843009213694000 when the true value is 2305843009213693951 — quietly 49 too high — and Number("0x20000000000001") loses its last digit the same way. This page never converts to a float: the digits go straight into a BigInt, which has no ceiling, so a 64-bit register value, a Snowflake ID or a 512-bit hash all come out digit for digit.

Because in binary those numbers are not what they look like, and hex shows it immediately. Written as a raw IEEE-754 double, 0.1 is 3FB999999999999A and 0.2 is 3FC999999999999A — both ending in A, both rounded up from a repeating fraction, because a tenth is no more expressible in base 2 than a third is in base 10. Add them and you get 3FD3333333333334, while the double closest to 0.3 is 3FD3333333333333: the two differ by one unit in the last place, which prints as 0.30000000000000004. Paste either of those 16-digit values into this page and the IEEE-754 reading will hand you back the number it stands for.

It is a marker inherited from C that tells a compiler the digits after it are base 16, and it is not part of the number — 0x1F and 1F are the same 31. You never have to type it here, and five other conventions are accepted as well: # for CSS colours, U+ for Unicode code points, \x inside string escapes, a trailing h from assembly listings, and &#x…; from HTML entities. Different ecosystems settled on different markers because bare digits are ambiguous: 10 is ten in decimal and sixteen in hex, and only the prefix tells you which was meant.

You cannot, until you know how wide the register is — the same bits mean 4,294,967,294 as an unsigned 32-bit value and −2 as a signed one. Two's complement is the agreement that makes the second reading work: the top bit carries a negative weight, so in 32 bits the pattern is worth −2³¹ + the rest. That is why the width table on this page lists each width separately instead of picking one for you, and why a value that looks absurdly large in a debugger is usually a small negative number read at the wrong width. Typing a minus sign in front of a hex value here works too, and the table shows which register the result would fit in.

It is a magic number — a value chosen to be recognisable when it turns up somewhere it should not. Because hex uses the letters A to F you can spell a limited vocabulary with it, and programmers have used that for decades: 0xDEADBEEF marks freed or uninitialised memory on several platforms, 0xCAFEBABE is the first four bytes of every Java .class file, 0xFEEDFACE identifies a 32-bit Mach-O binary on macOS, and 0x8BADF00D is the code iOS records when the watchdog kills an app for taking too long to launch. Spotting one in a hex dump usually means you are reading memory that was never initialised with real data.

Yes — paste one value per line and the page switches from the single-value inspector to a table with decimal, hex and binary for each row. Up to 1,000 lines are read at a time, a thousand rows convert in about a tenth of a millisecond, and the whole table copies as tab-separated text that pastes straight back into a spreadsheet. Lines that are not valid hex keep their place in the table with the reason beside them, so a bad row never silently shifts everything below it.