Binary Code Translator

What This Tool Does

This tool performs four related conversions in one interface. The first is text-to-binary character encoding: each input character is mapped to its Unicode code point, then to a binary representation at 7-bit ASCII, 8-bit (Latin-1), or 16-bit Unicode width. The second is the inverse — parsing a stream of 0s and 1s back into readable text by reading fixed-width groups and resolving each group through String.fromCharCode(). Both directions support space, newline, or no separator, with automatic detection on input.

The third and fourth conversions handle integer-to-binary and floating-point-to-binary transformations. Integer mode supports 8, 16, 32, and 64-bit widths with signed (two's complement) or unsigned interpretations, including the asymmetric range -2^N-1 to 2^N-1-1 for signed values. Floating-point mode renders the exact IEEE 754 single-precision (binary32) or double-precision (binary64) bit pattern for any decimal input you provide, including special values: positive and negative zero, positive and negative infinity, signaling and quiet NaN, and subnormal (denormal) numbers below the smallest normal magnitude.

Every computation runs client-side. No input you paste — credentials in test data, debugging traces from internal systems, anything — is ever uploaded, logged, or stored outside the tab you have open. The character breakdown table that appears beneath the output panel shows the exact code point and bit pattern for each character, making this tool useful for verifying mojibake recovery, debugging mixed-encoding files, and writing custom parsers that need a known-good reference output.

How to Use It

Pick a direction first. The two top chips — Text → Binary and Binary → Text — control whether the input field accepts readable characters or a stream of 0s and 1s. Output updates live as you type with a 150 ms debounce, so you can iterate on input without waiting between keystrokes.

Set the bit length next. Use 8-bit for general-purpose ASCII plus Latin-1 (the byte stream of most file formats and network protocols). Choose 7-bit ASCII when targeting strict pre-1987 ASCII compliance — every character outputs a 7-bit group with no high-bit padding. Pick 16-bit Unicode for characters above U+007F, including most non-Latin scripts. Each code point above 0xFFFF requires UTF-16 surrogate pairs; this tool emits each surrogate as a separate 16-bit group rather than computing the surrogate-pair encoding, which is the correct behavior when you are debugging raw UTF-16 byte streams from a file or memory dump.

Pick a separator. Space-separated output is the most readable — 01001000 01101001 — and is what most binary-debugging contexts expect. Newline-separated output puts each character on its own line, which makes it easier to align an annotated character breakdown when piping the result into a script. No separator (a continuous bit stream) is correct when the consumer is another parser expecting fixed-width groups; for that case, the Binary → Text direction splits the input on the bit-length boundary.

Click Try Example to pre-load a representative input for the current direction. Use Copy to grab the output as plain text suitable for pasting into an editor, log file, or chat message; use Download to save the result as a .txt file. The status bar at the bottom of the tool panel always shows the bit count, byte count, and any parse errors with the offending substring highlighted.

Worked Example

Three conversions, by hand and in the tool, with the bit-level steps shown explicitly.

Text "Hi" to 8-bit Binary

The string "Hi" has two characters. H has Unicode code point U+0048 (decimal 72); i has U+0069 (decimal 105). Converting each to 8-bit binary by repeated division by 2 (or, equivalently, by reading the bit pattern off the place values 128, 64, 32, 16, 8, 4, 2, 1):

• H = 72 = 64 + 8 = 01001000
• i = 105 = 64 + 32 + 8 + 1 = 01101001

With space separation, the tool outputs 01001000 01101001. Both values fit within 7 bits (high bit zero), so the 7-bit ASCII output would be 1001000 1101001 — identical content, one fewer leading zero per character.

Integer -42 to 8-bit Two's Complement

Encode -42 in two steps. Step one: write the absolute value (42) in unsigned 8-bit binary. 42 = 32 + 8 + 2, so 42 in binary is 00101010. Step two: take the two's complement — invert every bit (one's complement) and add 1.

• Start: 00101010 (the value 42)
• Invert each bit: 11010101 (this is the one's complement of 42)
• Add 1: 11010101 + 00000001 = 11010110

The high bit is 1, confirming a negative value. Reading the result as unsigned gives 214 = 256 - 42, which is the standard alternative interpretation of two's complement: the negative of any value x in an N-bit field is encoded as 2^N - x. Either method produces the same bit pattern 11010110.

3.14159 in IEEE 754 Single-Precision

The decimal value 3.14159 is encoded as a 32-bit IEEE 754 float in three parts: a sign bit, an 8-bit biased exponent, and a 23-bit mantissa. The sign is positive, so the sign bit is 0. Express 3.14159 in normalized binary: it is approximately 1.10010010000111111010001 × 21. The unbiased exponent is 1; adding the bias of 127 gives a stored exponent of 128 = 10000000. The leading 1 of the mantissa is implicit (the so-called "hidden bit"), so the 23 stored mantissa bits are the trailing fraction: 10010010000111111010001.

Concatenating gives the 32-bit pattern: 0 10000000 10010010000111111010001, or with byte grouping, 01000000 01001001 00001111 11010001. The chart below shows the bit layout visually for both single-precision and double-precision formats. (Note: 3.14159 is not exactly representable in binary; the stored value rounds to approximately 3.1415898799896240234375, an error of about 1.2 × 10^-7.)

Common Use Cases

Binary representations come up in any role that touches the wire format or memory layout of data.

Debugging Binary Protocols

Network protocols, file format headers, and serialization frames carry meaning at the bit level. A TCP flags byte contains six individual flag bits (URG, ACK, PSH, RST, SYN, FIN) packed into a single octet — reading the raw hex from a Wireshark capture tells you only that the byte is, say, 0x18, but converting to binary 00011000 immediately shows PSH and ACK are set. The same applies to packed bitfield structures in custom binary formats: protobuf wire tags, BSON type bytes, or the version-and-IHL nibbles in an IPv4 header.

Learning Computer Science Fundamentals

Converting text to binary and back is the canonical first exercise in any character-encoding lesson. Once you have manually computed that H is 01001000, the relationship between code point, encoding, and storage clicks in a way no textbook diagram can match. Two's complement, IEEE 754, and endianness all benefit from the same hands-on approach — and a tool that shows every step is more useful than one that hides the work.

Embedded Microcontroller Register Decoding

Embedded development means reading and writing hardware registers whose individual bits map to specific peripheral behaviors. An ATmega328P's TCCR1A register, the STM32's GPIO MODER, the Cortex-M's NVIC priority registers — each has documented bit fields with semantics like "bits 7:6 = compare output mode A" or "bits 1:0 = pin mode (00=input, 01=output, 10=alternate, 11=analog)". Converting a hex register dump to binary lets you read those fields off the page directly.

Manual Debugging of HEX Dumps

When a hex editor or a corrupted-file post-mortem hands you a sequence of bytes, the path back to "what was this trying to say" often runs through binary. Was the high bit set? Is this signed or unsigned interpretation? Does the byte pattern match a known UTF-8 lead byte (110xxxxx, 1110xxxx, 11110xxx)? Binary view answers those questions in seconds.

Edge Cases

Binary representations have well-known pitfalls. The most common ones — and how this tool handles them — are listed below.

Endianness (little vs big). A 32-bit integer 0x12345678 stored to memory as four bytes is 12 34 56 78 on a big-endian system and 78 56 34 12 on a little-endian system (x86, ARM in user mode, RISC-V default). This tool emits each multi-byte value in big-endian "natural" order (most-significant bit first) to match how humans read numbers. When you are dumping memory from a little-endian process, reverse the byte order before pasting, or paste the bytes one at a time.

Signed vs unsigned interpretation. The 8-bit pattern 11010110 reads as 214 unsigned and as -42 signed (two's complement). Both interpretations of the same bits are valid; the right one depends on context — a length field is almost always unsigned, a temperature offset almost always signed. The tool emits the bit pattern; the interpretation is yours to choose based on the field's documented type.

Two's complement overflow. Adding two large positive signed values can produce a negative result when the sum exceeds 2^N-1-1. 01111111 + 00000001 = 10000000 (127 + 1 = -128 in 8-bit signed). Hardware detects this with the overflow flag, but high-level languages handle it inconsistently — C undefined behavior on signed overflow, Java wraps silently, Rust panics in debug builds and wraps in release. The tool does not perform arithmetic; it only encodes and decodes individual values.

IEEE 754 NaN, Infinity, and denormals. When all exponent bits are 1 and the mantissa is nonzero, the value is NaN (not-a-number) — and there are millions of distinct NaN bit patterns. When all exponent bits are 1 and the mantissa is zero, the value is +Infinity (sign 0) or -Infinity (sign 1). When all exponent bits are 0 and the mantissa is nonzero, the value is a subnormal (denormalized) number — these fill the gap between zero and the smallest normal value with reduced precision. The tool renders all of these correctly.

Signed zero (+0 vs -0). IEEE 754 has two zeros: positive zero (all bits 0) and negative zero (sign bit 1, all other bits 0). They compare equal under == but produce different results in some operations: 1/(+0) = +Infinity while 1/(-0) = -Infinity. Most languages hide this distinction in print output but preserve it in stored representations.

64-bit precision exceeds JavaScript Number. JavaScript's Number type is a binary64 double, with 53 bits of integer precision. Integers above 2⁵³ (about 9.007 × 10¹⁵) cannot be represented exactly. For 64-bit integer work, use BigInt (literal suffix n) or specialized libraries. This tool uses BigInt internally for 64-bit values to avoid silent precision loss.

Behind the Scenes

Binary number representation has a longer history than the silicon that uses it. The mathematical foundation predates the first electromechanical computer by more than two and a half centuries.

Positional Binary Notation and Leibniz (1679)

Gottfried Wilhelm Leibniz wrote the first formal description of base-2 positional notation in a 1679 manuscript later published as "Explication de l'Arithmétique Binaire" (1703). Leibniz did not invent binary — Pingala had described a closely related system in Sanskrit prosody around 200 BCE, and the I Ching's hexagrams encode 6-bit patterns — but Leibniz was the first to articulate the arithmetic operations (addition, subtraction, multiplication, division) algorithmically in base 2 in the way modern computers implement them. He also recognized the mechanical advantage: a base-2 calculator requires only two stable states per digit, far simpler to build than a decimal calculator.

Von Neumann's IAS Machine and Stored-Program Computing

The Institute for Advanced Study (IAS) machine, designed by John von Neumann's team and operational in 1952, was the first widely-replicated stored-program computer using binary representation throughout. Its 40-bit word held either one floating-point number or two 20-bit instructions, with all values stored and processed as native binary. The IAS architecture influenced ILLIAC, JOHNNIAC, MANIAC, AVIDAC, and dozens of other early machines — the binary, stored-program design is now so universal that "von Neumann architecture" is shorthand for any computer that holds instructions and data in the same binary memory.

IEEE 754-1985 Floating-Point Standardization

Before IEEE 754, every floating-point format was vendor-specific. IBM 360 used base-16 floats with a 7-bit exponent. DEC VAX used base-2 with a different bias. Cray used base-2 but without a hidden bit. The same C program could produce different numerical results on different machines, with different overflow behaviors and different NaN handling. William Kahan led the IEEE 754 standardization effort starting in 1977, and the resulting standard (ratified 1985, revised 2008 and 2019) defined a single binary floating-point format used by every modern CPU. The standard guarantees specific bit-exact results for the basic operations (+, -, ×, ÷, √) and specifies how special values (NaN, Infinity, signed zero, denormals) must behave — which is why this tool can render the bit pattern for 3.14159 with confidence that any IEEE 754-compliant chip will agree.

Why Two's Complement Won Over Sign-Magnitude

Early binary computers used several incompatible encodings for signed integers. Sign-magnitude (one bit for the sign, the rest for the absolute value) is the most intuitive — it matches how humans write -42 — but it has two representations of zero (+0 and -0) and requires separate add/subtract circuits because the sign bit cannot be folded into the arithmetic directly. One's complement (negate by inverting every bit) also has two zeros and requires an end-around carry to handle subtraction correctly. Two's complement has exactly one zero, uses the same adder for signed and unsigned arithmetic, and naturally implements modular arithmetic — making it the dominant encoding by the mid-1960s and the universal one by the 1980s.

Comparison: This Tool vs CLI vs Calculator Apps

A handful of alternatives offer overlapping but distinct functionality. Pick the right one based on what you need to see.

The Python recipe for IEEE 754 binary32 conversion fits in two lines: import struct; ''.join(f'{b:08b}' for b in struct.pack('>f', 3.14159)) produces 01000000010010010000111111010001 — the same bit pattern this tool's worked example produces, byte-identical. Use the tool when you want the visual breakdown; use the script when you want to process a CSV of 10,000 values into a binary column.