Free Binary, Hex & ASCII Tools
Converters for the low-level building blocks: text ↔ binary, text ↔ hex, ASCII reference table. Runs in your browser.
Picking the right base for the job
Usually you know which base you want; the question is how to get there without opening a Python REPL. Binary is for bitmasks and flags: file permissions rwxr-xr-x read as 111101101, which is 0755 in octal and 493 in decimal. Hex is for bytes, because two hex digits map exactly onto one byte with no arithmetic in your head. Decimal is for humans, and for the one log field someone decided to print as an integer.
The conversions that trip people up cross a byte boundary. 0xFF is 255 unsigned but -1 as a signed 8-bit value, and nothing in the number itself tells you which reading is correct. You have to know the width and the signedness from the spec. If a decoder hands you 4294967295 where you expected a small negative number, that is a 32-bit two's complement value printed unsigned.
Byte order will bite you
The bytes 00 00 01 00 are 256 read big-endian and 65536 read little-endian. Network protocols are big-endian by convention, the network byte order that htons and htonl convert to; x86 and ARM memory dumps are little-endian. A hex value copied out of a debugger's memory view usually needs reversing before it matches the protocol documentation, and an absurdly large result is the tell.
Reading character codes without guessing
ASCII stops at 127. Everything from 128 to 255 depends on which encoding the file was written in, and that is where most "weird character" bugs live. The classic symptom is ’ where a curly apostrophe should be: the UTF-8 bytes E2 80 99 displayed one byte at a time through Windows-1252. Something declared the wrong charset; the underlying bytes are intact.
Landmarks worth memorising: 0x30 is 0, 0x41 is A, 0x61 is a. Upper and lower case sit exactly 32 apart, which is why case flipping used to be a single XOR with 0x20. Below 0x20 are the invisible characters that break parsers: 0x09 tab, 0x0A line feed, 0x0D carriage return, and 0x00 null, which truncates strings in anything C-adjacent.
Spotting a bad result
- Hex with an odd number of digits is an incomplete byte.
0xABCis either0ABCor a truncated paste. - A binary string whose length is not a multiple of 8 lost its leading zeros. Pad on the left, never the right.
- Decoded text starting with
EF BB BFcarries a UTF-8 byte order mark. Strip it, or your equality check fails for no visible reason. - If every second character of your output is a null, you are reading UTF-16 as single-byte.
Checking any of this means pasting the suspect bytes somewhere, and those bytes are often a session token or a slice of a memory dump. These tools convert in the browser, so the input never leaves the page: no request to audit, nothing in a third party's logs.
Common questions
Why does my hex converter disagree with my calculator? Almost always signedness or width. A calculator in programmer mode set to a 16-bit word reads 0xFFFF as -1; a plain converter reads 65535. Check which width the tool assumes before assuming it is wrong.
What is the difference between 0x1F, 1Fh and 00011111? Nothing, the same value written three ways. 0x is the C and JavaScript prefix, trailing h is assembler notation, the third is binary. Some tools reject the prefix, so strip it if you get a parse error.
Do I need to worry about ASCII versus UTF-8? Not for codes 0 to 127, where UTF-8 is byte-for-byte identical to ASCII. Above that they diverge: an accented character is two bytes, an emoji four.
How many bits do I need for a given number? Base-2 logarithm, rounded up. 1000 needs 10 bits, a million needs 20, and an unsigned value in n bits maxes out at 2^n - 1. Signed values spend one bit on the sign, which is the whole 2038 problem: a signed 32-bit Unix timestamp stops at 2147483647, or 03:14:07 UTC on 19 January 2038. Read the same field unsigned and it lasts to 2106.