Hex to Decimal Converter — Convert Hexadecimal to Decimal with Step-by-Step Breakdown

What is a hex to decimal converter?

A hex to decimal converter takes a number written in base-16 (hexadecimal) and returns the same numeric value written in base-10 (decimal) — the everyday counting system most people use. Hexadecimal is compact and maps cleanly onto binary, which is why it appears everywhere in computing: memory addresses, byte values, colour codes, file magic numbers, register dumps, hash digests. Decimal is what humans read and reason about. Converting between the two is a routine operation that developers, security researchers, and hardware engineers do constantly.

The conversion itself is not difficult once you know the rule, but it is easy to make small errors when doing it by hand — especially on long values like 0xDEADBEEF or 0x7FFFFFFF. This tool does it exactly, shows the step-by-step arithmetic that produces the result, and handles the two interpretations that people often confuse: unsigned (the raw magnitude) and signed (two's complement, where the top bit means the value is negative).

It accepts the formats you actually paste — with or without a 0x prefix, uppercase or lowercase letters, with spaces, underscores, or continuous digits. It also supports batch conversion: put one value per line and every line is converted independently, which is useful for turning a column of hex bytes from a hex dump into a column of decimal values.

💡 Quick example. 2A in hex is 2 × 16 + 10 × 1 = 42 in decimal. The A stands for 10 because hexadecimal uses A–F for the values 10 through 15 (we ran out of digits after 9).

Why hexadecimal exists — a two-paragraph primer

Computers work in binary: every value is a sequence of 0s and 1s. But binary is verbose. A 32-bit memory address is 32 characters long — unreadable at a glance and prone to being mistyped. Hexadecimal compresses four binary bits into a single character, so a 32-bit address becomes just 8 hex digits. That factor of four is exact and lossless: every nibble (4 bits) maps one-to-one to a hex digit, and every byte maps to two hex digits. There is never any rounding, never any ambiguity.

Base 16 was chosen rather than, say, base 8 or base 32, because 16 is a power of two and because 10 digits plus 6 letters gives exactly 16 symbols without adding new punctuation. The mapping is the same on every modern platform, so a hex value means the same thing in C, Python, JavaScript, ARM assembly, and the Linux kernel. That is why hex persists even though decimal would be easier for humans — hex is easier for the machine, and it is close enough for humans to read.

How hexadecimal to decimal conversion works

Hexadecimal is a positional number system — each digit has a value determined by its position. The base is 16 instead of decimal's base 10, so each position is a power of 16 rather than a power of 10.

• The rightmost digit is the "ones" place: multiply by 16⁰ = 1.
• The next digit left is the "sixteens" place: multiply by 16¹ = 16.
• The next is the "two-fifty-sixes" place: multiply by 16² = 256.
• Then 16³ = 4096, 16⁴ = 65536, and so on.

Digits 0–9 have their usual value; letters A–F stand for 10 through 15. To convert, multiply each digit by its power of 16 and add the products.

Worked example — 0x2A:

1. Digit 2 is at position 1: 2 × 161 = 2 × 16 = 32.
2. Digit A (=10) is at position 0: 10 × 160 = 10 × 1 = 10.
3. Sum: 32 + 10 = 42.

Worked example — 0xDEADBEEF:

1. D (=13) × 16⁷ = 13 × 268,435,456 = 3,489,660,928
2. E (=14) × 16⁶ = 14 × 16,777,216 = 234,881,024
3. A (=10) × 16⁵ = 10 × 1,048,576 = 10,485,760
4. D (=13) × 16⁴ = 13 × 65,536 = 851,968
5. B (=11) × 16³ = 11 × 4,096 = 45,056
6. E (=14) × 16² = 14 × 256 = 3,584
7. E (=14) × 16¹ = 14 × 16 = 224
8. F (=15) × 16⁰ = 15 × 1 = 15
9. Sum: 3,735,928,559

The tool's positional breakdown table shows exactly this calculation for whatever value you paste, digit by digit, with MSB and LSB rows highlighted so you know which digit is the sign bit for signed interpretations.

Common hex values you will recognise

Some hex values appear constantly in documentation, debugging sessions, and technical writing. Knowing what they mean is worth memorising:

Signed vs unsigned — the same hex, different number

Here is the part that trips people up. The hex digits FF do not by themselves tell you what number they represent — they only tell you the bit pattern 1111 1111. Two different interpretations of the same bits give two different decimal values:

• Unsigned 8-bit: all 8 bits contribute to the value → 0b11111111 = 255.
• Signed 8-bit (two's complement): the top bit is a sign bit, so the same pattern means −1.

Two's complement is the standard way almost every modern CPU represents signed integers. The rule is simple: if the most significant bit (MSB) of an N-bit value is 1, the value is negative and equals unsigned − 2N.

💡 Which interpretation should you use? If you are reading raw bytes from a file, network packet, or hex dump, almost always unsigned. If you are looking at a value that came from a signed variable in code (int, int32_t, long), use signed and match the word size of the type.

Word size matters — and why

The word size selector (8-bit, 16-bit, 32-bit, 64-bit) tells the tool how many bits the value occupies. This changes the signed interpretation because two's complement depends on the total width:

• 0xFF as 8-bit signed is −1 (255 − 256).
• The same hex 0xFF as 16-bit signed — 0x00FF — is +255 because the sign bit (bit 15) is 0.
• 0xFFFF as 16-bit signed is −1 (65535 − 65536).
• 0xFFFF as 32-bit signed — 0x0000FFFF — is +65535 because bit 31 is 0.

Auto mode picks the smallest byte-aligned width that fits the unsigned value: 8 bits for anything up to 0xFF, 16 bits up to 0xFFFF, and so on. That matches the intuition that a hex value's width is naturally measured in bytes. If you specifically want to treat a short value as a wider signed number, set the width manually.

Decimal → hex — the reverse direction

Converting decimal back to hex uses repeated division by 16. Take the decimal number, divide by 16, record the remainder (0–15), then divide the quotient by 16 again, until the quotient is 0. Read the remainders in reverse order to get the hex digits.

Worked example — decimal 200 → hex:

1. 200 ÷ 16 = 12 remainder 8 → digit 8.
2. 12 ÷ 16 = 0 remainder 12 → digit C (=12).
3. Read remainders in reverse: C8.

The tool does this automatically in Decimal → Hex mode, and shows the same reverse-division step by step for the first value. Negative decimal values are also supported: the tool applies the two's complement wrap at the selected word size to find the hex bit pattern (for example, −1 in 16-bit → 0xFFFF).

Where hex to decimal conversion shows up

• Reading memory addresses. Debugger output and crash dumps print addresses in hex. Comparing two hex addresses that differ by 0x40 requires knowing they differ by 64 bytes.
• Decoding file permissions. Unix permissions look like 0644 or 0755 — those are octal, and the tool shows octal as a secondary output so you can read them directly. Hex 0x1A4 equals decimal 420 which is octal 0644.
• Byte-level file inspection. When a hex dump shows 89 50 4E 47 at the start, converting 0x89 to decimal 137 tells you it is outside the 7-bit ASCII range, which is a clue that this is binary data, not text.
• Colour codes. CSS hex colours like #FF00AA decompose into 0xFF = 255 red, 0x00 = 0 green, 0xAA = 170 blue. Converting each channel is useful for programmatic colour manipulation.
• Bit masking and flags. A status word of 0x8004 is 0x8000 | 0x0004 — the tool's positional breakdown makes it obvious which bit positions are set.
• Reading cryptography output. MD5 and SHA digests are hex strings. Occasionally you want to interpret a slice as a decimal number — for example to compare against a numeric ID system or a hash bucket size.
• Hardware register values. Datasheets give register values in hex. Converting to decimal makes them easier to compare against sizing limits, thresholds, or tolerance ranges.
• Reverse engineering. When you extract a magic constant like 0xDEADBEEF from a binary, converting to decimal confirms you have the right value and lets you search for it elsewhere in the file.
• Bit-field extraction. Extracting a field like the TCP header's data-offset (4 bits starting at bit 12) is done by masking with 0xF000 and shifting right by 12. The tool's positional breakdown makes the bit positions explicit.

Common mistakes when converting hex to decimal

• Treating hex digits as if they were decimal. 0x10 is not ten — it is 1 × 16 + 0 = 16. 0x100 is not one hundred — it is 256. This is the single most common error.
• Confusing A–F with letters. A in hex is the number 10, not a letter. The digit sequence 2A is 2×16 + 10×1 = 42, not "two-A".
• Mixing sign interpretations. If you read 0xFF as signed when the data is unsigned (or vice versa), you get a decimal value that is off by 256, 65536, 2³², or whatever the word size is.
• Forgetting the word size for signed values. 0xFF as signed 8-bit is −1, but the same digits as signed 16-bit (0x00FF) is +255. Always know how many bits the value is supposed to have.
• Assuming 64-bit word size always means big numbers. A 64-bit signed value with the MSB set can be as large in magnitude as it is positive — but bit 63 is the sign bit, so the maximum positive 64-bit signed value is only 0x7FFFFFFFFFFFFFFF = 9,223,372,036,854,775,807.
• Confusing hex and octal. A leading 0 in many programming languages means octal, not hex. In Python, 010 is 8, not 10 or 16. In C, the same. Only 0x means hexadecimal.
• Mixing up byte order for multi-byte values. 0x1234 is 4660 in big-endian interpretation. If the source is little-endian, the bytes appear as 34 12 and would be read as 0x3412 = 13330. The tool does not swap byte order; use a dedicated byte-swap utility if needed.
• Assuming leading zeros change the value. 0xFF, 0x00FF, 0x0000FF all represent the same number 255 — but their signed interpretation differs because the sign bit moves to a different position. 0xFF as 8-bit signed is −1; 0x00FF as 16-bit signed is +255.

Privacy and data storage

Everything runs in your browser. The conversion, the positional breakdown, the signed/unsigned interpretation, the batch processing, and the reference table filter all happen locally in JavaScript using BigInt for arbitrary-precision arithmetic. Nothing you type is uploaded to a server. There is no account, no login, and no network request after the page has loaded — the tool works offline once the page is cached. Your input is not stored anywhere; refreshing the page clears it.

Limitations

• The tool uses JavaScript's BigInt, so any practical bit width is converted exactly. The word size options are capped at 64 bits because that is the widest integer most programming languages and CPUs support natively; values wider than 64 bits still work on Auto.
• Byte order is not swapped automatically. If you paste little-endian bytes from a capture and expect big-endian interpretation, you need to reorder the bytes yourself.
• The word size selector affects only the signed interpretation, not the unsigned value. Unsigned conversion is always exact regardless of word size.
• Batch conversion is line-based. Each non-empty line is treated as a separate value. Multi-line single values are not supported — join them before pasting.
• Non-integer decimal inputs (like 3.14) are not supported in Decimal → Hex mode — the input must be a whole number. For fractional conversions, use a floating-point hex converter.
• The reference table covers well-known landmarks, not the entire hex range. For an arbitrary value, use the converter above.

Frequently asked questions

Related tools on AIToolsPros