Tip: use samples, upload, copy, download, and send-to actions inside the workspace where available.
Binary Viewer is a free, browser-based tool that helps you understand a dataset at a glance. View the raw bits of any file alongside ASCII. It's built for speed and privacy: Everything runs locally in your browser — your data is never uploaded to a server. No sign-up, no installs, and no daily limits.
Profile the data first so missing values, types, duplicates, and outliers are visible before you edit it.
Review the preview, copy or download the result, and keep everything local in your browser.
Base Converter: Convert between binary, octal, decimal, hex, base32, base36.
Open tool| offset | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | hex | uint8 | int8 | char |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 00000000 | 0 | 1 | 0 | 0 | 0 | 1 | 0 | 1 | 45 | 69 | 69 | E |
| 00000001 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 00 | 0 | 0 | · |
| 00000002 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 00 | 0 | 0 | · |
| 00000003 | 0 | 0 | 1 | 1 | 1 | 1 | 0 | 0 | 3C | 60 | 60 | < |
| 00000004 | 0 | 0 | 0 | 1 | 1 | 1 | 0 | 0 | 1C | 28 | 28 | · |
| 00000005 | 0 | 1 | 0 | 0 | 0 | 1 | 1 | 0 | 46 | 70 | 70 | F |
| 00000006 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 40 | 64 | 64 | @ |
| 00000007 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 00 | 0 | 0 | · |
| 00000008 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 40 | 64 | 64 | @ |
| 00000009 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 0 | 06 | 6 | 6 | · |
| 0000000a | 1 | 0 | 1 | 1 | 0 | 0 | 0 | 1 | B1 | 177 | -79 | · |
| 0000000b | 1 | 1 | 1 | 0 | 0 | 1 | 1 | 0 | E6 | 230 | -26 | · |
| 0000000c | 0 | 1 | 0 | 0 | 0 | 0 | 1 | 0 | 42 | 66 | 66 | B |
| 0000000d | 0 | 1 | 0 | 0 | 1 | 0 | 0 | 1 | 49 | 73 | 73 | I |
| 0000000e | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 0 | 54 | 84 | 84 | T |
| 0000000f | 0 | 1 | 0 | 1 | 0 | 0 | 1 | 1 | 53 | 83 | 83 | S |
| 00000010 | 1 | 1 | 0 | 0 | 0 | 0 | 1 | 0 | C2 | 194 | -62 | · |
| 00000011 | 1 | 1 | 1 | 0 | 1 | 1 | 0 | 1 | ED | 237 | -19 | · |
| 00000012 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 40 | 64 | 64 | @ |
| 00000013 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 00 | 0 | 0 | · |
| 00000014 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 00 | 0 | 0 | · |
| 00000015 | 0 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 7F | 127 | 127 | · |
| 00000016 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 80 | 128 | -128 | · |
| 00000017 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | FF | 255 | -1 | · |
Bit 7 is the most significant bit and sits on the left, matching how a byte is written in binary; bit 0 is the least significant. The int8 column reads the same eight bits as a signed two's-complement value, which is why 0xFF is 255 in one column and −1 in the next — the bits never changed, only the interpretation.
| Width | Big-endian | Little-endian | Selected as signed |
|---|---|---|---|
| 16-bit | 17664 | 69 | 17664 |
| 32-bit | 1157627964 | 1006633029 | 1157627964 |
| 64-bit | 4971974246789431296 | 18091485589143621 | 4971974246789431296 |
The same bytes, two orders. Big-endian stores the most significant byte first (network byte order, PNG, JPEG, Java, and every RFC packet diagram); little-endian stores it last (x86, ARM in practice, ZIP, BMP, most on-disk structures). Both readings are computed with BigInt, so 64-bit values stay exact — JavaScript's numeric bitwise operators would silently truncate anything past 32 bits.
Two's complement stores −n as 28 − n, which is why negation is “invert every bit, then add one” and why there is one more negative value than positive: -128 has no positive twin. Addition and subtraction need no special sign handling — the same adder works for both, and overflow simply wraps around the 8-bit ring.
How the value is reconstructed: (−1)0 × 1.000007152557373 × 211 = 2048.0146484375. The leading 1 of the significand is implicit — it is never stored, which buys one extra bit of precision. The stored exponent 138 is offset by the bias 127 so that the field can hold negative exponents without a sign of its own.
| Field | Bits | Width | Binary | Unsigned | Hex |
|---|---|---|---|---|---|
| version | 0–3 | 4 | 0100 | 4 | 0x4 |
| IHL | 4–7 | 4 | 0101 | 5 | 0x5 |
| DSCP | 8–13 | 6 | 000000 | 0 | 0x0 |
| ECN | 14–15 | 2 | 00 | 0 | 0x0 |
| total length | 16–31 | 16 | 0000000000111100 | 60 | 0x3C |
The word is 0x4500003C = 01000101 00000000 00000000 00111100, and the fields cover 32 of its 32 bits. With RFC numbering, a field spanning bits 0–3 is extracted by shifting right 32 − 1 − 3 places and masking with 0xF. RFC packet diagrams number bit 0 as the most significant bit of the first byte; C bitfields and hardware registers usually number from the least significant bit. Getting that backwards is the single most common protocol-parsing bug, which is why the toggle is here.
| Expression | Binary | Hex | Unsigned | Signed |
|---|---|---|---|---|
| A | 11001010 | 0xCA | 202 | -54 |
| B | 00001111 | 0x0F | 15 | 15 |
| A AND B | 00001010 | 0x0A | 10 | 10 |
| A OR B | 11001111 | 0xCF | 207 | -49 |
| A XOR B | 11000101 | 0xC5 | 197 | -59 |
| NOT A | 00110101 | 0x35 | 53 | 53 |
| A << 2 | 00101000 | 0x28 | 40 | 40 |
| A >> 2 | 11110010 | 0xF2 | 242 | -14 |
| A >>> 2 | 00110010 | 0x32 | 50 | 50 |
| A rotl 2 | 00101011 | 0x2B | 43 | 43 |
Every row is computed with BigInt and then masked to 8 bits, so nothing silently truncates. That matters because JavaScript's own bitwise operators convert their operands to signed 32-bit integers first: 2**31 | 0 is −2147483648, and 2**32 | 0 is 0. The difference between >> and >>> is visible above: the arithmetic shift copies the sign bit inward so negative numbers stay negative (−8 >> 1 = −4), while the logical shift pulls in zeros and turns any negative value into a large positive one. Shifting by more than the width is undefined in C and wraps modulo the width in JavaScript, so the input is clamped to 0–8 here.
