Hex to Decimal Converter

Converting hex to decimal by hand

Each digit has a place value that is a power of 16, counting from zero on the right. Multiply, then add. For 2F:

The same procedure works for any base — swap 16 for 2, 8 or whatever you have. Going the other way, divide repeatedly by the base and read the remainders bottom to top.

The digits, for reference

Why hex at all, when we can count in decimal?

Because one hex digit is exactly four bits, and decimal lines up with nothing. That single fact is the whole reason hex exists in computing.

A byte is always two hex digits. A 32-bit value is always eight. Converting between hex and binary needs no arithmetic at all — you replace each hex digit with its four bits, straight off the table above:

3F → 0011 1111 → 00111111

Try that with decimal 63 and there is no shortcut; you have to actually divide. That is why memory addresses, colour codes, permission masks and register dumps are all written in hex. It is not tradition, it is that the boundaries land in the right places.

Two's complement, or why 0xFFFFFFFF is sometimes −1

This trips people up constantly, and it is the reason the panel above exists.

A run of bits does not carry any information about whether it is signed. Read 0xFFFFFFFF as an unsigned 32-bit number and it is 4,294,967,295. Read the identical bits as a signed 32-bit number and it is −1. Both are correct. Which one you want depends on what the code that produced it thinks it is holding, and the hex alone cannot tell you.

The rule computers use is two's complement: if the top bit is set, the value is negative, and its magnitude is the value subtracted from 2^width. So at 8 bits, 0xFF is 256 − 255 = 1, hence −1. At 32 bits the same reasoning gives −1 from 4,294,967,296 − 4,294,967,295.

The practical version: if you are staring at a suspiciously enormous number in a debugger — 4 billion, or 18 quintillion — it is almost always a small negative number being read as unsigned. Check the signed column.

Large numbers, and where converters go wrong

JavaScript's ordinary number type holds integers exactly only up to 2⁵³ − 1, about 9 quadrillion. Past that, values are rounded to the nearest representable one.

This matters more than it sounds, because a 64-bit register value, a Snowflake ID or a truncated hash all exceed it comfortably. A converter built on parseInt does not refuse those — it returns a number that looks entirely plausible and is wrong in the last few digits. Nothing warns you.

This tool uses BigInt throughout, which is exact at any width. If you want to check any converter for the problem, paste in FFFFFFFFFFFFFFFF: the correct decimal answer is 18446744073709551615. A tool that ends in ...1616 or ...1600 is rounding.

How to use it

Type into whichever box matches what you have; the rest update on every keystroke. Prefixes are optional — 0x1F, 1F and 1f are all accepted, as are 0b and 0o. Underscores and spaces are ignored, so 1010_1111 works. A minus sign is fine too, and the signed panel will show how that value looks at each width.

Questions

Related tools

Browse all Sigma Wire tools - every free tool on the site, grouped by category.